ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
ASX340AT Non-Volatile Memory (NVM) Contents
Encoding Specification
For the latest datasheet, please visit www.onsemi.com
ASX340AT
Non-Volatile Memory (NVM) Contents Encoding
Specification
AND9333/D Rev. 1, Pub. 11/15
1
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Table of Contents
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Run Length Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Color Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Encoding Concepts and Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Record Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Payload Encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Checksums. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Extensible Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Record Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Record Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
NULL_RECORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
EXTENDED_NULL_RECORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
EXTENDED_RECORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
END_MARKER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
TOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
INIT_TABLE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
PATCH_TOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
OVERLAY_BITMAP_TOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
OVERLAY_STRING_TOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
COMMAND_SEQ_TOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
REGISTER_ARRAY_V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
VARIABLE_ARRAY_V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
REGISTER_SET_V1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
REGISTER_MASKED SET_V1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
VARIABLE_SET_V1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
VARIABLE_MASKED_SET_V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
REGISTER_INIT_V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
VARIABLE_INIT_V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
COMMAND_V1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
PATCH_V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
OVERLAY_BITMAP_V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
OVERLAY_BITMAP_V2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
OVERLAY_STRING_V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
COMMAND_SEQ_V1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
VENDOR_SPECIFIC_nn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Appendix A: Big-Endian Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Appendix B: Example NVM Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Appendix C: Extended Record Encoding Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Appendix D: TOC Processing Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Appendix E: MT9V126 Rev2 to ASX340AT Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Appendix F: Record Quick Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
AND9333/D Rev. 1, Pub. 11/15
2
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
List of Figures
List of Figures
Figure 1:
Figure 2:
NVM Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Example Flash/EEPROM Memory Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
AND9333/D Rev. 1, Pub. 11/15
3
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
List of Tables
List of Tables
Table 1:
Table 2:
Table 3:
Table 4:
Table 5:
Table 6:
Table 7:
Table 8:
Table 9:
Table 10:
Table 11:
Table 12:
Table 13:
Table 14:
Table 15:
Table 16:
Table 17:
Table 18:
Table 19:
Table 20:
Table 21:
Table 22:
Table 23:
Table 24:
Table 25:
Table 26:
Table 27:
Table 28:
Table 29:
Table 30:
Table 31:
Table 32:
Table 33:
Table 34:
Table 35:
Table 36:
Table 37:
Table 38:
Table 39:
Table 40:
Table 41:
Table 42:
Table 43:
Table 44:
Table 45:
Table 46:
Table 47:
Table 48:
Table 49:
Table 50:
Table 51:
Overlay Color Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Record Encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
SPI NVM Record Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
NULL_RECORD Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
NULL_RECORD Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
EXTENDED_NULL_RECORD Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
EXTENDED_NULL_RECORD Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
EXTENDED_RECORD Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
EXTENDED_RECORD Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
END_MARKER Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
TOC Header Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
TOC Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
INIT_TABLE Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
INIT_TABLE Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
PATCH_TOC Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
PATCH_TOC Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
OVERLAY_BITMAP_TOC Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
OVERLAY_BITMAP_TOC Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
OVERLAY_STRING_TOC Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
OVERLAY_STRING_TOC Payload Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
COMMAND_SEQ_TOC Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
COMMAND_SEQ_TOC Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
REGISTER_ARRAY_V1 Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
REGISTER_ARRAY_V1 Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
VARIABLE_ARRAY_V1 Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
VARIABLE_ARRAY_V1Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
REGISTER_SET_V1 Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
REGISTER_SET_V1 Payload Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
REGISTER_MASKED SET_V1 Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
REGISTER_MASKED SET_V1 Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
VARIABLE_SET_V1 Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
VARIABLE_SET_V1 Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
VARIABLE_MASKED_SET_V1 Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
VARIABLE_MASKED_SET_V1 Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
REGISTER_INIT_V1 Header Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
REGISTER_INIT_V1 Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
VARIABLE_INIT_V1 Header Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
VARIABLE_INIT_V1 Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
COMMAND_V1 Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
COMMAND_V1 Payload Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
PATCH_VI Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
PATCH_VI Payload Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
OVERLAY_BITMAP_V1 Header Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
OVERLAY_BITMAP_V1 Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
OVERLAY_BITMAP_V2 Header Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
OVERLAY_BITMAP_V2 Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
OVERLAY_STRING_V1 Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
OVERLAY_STRING_V1 Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
COMMAND_SEQ_V1 Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
COMMAND_SEQ_V1 Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
VENDOR_SPECIFIC_nn Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
AND9333/D Rev. 1, Pub. 11/15
4
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
List of Tables
Table 52:
Table 53:
Table 54:
Table 55:
Table 56:
Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Using SYSMGR_CONFIG_MODE to control the System Configuration Phase . . . . . . . . . . . . . . . . . . .43
MT9V126 Rev2 to ASX340AT Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Record Quick Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
AND9333/D Rev. 1, Pub. 11/15
5
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Introduction
Introduction
This document specifies the encoding of data stored in non-volatile memory (NVM) for
the ASX340AT Rev2 device . This document is intended for developers of the NVM
supporting tools and for Applications Engineers.
Background
The ASX340AT supports an optional NVM device, that is, SPI Flash or SPI EEPROM, to
enhance the graphical overlay capabilities of the device, and to store configuration and
calibration data.
The SPI Flash configuration and control support provided by MT9V126 has been maintained by ASX340AT, where applicable (see Appendix E).
Context
Figure 1 shows that the SPI NVM device is directly attached to the ASX340AT through the
SPI bus. The ASX340AT implements an SPI bus master controller and a DMA engine. The
DMA engine can transfer data over the SPI bus directly to various internal RAM memories without processor intervention.
Figure 1:
NVM Context
SPI
Flash
Overlay RAM
5 x 2 Kb
Patch RAM
ASX340AT
Microprocessor
Firmware
Variables
Two-wire
Serial I/F
Host
The ASX340AT on-chip firmware configures the SPI bus controller and DMA engine as
appropriate, initiates a transfer, then waits for a DMA-complete interrupt. At this point,
the requested data has been transferred into the required RAM.
The SPI bus controller implements a 16-bit accumulator, which sums all incoming 16bit data values it receives over the SPI bus. When a transfer is complete, the firmware can
optionally use the accumulator contents to checksum (integrity check) the transferred
data.
AND9333/D Rev. 1, Pub. 11/15
6
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Introduction
Run Length Encoding
The NVM can contain overlay bitmaps. These are stored in a run-length encoded
(compressed) format.
Color Encoding
The NVM can contain overlay color look-up tables (LUTs). These are stored in the
YCbCrA 6554 format, meaning 6 bits of luminance, 5 bits of blue and red chrominance,
and 4 bits of alpha (opacity). However, these values are packed into a 32-bit value with
padding as shown in Table 1:
Table 1:
Overlay Color Encoding
Byte Address
Bits
Purpose
+0
1...0
Reserved
7...2
Y
2...0
Reserved
7...3
Cb
2...0
Reserved
+1
+2
+3
AND9333/D Rev. 1, Pub. 11/15
Description
Luminance
Blue chrominance
7...3
Cr
3...0
Reserved
Red chrominance
7...4
Alpha
Opacity
7
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Encoding Concepts and Assumptions
Encoding Concepts and Assumptions
The NVM Encoding specified in this document is based on the following concepts, rules
and assumptions:
• All data stored in NVM is encoded into 'records'.
• Each record contains a header, and a payload.
• The payload must contain a multiple of 16-bit data values. Any trailing bytes should
be padded with 0x00.
• All 16- and 32-bit data values are encoded in big-endian format (see “Appendix A: BigEndian Encoding” on page 40).
• All records must be aligned to a 16-bit boundary (bottom address bit must be zero).
• All records must encode a 16-bit checksum into the header to allow data integrity to
be verified.
• All NVM addresses are encoded within a 32-bit value. Refer to Appendix B of the
ASX340AT Host Command Interface document for examples of supported NVM
devices.
The supported NVM devices have densities ranging from 1Kb to 8Mb. This requires a
maximum addressable range of 20 bits (8Mb = 1MB = 2^20). However, in order to
maintain 16-bit record packing, this range must be extended to use 32 bits.
• There are no hardcoded address placements for records; however,
– For SPI Flash devices, the TOC record must reside on a four Kbyte address boundary within the first 256 Kbytes of the device.
– For SPI EEPROM devices, the TOC record must reside at address 0x0.
An example NVM memory layout using the encoding scheme is given in Appendix B.
• No assumption is made that the device is owned solely by the SOC firmware.
• The encoding specification does not make any assumptions on the erase block size of
the underlying NVM device. The intention is that (provided sufficient space exists) the
encoded data can be modified and extended without requiring block erasures and
reprogramming of existing data.
• The intention is that a default NVM image will be created by a customer (using the
NVM support tools) and programmed into all Flash/EEPROM devices. However, over
time additional information can be added to each individual device. The encoding
scheme is therefore extensible, permitting additional records to be added without
requiring reprogramming of existing contents.
AND9333/D Rev. 1, Pub. 11/15
8
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Encoding Concepts and Assumptions
Record Encoding
Standard records have the encoding specified in Table 2:
Table 2:
Record Encoding
Byte Offset
Bits
Purpose
Description
+0
7..0
Record type
8-bit record type identifier
+1
7..0
Payload length
8-bit payload length
+2
7..0
MSB of checksum
16-bit checksum
+3
7..0
LSB of checksum
+4 to
(payload length + 3)
–
Payload
Record payload - padded to 16-bit boundary
The encoding scheme supports 256 record types, which is deemed suitable for the foreseeable future. The standard record encoding scheme supports payloads from 0 to 254
bytes (255 is an illegal value). This is suitable for the majority of records supported by
this specification. However, an extended record type exists to support larger payloads
(up to 64Kb), and to permit future expansion of record types. Appendix C gives an
example of an extended record encoding.
Note:
The maximum record size for any particular implementation may be restricted.
Payload Encoding
The encoding of the record payload is specific to each record; see the record definitions
in“Record Types” on page 11. However, all multibyte fields must be encoded in bigendian format.
Checksums
The record checksum is calculated over the entire record (all header and payload 16-bit
values). The checksum is a 16-bit one's complement addition of the record and payload
contents (identical to the IP packet checksum -- see RFC 1071 at http://www.faqs.org/
rfcs/rfc1071.html).
When calculating the checksum, the checksum field of the record is read as 0x0000, then
written with the resultant checksum. When using the checksum to determine the integrity of the record, the 1one's complement addition of the record including its checksum
should result in a resultant checksum of 0xFFFF.
Extensible Encoding
The encoding scheme supports extensibility, in that although each record is of fixed size
and cannot be extended after programming, the number of records in any particular
region is not fixed. The firmware will continue processing records until if finds an
END_MARKER record. This record has a special encoding that allows it to be subsequently overwritten and a new record added to the existing sequence.
Record Versioning
Some records detailed in this specification have an explicit version (for example,
PATCH_V1) and some have an implicit version (TOC). The intention is that the version of
all records without an explicit version is tied to the Version ID field of the TOC record.
These records cannot be updated in the field without reprogramming the Version ID.
However, records with an explicit version can be added to a device without requiring
AND9333/D Rev. 1, Pub. 11/15
9
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Encoding Concepts and Assumptions
reprogramming of the existing contents. The intention is that, over time, firmware
updates (maybe due to part revisions and/or patches) may add additional records, or
updated record versions, but the firmware should continue to support existing NVM
images with older versions.
AND9333/D Rev. 1, Pub. 11/15
10
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
Record Types
Overview
Table 3 lists the mandatory and optional record types that are encompassed within this
specification (details of each type are provided in subsequent sections):
Table 3:
SPI NVM Record Types
Mandatory /
Optional
Encoding
Description
NULL_RECORD
O
0x00
Indicates a record that should be ignored by the firmware. This allows
an existing record to be deleted.
EXTENDED_RECORD
O
0xFE
Supports larger payloads, and future expansion of the encoding
format.
END_MARKER
M
0xFF
Indicates the end of a variable-length array of records.
TOC
M
0xF1
The table of contents identifies the encoding version of the NVM
contents, and the locations of the various records present in the NVM.
This is the only record that has restricted address placement
requirement.s
INIT_TABLE
O
0xF2
Lists the records to be processed during the initialization phase (these
are typically register and variable defaults).
PATCH_TOC
O
0xF3
Provides a table of contents for the patches encoded within the NVM.
This allows patches to be referenced by index, and not by absolute
address.
OVERLAY_BITMAP_TOC
O
0xF4
Provides a table of contents for the bitmaps encoded within the NVM.
This allows bitmaps to be referenced by index, and not by absolute
address.
OVERLAY_STRING_TOC
O
0xF5
Provides a table of contents for the character strings encoded within
the NVM This allows character strings to be referenced by index, and
not by absolute address.
COMMAND_SEQ_TOC
O
0xF6
Provides a table of contents for the command sequences encoded
within the NVM. This allows command sequences to be referenced by
index, and not by absolute address.
REGISTER_ARRAY_V1
O
0x40
Encodes a contiguous range of register values (register values
increment linearly).
VARIABLE_ARRAY_V1
O
0x50
Encodes a contiguous range of (firmware) variable values (register
values increment linearly).
REGISTER_SET_V1
O
0x60
Encodes a noncontiguous set of register values (discrete address/value
pairs).
REGISTER_MASKED SET_V1
O
0x61
Encodes a noncontiguous set of register bit field values (discrete
address/mask/value tuples).
VARIABLE_SET_V1
O
0x70
Encodes a noncontiguous set of variable values (discrete address/value
pairs).
VARIABLE_MASKED_SET_V1
O
0x71
Encodes a noncontiguous set of variable bit field values (discrete
address/mask/value tuples).
REGISTER_INIT_V1
O
0x41
Encodes a single initialization value for a range of registers.
VARIABLE_INIT_V1
O
0x51
Encodes a single initialization value for a linear range of variables.
COMMAND_V1
O
0xB1
Encodes a single host command.
PATCH_V1
O
0x80
Encodes a firmware patch (for loading by the patch loader).
OVERLAY_BITMAP_V1
O
0x90
Encodes an overlay bitmap header, and the run-length encoded
bitmap.
Record Type
AND9333/D Rev. 1, Pub. 11/15
11
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
Table 3:
SPI NVM Record Types (continued)
Mandatory /
Optional
Encoding
OVERLAY_BITMAP_V2
O
0x91
Encodes an overlay bitmap header, and the run-length encoded
bitmap.
OVERLAY_STRING_V1
O
0xA0
Encodes an overlay character string header, and the character string.
COMMAND_SEQ_V1
O
0xB0
Encodes one or more host commands, allowing command execution
from NVM.
VENDOR_SPECIFIC_nn
O
0xE0-0xEF
Record Type
Note:
Description
These records are a reserved range for vendor-specific data; these
records are not interpreted by the SOC firmware.
The firmware will ignore any unrecognized record types, and attempt to use the payload length to
determine where to look for the next record. Note however that the resultant side effects of using
a potentially invalid payload length field cannot be mitigated by the firmware.
NULL_RECORD
The NULL_RECORD is provided to allow an existing record to be deleted.
Table 4:
NULL_RECORD Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0x00
NULL_RECORD
+1
Payload Length
8 bits
-
See Table 5, NULL_RECORD Payload Format.
+2
Checksum
16 bits
-
Dependent on payload
Table 5:
NULL_RECORD Payload Format
Byte Offset
Field
Size
Value
0..(Payload Length - 1)
Notes:
AND9333/D Rev. 1, Pub. 11/15
Description
Ignored
1. The NULL_RECORD record is provided to allow an existing record to be ‘deleted’. The Record Type
code of 0x00 is chosen specifically for (NOR) Flash memory - any location can be programmed to
0x00 without requiring a block erasure.
2. The intention is that a new record can be written to the END_MARKER following an existing record,
and the existing record converted to a NULL_RECORD. The firmware ignores the payload of a
NULL_RECORD, and will therefore skip the existing record and process the following new record.
3. A NULL_RECORD cannot be written over an EXTENDED_RECORD; instead, an EXTENDED_NULL_RECORD is required.
4. The Checksum field of a NULL_RECORD is invalid, and is ignored when the record is processed.
12
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
EXTENDED_NULL_RECORD
This record is provided to allow an existing EXTENDED_RECORD to be ‘deleted’.
Table 6:
EXTENDED_NULL_RECORD Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
16 bits
0x0000
+1
Payload Length
16 bits
-
See Table 7, EXTENDED_NULL_RECORD Payload Format.
+2
Checksum
16 bits
-
Dependent on payload.
Table 7:
EXTENDED_NULL_RECORD
EXTENDED_NULL_RECORD Payload Format
Byte Offset
Field
Size
Value
0..(Payload Length- 1)
Notes:
AND9333/D Rev. 1, Pub. 11/15
Description
Ignored
1. The EXTENDED_NULL_RECORD record is provided to allow an existing extended record to be
‘deleted’. The Record Type code of 0x0000 is chosen specifically for (NOR) Flash memory-- any location can be programmed to 0x0000 without requiring a block erasure.
2. The intention is that a new record can be written to the END_MARKER following an existing
extended record, and the existing extended record converted to an EXTENDED_NULL_RECORD. The
firmware ignores the payload of an EXTENDED_NULL_RECORD, and will therefore skip the existing
record and process the following new record.
3. The Checksum field of an EXTENDED_NULL_RECORD is invalid, and is ignored when the record is
processed.
13
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
EXTENDED_RECORD
This record is provided to allow larger payload sizes, and for future extension of the
encoding format.
Table 8:
EXTENDED_RECORD Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0xFE
EXTENDED_RECORD
+1
Payload Length
8 bits
0x4
See Table 9, EXTENDED_RECORD Payload Format.
+2
Checksum
16 bits
–
Table 9:
EXTENDED_RECORD Payload Format
Byte Offset
+0
Dependent on payload.
Field
Extended Record Type
Size
16 bits
Value
0x0000, 0x00FF
Reserved.
0x0001 - 0x00FE
Standard record type
0x0100 - 0xFFFE
0xFFFF
+2
Extended Payload Length
+4
AND9333/D Rev. 1, Pub. 11/15
16 bits
–
…
Notes:
Description
Extended record type.
Reserved.
Dependent on payload.
Extended payload.
1. The record Checksum field applies to the entire extended record, which can extend to 64KB.
2. The EXTENDED_RECORD payload encodes the record type of the extended payload. ‘Standard’
records can be encoded within extended payloads, by using their 8-bit record type identifier within
the extended record type field (values 0x00xx are reserved for this purpose).
3. "Appendix C gives an example of an OVERLAY_BITMAP_V1 payload encoded with an EXTENDED_RECORD.
14
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
END_MARKER
This record is used to indicate the end of a variable-length array of records. Note the
payload length value of 0xFF is illegal in any other record.
Table 10:
END_MARKER Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0xFF
END_MARKER
+1
Payload Length
8 bits
0xFF
No payload
+2
Checksum
16 bits
0xFFFF
Notes:
AND9333/D Rev. 1, Pub. 11/15
Checksum not calculated
1. After erasure, all (NOR) Flash devices will read back 0xFF from all locations. This encoding was chosen to allow an erased section of Flash to be used as an END_MARKER. If a new record is added to
the end of an existing array, it can simply be programmed directly over the previous END_MARKER.
The array will now be terminated by the subsequent region of erased Flash.
2. Therefore, END_MARKER records do not have to be explicitly programmed into the Flash - they are
created implicitly after erasure of the device.
15
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
TOC
The TOC (table of contents) record provides an index to various other records in the
NVM.
Table 11:
TOC Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0xF1
TOC
+1
Payload Length
8 bits
0x2C
See Table 12, TOC Payload Format.
+2
Checksum
16 bits
–
Table 12:
Dependent on payload.
TOC Payload Format
Byte
Offset
Field
Size
Value
Description
+0
Version ID
32 bits 0x4B323242
Identifies the version of the NVM encoding format
+4
Init Table
32 bits Address of the INIT_TABLE
record
Pointer to the INIT_TABLE record to process during the
initialization phase
+8
Calibration Table
32 bits Address of the INIT_TABLE
record
Pointer to INIT_TABLE record to process during the
calibration phase
+12
Patch Init Table
32 bits Address of the INIT_TABLE
record
Pointer to INIT_TABLE record to process during the patch
loading phase
+16
Reserved
32 bits 0x0
Reserved -- set to all zeros
+20
Overlay Init Table
32 bits Address of the INIT_TABLE
record
Pointer to the first INIT_TABLE record to process during
Overlay initialization.
+24
Patch TOC
32 bits Address of PATCH_TOC record Pointer to the PATCH_TABLE record
+28
Overlay Bitmap TOC
32 bits Address of the
Pointer to the bitmap TOC record
OVERLAY_BITMAP_TOC record
+32
Overlay String TOC
32 bits Address of the
Pointer to the overlay string TOC record
OVERLAY_STRING_TOC record
+36
Command Seq TOC
32 bits Address of the
COMMAND_SEQ_TOC record
Pointer to the command sequence TOC record
+40
Reserved
32 bits 0x0
Reserved -- set to all zeros
Notes:
AND9333/D Rev. 1, Pub. 11/15
1. The TOC record is intended to provide a contents index function for the firmware, and to locate the
various initialization records.
2. The TOC record must be located
– within the first 256 KB of an SPI Flash device, on a four KB boundary (0x0000, 0x1000, 0x2000....).
– at address 0x0 of an SPI EEPROM device
3. Appendix D describes how the TOC is processed by the SOC firmware.
4. The 'Init Table' field should point to the initialization INIT_TABLE record in the NVM.
If the NVM does not contain an initialization INIT_TABLE record, this field must be zero.
5. The Calibration Table field should point to the calibration INIT_TABLE record in the NVM to be processed during the calibration phase.
If the NVM does not contain a calibration INIT_TABLE record, this field must be zero.
6. The Patch Init Table field should point to the Patch INIT_TABLE record in the NVM to be processed
during Patch initialization.
If the NVM does not contain a Patch INIT_TABLE record, this field must be zero.
7. The Overlay Init Table field should point to the Overlay INIT_TABLE record in the NVM to be processed during Graphical Overlay initialization.
If the NVM does not contain an Overlay INIT_TABLE record, this field must be zero.
16
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
8. The Patch TOC field should point to the PATCH_TOC record in the NVM.
If the NVM does not contain any PATCH_Vx records, this field must be zero.
9. The Overlay Bitmap TOC field should point to the OVERLAY_BITMAP_TOC record in the NVM.
If the NVM does not contain any OVERLAY_BITMAP_Vx records, this field must be zero.
10. The Overlay String TOC field should point to the OVERLAY_STRING_TOC record in the NVM.
If the NVM does not contain any OVERLAY_STRING_Vx records, this field must be zero.
11. The Command Sequence TOC field should point to the COMMAND_SEQ_TOC record in the NVM.
If the NVM does not contain any COMMAND_SEQ_Vx records, this field must be zero.
AND9333/D Rev. 1, Pub. 11/15
17
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
INIT_TABLE
This record encodes the set of records that must be processed during an initialization
phase.
Table 13:
INIT_TABLE Header Format
Byte Offset
Field
Size
Value
Description
INIT_TABLE
+0
Record Type
8 bits
0xF2
+1
Payload Length
8 bits
–
See Table 14, INIT_TABLE Payload Format.
+2
Checksum
16 bits
–
Dependent on payload.
Table 14:
INIT_TABLE Payload Format
Byte Offset
Value
Description
+0
Record_0
Field
32 bits
Size
Address of first record to process
Pointer to first record.
+4
Record_1
32 bits
Address of second record to process
Pointer to second record
+(Payload Length - 4) Record_n
32 bits
Address of last record to process
Pointer to last record
…
AND9333/D Rev. 1, Pub. 11/15
Notes:
1. The INIT_TABLE record provides a list of records that must be processed by the firmware during the
various initialization phases.
2. The intention is that the records to be processed may be scattered throughout the NVM, and therefore may also be referenced by other tables.
3. The INIT_TABLE record can reference the following record types:
- REGISTER_ARRAY_V1
- REGISTER_INIT_V1
- REGISTER_SET_V1
- REGISTER_MASKED SET_V1
- VARIABLE_ARRAY_V1
- VARIABLE_INIT_V1
- VARIABLE_SET_V1
- VARIABLE_MASKED_SET_V1
- COMMAND_V1
Important
The ASX340AT firmware uses overlay buffer index 4 as scratch RAM when processing an INIT_TABLE record.
Each record referenced by the INIT_TABLE is first located and verified, then retrieved into the scratch RAM.
The user must ensure NO bitmaps are loaded into overlay buffer index 4 during the initialization phases.
The user must ensure that NO records referenced by an INIT_TABLE record have payloads that exceed two
kilobytes.
18
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
PATCH_TOC
This record is used to provide a logical-to-physical address look-up for patch records
stored in the NVM.
Table 15:
PATCH_TOC Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0xF3
PATCH_TOC
+1
Payload Length
8 bits
–
See Table 16, PATCH_TOC Payload Format.
+2
Checksum
16 bits
–
Dependent on payload.
Table 16:
PATCH_TOC Payload Format
Byte Offset
Field
Size
+0
Patch_0
32 bits
Address of first PATCH_Vx record
Value
Description
Pointer to first patch
+4
Patch_1
32 bits
Address of second PATCH_Vx record
Pointer to second patch
Patch_n
32 bits
Address of last PATCH_Vx record
Pointer to last patch
…
+(Payload Length - 4)
Notes:
AND9333/D Rev. 1, Pub. 11/15
1. The PATCH_TOC details the locations of the patches encoded within the NVM.
2. The intention is that it provides a logical-to-physical translation of the patch record address. The
Host software only has to provide a logical patch index. The firmware will use the TOC to determine
the physical address.
3. This allows the ASX340AT Flash generation tool to place patch records where it wishes within the
NVM, and then generate the PATCH_TOC, rather than having to fix-up addresses for every patch reference throughout the NVM.
4. It also allows patches to be replaced in the field—the Host would store the new patch records in a
suitable location, and then write a new PATCH_TOC record immediately following the existing one.
It would then convert the existing PATCH_TOC to a NULL_RECORD. The firmware will subsequently
ignore the 'deleted' TOC and use the new TOC, which references the new patches (but maintains
their logical indexes).
19
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
OVERLAY_BITMAP_TOC
This record is used to provide a logical-to-physical address look-up for overlay bitmap
records stored in the NVM.
Table 17:
OVERLAY_BITMAP_TOC Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0xF4
OVERLAY_BITMAP_TOC
+1
Payload Length
8 bits
–
See Table 18, OVERLAY_BITMAP_TOC Payload Format.
+2
Checksum
16 bits
–
Dependent on payload.
Table 18:
OVERLAY_BITMAP_TOC Payload Format
Byte Offset
Field
Size
+0
Bitmap_0
32 bits
Address of first
OVERLAY_BITMAP_Vx record
Address of the first overlay bitmap
+4
Bitmap_1
32 bits
Address of second
OVERLAY_BITMAP_Vx record
Address of the second overlay bitmap
Bitmap_n
32 bits
Address of the last
OVERLAY_BITMAP_Vx record
…
Description
–
+(Payload Length - 4)
Notes:
AND9333/D Rev. 1, Pub. 11/15
Value
Address of the last overlay bitmap
1. The OVERLAY_BITMAP_TOC details the locations of the bitmaps encoded within the NVM
2. The intention is that it provides a logical-to-physical translation of the bitmap address. The Host
software only has to provide a logical bitmap index. The firmware will use the TOC to determine the
physical address.
3. This allows the NVM generation tool to place bitmaps where it wishes within the NVM, and then
generate the OVERLAY_BITMAP_TOC, rather than having to fix up addresses for every bitmap reference throughout the NVM.
4. It also allows bitmaps to be replaced in the field—the Host would store the new bitmap records in a
suitable location, and then write a new OVERLAY_BITMAP_TOC record immediately following the
existing one. It would then convert the existing OVERLAY_BITMAP_TOC to a NULL_RECORD. The
firmware will then subsequently ignore the 'deleted' TOC and use the new TOC, which references
the new bitmaps (but maintains their logical indexes).
20
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
OVERLAY_STRING_TOC
This record is used to provide a logical-to-physical address look-up for overlay string
records stored in the NVM.
Table 19:
OVERLAY_STRING_TOC Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0xF5
+1
Payload Length
8 bits
–
See Table 20, OVERLAY_STRING_TOC Payload Format.
+2
Checksum
16 bits
–
Dependent on payload.
Table 20:
OVERLAY_STRING_TOC
OVERLAY_STRING_TOC Payload Format
Byte Offset
Field
Size
Value
Description
+0
String_0
32 bits
Address of first OVERLAY_STRING_Vx record
Address of the first overlay string
+4
String_1
32 bits
Address of second OVERLAY_STRING_Vx record
Address of the second overlay string
String_n
32 bits
Address of the last OVERLAY_STRING_Vx record Address of the last overlay string
…
–
+(Payload Length - 4)
Notes:
AND9333/D Rev. 1, Pub. 11/15
1. The OVERLAY_STRING_TOC details the locations of the strings encoded within the NVM.
2. The intention is that it provides a logical-to-physical translation of the string address. The Host
software only has to provide a logical string index. The firmware will use the TOC to determine the
physical address.
3. This allows the ASX340AT Flash generation tool to place strings where it wishes within the NVM,
and then generate the OVERLAY_STRING_TOC, rather than having to fix up addresses for every
string reference throughout the NVM.
4. It also allows strings to be replaced in the field– the Host would store the new string records in a
suitable location, and then write a new OVERLAY_STRING_TOC record immediately following the
existing one. It would then convert the existing OVERLAY_STRING_TOC to a NULL_RECORD. The
firmware will then subsequently ignore the 'deleted' TOC and use the new TOC, which references
the new strings (but maintains their logical indexes).
21
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
COMMAND_SEQ_TOC
This record is used to provide a logical-to-physical address look-up for command
sequence records stored in the NVM.
Table 21:
COMMAND_SEQ_TOC Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0xF6
+1
Payload Length
8 bits
–
See Table 22, COMMAND_SEQ_TOC Payload Format.
+2
Checksum
16 bits
–
Dependent on payload.
Table 22:
COMMAND_SEQ_TOC
COMMAND_SEQ_TOC Payload Format
Byte Offset
Field
Size
Value
Address of first
COMMAND_SEQ_Vx record
Address of second
COMMAND_SEQ_Vx record
-
+0
Command_0
32 bits
+4
Command_1
32 bits
Command_n
32 bits
…
+(Payload Length - 4)
Notes:
AND9333/D Rev. 1, Pub. 11/15
Address of the last
COMMAND_SEQ_Vx record
Description
Address of the first command sequence
Address of the second command sequence
Address of the last command sequence
1. The COMMAND_SEQ_TOC details the locations of the command sequences encoded within the
Flash.
2. The intention is that it provides a logical-to-physical translation of the command address. The Host
software only has to provide a logical command index. The firmware will use the COMMAND_SEQ_TOC to determine the physical address.
3. This allows the ASX340AT Flash generation tool to place commands where it wishes within the
Flash, and then generate the COMMAND_SEQ_TOC, rather than having to fix-up addresses for
every command sequence reference throughout the Flash.
4. It also allows command sequences to be replaced in the field - the Host would store the new command records in a suitable location, and then write a new COMMAND_SEQ_TOC record immediately following the existing one. It would then convert the existing COMMAND_SEQ_TOC to a
NULL_RECORD. The firmware will then subsequently ignore the 'deleted' TOC and use the new TOC,
which references the new commands (but maintains their logical indexes).
22
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
REGISTER_ARRAY_V1
This record is used to store a contiguous array (range) of 16-bit register values.
Table 23:
REGISTER_ARRAY_V1 Header Format
Byte Offset
+0
Field
Record Type
Size
Value
Description
8 bits
0x40
REGISTER_ARRAY_V1
+1
Payload Length
8 bits
+2
Checksum
16 bits
Table 24:
See Table 24, REGISTER_ARRAY_V1 Payload Format.
–
Dependent on payload.
REGISTER_ARRAY_V1 Payload Format
Byte Offset
+0
Field
Size
Start address
Value
16 bits
Description
The first register address. Value[0] will be written to this address. Must
be 16-bit aligned.
+2
Value[0]
16 bits
+4
Value[1]
16 bits
–
First register value
Next register value
+(Payload Length - 2) Value[n]
16 bits
Last register value
…
Notes:
AND9333/D Rev. 1, Pub. 11/15
1. The number of register values in the record is: (Payload Length - 2) / 2
2. The REGISTER_ARRAY_V1 record can be encoded into an EXTENDED_RECORD payload if the number
of register values exceeds 126.
23
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
VARIABLE_ARRAY_V1
This record is used to store a contiguous array (range) of 8-bit variable values.
Table 25:
VARIABLE_ARRAY_V1 Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0x50
VARIABLE_ARRAY_V1
+1
Payload Length
8 bits
+2
Checksum
16 bits
Table 26:
See Table 26, VARIABLE_ARRAY_V1Payload Format.
–
Dependent on payload.
VARIABLE_ARRAY_V1Payload Format
Byte Offset
Field
Size
Value
+0
Page + Offset
16 bits
+2
Value[0]
8 bits
0...9: offset
10...14: page
15: reserved
–
Description
+3
Value[1]
8 bits
Next byte value
Value[n]
8 bits
Last byte value
Identifies firmware variable page (ID) and offset of variable
within page.
First byte value
…
+(Payload Length - 1)
Notes:
AND9333/D Rev. 1, Pub. 11/15
1. When applying the variable settings, the firmware effectively performs a byte-wise memory-copy
from the NVM to the specified variable page + offset.
2. The 'Page' component of the 'Page + Offset' field is the firmware's logical identifier (or context) for
the variable data; the page is also known as the 'Driver ID'. The logical-to-physical translation is performed through the 'Page Table' (also known as 'Driver Table') which is initialized by the firmware at
start-up. When the variable is being updated from an NVM record, the firmware also uses the Page
Table to determine the physical base address.
3. The number of variable (byte) values contained in the record is: Payload Length - 2.
4. The VARIABLE_ARRAY_V1 record can only be used to write an even number of bytes. Any additional
trailing byte should be encoded into an VARIABLE_SET_V1 record.)
5. The VARIABLE_ARRAY_V1 record can be encoded into an EXTENDED_RECORD payload if the number
of variable values exceeds 252.
24
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
REGISTER_SET_V1
This record is used to store a discontinuous set of 16-bit register values.
Table 27:
REGISTER_SET_V1 Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0x60
Address of register REGISTER_SET_V1
+1
Payload Length
8 bits
+2
Checksum
16 bits
Table 28:
See Table 28, REGISTER_SET_V1 Payload Format.
–
Dependent on payload.
REGISTER_SET_V1 Payload Format
Byte Offset
Field
Size
+0
Address0
16 bits
Value
Description
Address of register. Must be 16-bit aligned.
+2
Value0
16 bits
+4
Address 1
16-bits
–
Register value
Address of register. Must be 16-bit aligned.
+6
Value1
16 bits
Register value
+(Payload Length - 4)
Address n
16 bits
Address of register. Must be 16-bit aligned.
+(Payload Length - 2)
Value n
16 bits
Register value
…
Notes:
AND9333/D Rev. 1, Pub. 11/15
1. The number of register address/value pairs in the record is: (Payload Length / 4)
2. The REGISTER_SET_V1 record can be encoded into an EXTENDED_RECORD payload if the number of
register values exceeds 63.
25
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
REGISTER_MASKED SET_V1
This record is used to store a discontinuous array (range) of 16-bit register values.
Table 29:
REGISTER_MASKED SET_V1 Header Format
Byte Offset
+0
Field
Record Type
Size
Value
Description
8 bits
0x61
REGISTER_MASKED_SET_V1
+1
Payload Length
8 bits
+2
Checksum
16 bits
Table 30:
See Table 30, REGISTER_MASKED SET_V1 Payload Format.
–
Dependent on payload.
REGISTER_MASKED SET_V1 Payload Format
Byte Offset
Field
Size
Value
Description
+0
Address 0
16 bits
+2
Mask [0]
16 bits
Address of register. Must be 16-bit aligned.
+4
Value[0]
16 bits
Register value
+6
Address 1
16 bits
Address of register. Must be 16-bit aligned.
+8
Mask [1]
16 bits
+10
Value[1]
16 bits
Register value
+(Payload Length - 6)
Address_n
16 bits
Address of register Must be 16-bit aligned.
+(Payload Length - 4)
Mask_n
16 bits
Bit field mask
+(Payload Length - 2)
Value_n
16 bits
Register value
–
–
Bit field mask
Bit field mask
…
Notes:
AND9333/D Rev. 1, Pub. 11/15
1. The firmware performs the following operation on each address/mask/value tuple:
uint16 tmp = *((uint16*)(Address));
tmp &= ~(Mask);
tmp |= (Value)
*((uint16*)(Address)) = tmp;
2. Any bits set within the Value field which are not included within the Mask field will be logically
ORed into the existing value at Address.
3. The number of register address/mask/value tuples in the record is: (Payload Length / 6)
4. The REGISTER_MASKED_SET_V1 record can be encoded into an EXTENDED_RECORD payload if the
number of register values exceeds 42.
26
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
VARIABLE_SET_V1
This record is used to store a discontinuous set of varying-size variable values.
Table 31:
VARIABLE_SET_V1 Header Format
Byte Offset
Field
Size
Value
+0
Record Type
8 bits
0x70
+1
Payload Length
8 bits
–
See Table 32, VARIABLE_SET_V1 Payload Format.
+2
Checksum
16 bits
–
Dependent on payload.
Table 32:
Description
VARIABLE_SET_V1
VARIABLE_SET_V1 Payload Format
Byte Offset
Field
Size
Value
Page+Offset_0
16 bits
0...9: Offset
10...14: Page
15: Reserved
Identifies firmware variable page (logical ID) and offset of
variable (within page)
Type_0
8 bits
8 = UINT8
16 = UINT16
32 = UINT32
Identifies type of variable
+0
+2
Description
+3
Pad_0
8 bits
Padding for alignment
+4
Value_0
32 bits
Variable value
Page+Offset_1
16 bits
+10
Type_1
8 bits
Identifies type of variable
+11
Pad_1
8 bits
Padding for alignment
+12
Value_1
32 bits
Variable value
Page+Offset_n
16 bits
Identifies firmware variable page (logical ID) and offset of
variable (within page)
Type_n
8 bits
Identifies type of variable
+8
0...9: Offset
10...14: Page
15: Reserved
Identifies firmware variable page (logical ID) and offset of
variable (within page)
…
+(PayloadSize-8)
+(PayloadSize-6)
+(PayloadSize-5)
Pad_n
8 bits
Padding for alignment
+(PayloadSize-4)
Value_n
32 bits
Variable value
Notes:
1. For description of the 'Page + Offset' fields, see “VARIABLE_ARRAY_V1” on page 24.
2. When updating a variable's value, the firmware uses the TYPE_n field to determine the type of the
variable, and therefore the size of the value encoded in the record. The firmware will perform the
following operations:
TYPE_n
UINT8
UINT16
UINT32
Operation
*((uint8*)(PageTab[Page] + Offset)) = (uint8)Value
*((uint16*)(PageTab[Page] + Offset)) = (uint16)Value
*((uint32*)(PageTab[Page] + Offset)) = (uint32)Value32
3. The VARIABLE_SET_V1 record can be encoded into an EXTENDED_RECORD payload if the number of
variable value pairs exceeds the standard record permitted payload size.
AND9333/D Rev. 1, Pub. 11/15
27
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
VARIABLE_MASKED_SET_V1
This record is used to store a discontinuous set of varying-size variable bit field values.
Table 33:
VARIABLE_MASKED_SET_V1 Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0x71
VARIABLE_MASKED_SET_V1
+1
Payload Length
8 bits
-
See Table 34, VARIABLE_MASKED_SET_V1 Payload Format
+2
Checksum
16 bits
-
Dependent on payload.
.
VARIABLE_MASKED_SET_V1 Payload Format
Table 34:
Byte Offset
Field
Size
Value
Description
+0
Page+Offset_0
16 bits
0..9: Offset
10..14: Page
15: Reserved
Identifies firmware variable page (logical ID) and offset of
variable (within page).
+2
Type_0
8 bits
8: UINT8
16: UINT16
32: UINT32
Identifies type of variable.
+3
Pad_0
8 bits
Padding for alignment.
+4
Mask_0
32 bits
Bit field mask.
+8
Value_0
32 bits
Variable value.
+12
Page+Offset_1
16 bits
+14
Type_1
8 bits
Identifies type of variable.
+15
Pad_1
8 bits
Padding for alignment.
+16
Mask_1
32 bits
Bit field mask.
+20
Value_1
32 bits
Variable value.
+(PayloadSize-12)
Page+Offset_n
16 bits
Identifies firmware variable page (logical ID) and offset of
variable (within page).
+(PayloadSize-10)
Type_n
8 bits
Identifies type of variable.
+(PayloadSize-9)
Pad_n
8 bits
Padding for alignment.
+(PayloadSize-8)
Mask_n
32 bits
Bit field mask.
+(PayloadSize-4)
Value_n
32 bits
Variable value
0..9: Offset
10..14: Page
15: Reserved
Identifies firmware variable page (logical ID) and offset of
variable (within page).
...
Notes:
1. For a description of the Page + Offset fields, see VARIABLE_ARRAY_V1.
2. When updating a variable’s value, the firmware uses the TYPE_n field to determine the type of the
variable, and therefore the size of the value encoded in the record. The firmware will perform the
following operations:
TYPE_n
UINT8
AND9333/D Rev. 1, Pub. 11/15
Operation
uint8 val = *((uint8*)(PageTab[Page] + Offset))
val &= ~(uint8)Mask
val |= (uint8)Value
*((uint8*)(PageTab[Page] + Offset)) = val
28
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
TYPE_n
UINT16
Operation
uint16 val = *((uint16*)(PageTab[Page] + Offset))
val &= ~(uint16)Mask
val |= (uint16)Value
*((uint16*)(PageTab[Page] + Offset)) = val
UINT32
uint32 val = *((uint32*)(PageTab[Page] + Offset))
val &= ~Mask
val |= Value
*((uint32*)(PageTab[Page] + Offset)) = val
3. Any bits set within the Value field which are not included within the Mask field will be logically
ORed into the existing value at the resultant address.
4. The type of the variable must be correct for the variable being written - that is, a write to an 8-bit
variable must be encoded as a UINT8.
5. The VARIABLE_MASKED_SET_V1 record can be encoded into an EXTENDED_RECORD payload if the
number of variable value pairs exceeds the standard record permitted payload size.
AND9333/D Rev. 1, Pub. 11/15
29
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
REGISTER_INIT_V1
This record is used to store a fixed (initialization) value throughout a contiguous array
(range) of 16-bit register values.
Table 35:
REGISTER_INIT_V1 Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0x41
REGISTER_INIT_V1
+1
Payload Length
8 bits
0x06
See Table 36, REGISTER_INIT_V1 Payload Format.
+2
Checksum
16 bits
–
Table 36:
Dependent on payload.
REGISTER_INIT_V1 Payload Format
Byte Offset
Field
Size
+0
Start address
16 bits
+2
Length
16 bits
+4
Value
16 bits
Note:
AND9333/D Rev. 1, Pub. 11/15
Value
Description
The first register address. Value[0] will be written to this address.
Must be 16-bit aligned.
–
Number of registers to initialize
Fixed value to initialize all registers
The REGISTER_INIT_V1 record is intended to support initialization of a range of registers to a fixed
value (for example, zero).
30
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
VARIABLE_INIT_V1
This record is used to store a fixed (initialization) value throughout a contiguous array
(range) of 8-bit variable values.
Table 37:
VARIABLE_INIT_V1 Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0x51
VARIABLE_INIT_V1
+1
Payload Length
8 bits
+2
Checksum
16 bits
Table 38:
See Table 38, VARIABLE_INIT_V1 Payload Format.
–
Dependent on payload.
VARIABLE_INIT_V1 Payload Format
Byte Offset
Field
Size
Value
+0
Page + Offset
16-bits
+2
Length
16-bits
0..9: offset
10..14: page
15: reserved
–
+4
Value
8-bits
Notes:
AND9333/D Rev. 1, Pub. 11/15
Description
Identifies firmware variable page (ID) and offset of variable
within page.
Number of bytes to initialize
Fixed value to initialize all bytes
1. When applying the variable settings, the firmware effectively performs a byte-wise memory-set
from NVM to the specified variable page + offset.
2. For a description of the Page + Offset fields, see VARIABLE_ARRAY_V1.
31
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
COMMAND_V1
This record is used to store a single Host Command.
Table 39:
COMMAND_V1 Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0xB1
COMMAND_V1
+1
Payload Length
8 bits
+2
Checksum
16 bits
Table 40:
See Table 40, COMMAND_V1 Payload Format.
-
Dependent on payload.
COMMAND_V1 Payload Format
Byte Offset
Field
Size
Value
+0
Host command
16 bits
–
Description
The host command
+2
Pad
16 bits
–
Padding for alignment
+4
Command params
128 bits
–
Parameters of the command (command-specific)
Notes:
AND9333/D Rev. 1, Pub. 11/15
1. The Host Command encoding is detailed in the Host Command Interface Specification.
2. Although each Host Command has specific parameters of variable length, the record encoding
assumes the worse case. This simplifies the parsing requirements for the firmware, on the assumption that sufficient space exists in the SPI NVM device.
32
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
PATCH_V1
This record is used to store a firmware patch.
Table 41:
PATCH_VI Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0x80
+1
Payload Length
8 bits
-
See Table 42, PATCH_VI Payload Format
+2
Checksum
16 bits
-
Dependent on payload.
Table 42:
PATCH_V1
PATCH_VI Payload Format
Byte Offset
Field
Size
Value
Description
+0
Load address
16 bits
–
The load address of the patch (in Patch RAM). Must be 16-bit
aligned.
+2
Loader address
16 bits
–
The address of the loader component of the patch. (The
loader is invoked by the Patch Loader). Must be 16-bit
aligned.
+4
Firmware ID
32 bits
–
Firmware ROM version identifier
+8
Patch ID
16 bits
–
Unique patch identifier
+10
Byte[0]
8 bits
–
First byte of patch
+11
Byte[1]
8 bits
–
Next byte of patch
Byte[n]
8 bits
…
+(Payload Length - 10)
Notes:
AND9333/D Rev. 1, Pub. 11/15
Last byte of patch
1. Patches are interpreted as a byte array within the record.
2. Patches are copied from NVM to Load address in Patch RAM by the Patch Loader. The loader performs a byte-wise memory copy, then invokes the patch entry point function loader (which must be
located at entry point address).
3. The Load address and Entry point address fields in the record payload are specified as 16-bit offsets
from the base of the Patch RAM; these are not absolute addresses.
4. The Firmware ID field is used by the Patch Loader to verify that the patch is appropriate for the ROM
firmware. Any attempt to load a patch with an incorrect encoded firmware version will be rejected.
5. The Patch ID field is used to provide a unique identifier for the patch. Note that no enforcement of
unique identifiers is provided by the firmware.
6. The PATCH_V1 record can be encoded into an EXTENDED_RECORD payload if the patch code exceeds
246 bytes
33
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
OVERLAY_BITMAP_V1
This record is used to store a compressed bitmap (without cropping support). Note that
as a compressed bitmap can extend to 2048 bytes, this record may need to be encoded
within an EXTENDED_RECORD(see “Appendix C: Extended Record Encoding Example” on
page 42 for an example).
Table 43:
OVERLAY_BITMAP_V1 Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0x90
+1
Payload Length
8 bits
-
See Table 44, OVERLAY_BITMAP_V1 Payload Format
+2
Checksum
16 bits
-
Dependent on payload.
Table 44:
OVERLAY_BITMAP_V1
OVERLAY_BITMAP_V1 Payload Format
Byte Offset
Field
Size
Value
Description
+0
Blink interval
8 bits
+1
8 bits
+2
Timeout
interval
Size
0
1 - 255
0
1 - 255
16 bits
+4
Image Control
8 bits
+5
+6
Pad
LengthX
8 bits
16 bits
No blinking
Blinking interval in multiples of 5 frames.
No timeout
Timeout interval in multiples of 5 frames.
Size of the bitmap data (in bytes) - including the RLE
header fields.
0: No calibration applied to offset
1: Offset subject to calibration
Should be 0
Padding to force 16-bit alignment of 16-bit values.
Horizontal length of the image.
+8
LengthY
16 bits
+10
OffsetX
16 bits
+12
OffsetY
16 bits
+14
+18
+22
+26
+30
+34
+38
+42
+46
+50
+54
+58
…
Color0LUT
Color1LUT
Color2LUT
Color3LUT
Color4LUT
Color5LUT
Color6LUT
Color7LUT
RLE_LUT0
RLE_LUT1
RLE_LUT2
RLE_DATA
32 bits
32 bits
32 bits
32 bits
32 bits
32 bits
32 bits
32 bits
32 bits
32 bits
32 bits
–
Note:
AND9333/D Rev. 1, Pub. 11/15
Bit 0: Calibration Enable
Bit 1..7: Reserved
0
Bit 0..8: LengthX
Bit 9..15: Reserved
Bit 0..9: LengthY
Bit 10..15: Reserved
Bit 0..8: OffsetX
Bit 9..15: Reserved
Bit 0..9: OffsetY
Bit 10..15: Reserved
See “Color Encoding” on page 7.
See “Color Encoding” on page 7.
See “Color Encoding” on page 7.
See “Color Encoding” on page 7.
See “Color Encoding” on page 7.
See “Color Encoding” on page 7.
See “Color Encoding” on page 7.
See “Color Encoding” on page 7.
See “Color Encoding” on page 7.
See “Color Encoding” on page 7.
See “Color Encoding” on page 7.
–
–
Vertical height of the image.
Horizontal offset of image (from top left corner) before calibration.
Vertical offset of image (from top left corner) before calibration.
LUT for color index 0
LUT for color index 1
LUT for color index 2
LUT for color index 3
LUT for color index 4
LUT for color index 5
LUT for color index 6
LUT for color index 7
RLE LUT 0
RLE LUT 1
RLE LUT 2
The run-length encoded bitmap.
The bitmap header encoding from offset +4 within the payload is identical to the underlying overlay buffer encoding. This allows DMA transfer of the header and bitmap from NVM directly to the
overlay buffer without firmware processing.
34
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
OVERLAY_BITMAP_V2
This record is used to store a compressed bitmap (with cropping support). Note that as a
compressed bitmap can extend to 2048 bytes, this record may need to be encoded
within an EXTENDED_RECORD (see “Appendix C: Extended Record Encoding Example”
on page 42 for an example).
Table 45:
OVERLAY_BITMAP_V2 Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0x91
OVERLAY_BITMAP_V2
+1
Payload Length
8 bits
-
See Table 46, OVERLAY_BITMAP_V2 Payload Format.
+2
Checksum
16 bits
-
Dependent on payload.
Table 46:
OVERLAY_BITMAP_V2 Payload Format
Byte Offset
Field
Size
Value
Description
+0
Blink interval
8 bits
0
No blinking
+1
Timeout interval
8 bits
+2
Size
16 bits
+4
CropLengthX
16 bits
+6
CropLengthY
16 bits
+8
CropOffsetX
16 bits
+10
CropOffsetY
+12
1 - 255
0
Blinking interval in multiples of 5 frames
No timeout
1- 255
Timeout interval in multiples of 5 frames
Size of the bitmap data (in bytes) including the RLE
header fields.
Bit 0..8: LengthX
Bit 9..15: Reserved
Bit 0..9: LengthY
Bit 10..15: Reserved
Bit 0..8: OffsetX
Bit 9..15: Reserved
Horizontal offset of crop region (relative to top left
corner of image)
16 bits
Bit 0..9: OffsetY
Bit 10..15: Reserved
Vertical offset of crop region (relative to top left
corner of image)
Reserved0
16 bits
0
+14
Reserved1
16 bits
0
+16
Reserved2
16 bits
0
+18
Image Control
8 bits
Bit 0: Calibration Enable
Bit 1: Crop Enable
Bit 2: Crop Out
Bit 3..7: Reserved
+19
Pad
8 bits
0
+20
LengthX
16 bits
+22
LengthY
16 bits
+24
OffsetX
16 bits
Bit 0..8: LengthX
Bit 9..15: Reserved
Bit 0..9: LengthY
Bit 10..15: Reserved
Bit 0..8: OffsetX
Bit 9..15: Reserved
+26
OffsetY
16 bits
AND9333/D Rev. 1, Pub. 11/15
Horizontal length of crop region
Vertical height of crop region
0: No calibration applied to offset
1: Offset subject to calibration
0: Disable cropping
1: Enable cropping
0: Crop inside of window
1: Crop outside of window
Padding to force 16-bit alignment of 16-bit values
Bit 0..9: OffsetY
Bit 10..15: Reserved
35
Horizontal length of the image
Vertical height of the image
Horizontal offset of image (from top left corner) -before calibration
Vertical offset of image (from top left corner) -before calibration
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
Table 46:
OVERLAY_BITMAP_V2 Payload Format (continued)
Byte Offset
Field
Size
Value
Description
+28
Color0LUT
32 bits
See “Color Encoding” on page 7
LUT for color index 0
+32
Color1LUT
32 bits
See “Color Encoding” on page 7
LUT for color index 1
+36
Color2LUT
32 bits
See “Color Encoding” on page 7
LUT for color index 2
+40
Color3LUT
32 bits
See “Color Encoding” on page 7
LUT for color index 3
+44
Color4LUT
32 bits
See “Color Encoding” on page 7
LUT for color index 4
+48
Color5LUT
32 bits
See “Color Encoding” on page 7
LUT for color index 5
+52
Color6LUT
32 bits
See “Color Encoding” on page 7
LUT for color index 6
+56
Color7LUT
32 bits
See “Color Encoding” on page 7
LUT for color index 7
+60
RLE_LUT0
32 bits
See “Color Encoding” on page 7
RLE LUT 0
+64
RLE_LUT1
32 bits
See “Color Encoding” on page 7
RLE LUT 1
+68
RLE_LUT2
32 bits
See “Color Encoding” on page 7
RLE LUT 2
+72
RLE_DATA
-
-
The run-length encoded bitmap.
... Note:
AND9333/D Rev. 1, Pub. 11/15
The bitmap header encoding from offset +4 within the payload is identical to the underlying overlay buffer encoding. This allows DMA transfer of the header and bitmap from NVM directly to the
overlay buffer without firmware processing.
36
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
OVERLAY_STRING_V1
This record is used to store an overlay character string.
Table 47:
OVERLAY_STRING_V1 Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0xA0
OVERLAY_STRING_V1
+1
Payload Length
8 bits
0x1C
See Table 48, OVERLAY_STRING_V1 Payload Format
+2
Checksum
16 bits
-
Table 48:
Dependent on payload.
OVERLAY_STRING_V1 Payload Format
Byte
Offset
Field
Size
Value
+0
Enable0-15
16 bits
+2
Enable16-21
16 bits
Bit 0: char 0 enable
…
Bit 15: char 15 enable
Bit 0: char 16 enable
Bit 5: char 21 enable
Bits 14..6: reserved
Bit 15: decimate
+4
CharIndex_1_0
8 bits
+5
CharIndex_3_2
8 bits
…
Description
Bit 3..0: character 0
Bit 7..4: character 1
–
Enable for character positions 0 to 15
Enable for character positions 16 to 21.
0 = No decimation
1 = Decimate by 2
Index of character for positions 0 and 1.
Index of character for positions 2 and 3.
–
+14
CharIndex_21_20
8 bits
–
+15
Reserved
8 bits
0
Index of character for positions 20 and 21.
+16
BackgroundLUT
32 bits
See “Color Encoding” on page 7.
Color LUT for background
+20
ForegroundLUT
32 bits
See “Color Encoding” on page 7.
Color LUT for foreground
+24
OffsetX
16 bits
Bit 8..0: OffsetX
Bit 15..9: Reserved
Horizontal offset of character string (from top left
corner)
+26
OffsetY
16 bits
Bit 9..0: OffsetY
Bit 15..10: Reserved
Vertical offset of character string (from top left
corner)
Note:
AND9333/D Rev. 1, Pub. 11/15
The ASX340AT firmware supports a font of 16 characters. Refer to the ASX340AT Host Command
Interface Document for details.
37
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
COMMAND_SEQ_V1
This record is used to index one or more host command (or other) records, to be
processed in sequence.
Table 49:
COMMAND_SEQ_V1 Header Format
Byte Offset
Field
Size
Value
+0
Record Type
8 bits
0xB0
+1
Payload Length
8 bits
-
See Table 50, COMMAND_SEQ_V1 Payload Format
+2
Checksum
16 bits
-
Dependent on payload.
Table 50:
Description
COMMAND_SEQ_V1
COMMAND_SEQ_V1 Payload Format
Byte Offset
Field
Size
Value
+0
Command 0
32 bits
+4
Command 1
32 bits
Address of the second
record
Command n
32 bits
Address of the last record
Description
Address of the first record Pointer to the first record in this sequence
Pointer to the second recordin this sequence
...
+(Payload Length - 4)
Notes:
AND9333/D Rev. 1, Pub. 11/15
Pointer to the final record in this sequence
1. The COMMAND_SEQ_V1 record is provided to group multiple records to be processed consecutively through the MISC_INVOKE_COMMAND_SEQ host command.
2. The ASX340AT firmware processes each record indexed by the Command Sequence record in turn,
and waits for each command to complete, before continuing to the next record
3. By default, if any command fails (returns anything but ENOERR), processing of the command
sequence is aborted.
4. The MISC_CONFIG_CMDSEQ_PROC host command allows command failures to be ignored.
5. The COMMAND_SEQ_V1 record can reference the following record types:
- REGISTER_ARRAY_V1
- REGISTER_INIT_V1
- REGISTER_SET_V1
- REGISTER_MASKED SET_V1
- VARIABLE_ARRAY_V1
- VARIABLE_MASKED_SET_V1
- VARIABLE_INIT_V1
- VARIABLE_SET_V1
- COMMAND_V1
38
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Record Types
VENDOR_SPECIFIC_nn
These are a reserved range of records provided for customer use; they are not interpreted
by the ASX340AT firmware.
Table 51:
VENDOR_SPECIFIC_nn Header Format
Byte Offset
Field
Size
Value
+0
Record Type
8 bits
0xE0-0xEF
+1
Payload Length
8 bits
–
+2
Checksum
16 bits
–
AND9333/D Rev. 1, Pub. 11/15
39
Description
VENDOR_SPECIFIC_00 VENDOR_SPECIFIC_15
Dependent on payload.
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Appendix A: Big-Endian Encoding
Appendix A: Big-Endian Encoding
All 16- and 32-bit data values are encoded in big-endian format that stores the mostsignificant data byte at the least-significant (lower) address. For example, the 16-bit
value 0x1234 would be stored in memory as:
Byte Address Offset +0x0: 0x12
Byte Address Offset +0x1: 0x34
The 32-bit value 0x12345678 would be stored in memory as:
Byte Address Offset +0x0: 0x12
Byte Address Offset +0x1: 0x34
Byte Address Offset +0x2: 0x56
Byte Address Offset +0x3: 0x78
Appendix B: Example NVM Layout
Figure 2 on page 41 shows an example SPI layout as would be generated by the NVM
Generation tool. The assumption is that the device is erased then programmed with the
generated image during manufacture/assembly of the camera subsystem (containing
the ASX340AT). The assembly is then calibrated (by a manufacturer-specific procedure),
and a calibration update written to the NVM.
The NVM Generation tool will segment the available memory into various regions as
shown in the figure. Each region contains room for more records to be added (in the
field, if necessary).
AND9333/D Rev. 1, Pub. 11/15
40
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Appendix B: Example NVM Layout
Figure 2:
Example Flash/EEPROM Memory Layout
Er ased
VEN D OR_SPEC IF IC _00
Er ased
C OM M AN D_V1
VAR IABLE_SET _V1
R EGIST ER _AR R AY_V1
C OM M AN D _V1
C om m and sequence
region
VAR IABLE_SET _V1
C OM M AN D_V1
R EGIST ER _AR R AY_V1
VAR IABLE_SET _V1
Er ased
C OM M AN D _SEQ _V1
C OM M AN D _SEQ _V1
C OM M AN D _SEQ _V1
Er ased
Overlay string region
OVER LAY _ST R IN G_V1
OVER LAY _ST R IN G_V1
Er ased
Bitm ap region
OVER LAY _BIT M AP_V 1
OVER LAY _BIT M AP_V 1
OVER LAY _BIT M AP_V 1
OVER LAY _BIT M AP_V 1
Er ased
Patch region
PAT C H_V 1
PAT C H_V 1
Overlay Initialization region
Er ased
C OM M AN D _V1
Er ased
C alibration region
VAR IABLE_SET _V1
C OM M AN D _V1
R EGIST ER _AR R AY_V1
Er ased
VAR IABLE_SET _V1
Initialization region
VAR IABLE_AR R AY_V1
R EGIST ER _SET _V1
R EGIST ER _AR R AY_V1
R EGIST ER _AR R AY_V1
Er ased
C OM M AN D_SEQ _T OC
Er ased
OVER LAY _ST R IN G_T OC
Er ased
OVER LAY_BIT M AP_T OC
Er ased
PAT C H_T OC
Er ased
IN IT_T ABLES (overlay)
Er ased
IN IT_T ABLES (patch)
Er ased
IN IT_T ABLES (calibration)
Er ased
IN IT_T ABLES (defaults)
Er ased
T OC
AND9333/D Rev. 1, Pub. 11/15
41
0x00000000
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Appendix C: Extended Record Encoding Example
Appendix C: Extended Record Encoding Example
An example of how a bitmap can be encoded into an extended record.
Table 52:
Header Format
Byte Offset
Field
Size
Value
Description
+0
Record Type
8 bits
0xFE
EXTENDED_RECORD
+1
Payload Length
8 bits
0x4
See Table 53, Payload Format
+2
Checksum
16 bits
–
Table 53:
Dependent on payload.
Payload Format
Byte
Offset
Field
Size
Value
+0
Extended Record
Type
16 bits
OVERLAY_BITMAP_V1
+2
Extended Payload
Length
16 bits
–
+4
Indicates extended payload contains an overlay
bitmap.
56 + RLE bitmap size
See Table 44,
“OVERLAY_BITMAP_V1 Payload
Format,” on page 34.
Note:
AND9333/D Rev. 1, Pub. 11/15
Description
The overlap bitmap header and RLE data.
The Checksum field must be calculated over the entire record (header, extended record, and payload).
42
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Appendix D: TOC Processing Sequence
Appendix D: TOC Processing Sequence
The ASX340AT firmware processes the TOC record 'initialization' fields at system startup. These 'init table' fields reference INIT_TABLE records, each of which in turn references the records to be processed.
The order in which these 'init tables' are processed is as follows:
1. Init Table
2. Patch Init Table
3. Calibration Table
4. Overlay Init Table
The intention is that:
• The Init Table contains a 'default' set of register, variable and commands that are used
to tune and configure every device instance.
• The Patch Init Table contains one or more patches to be automatically applied at
system start-up.
• The Calibration Table contains instance-specific calibration and configuration data
(e.g. lens position calibration and overlay calibration adjustments). Typically, the
'generic' image (for every device instance) will contain an empty Calibration Table;
that is, the Calibration Table in the TOC will point to an INIT_TABLE record with no
entries. At start-up the firmware will detect the empty table and simply skip it. If perinstance calibration data needs to be stored, the host subsequently writes a new
INIT_TABLE record immediately after the existing empty record, and then converts
the existing empty record into a NULL_RECORD. At start-up, the firmware will skip
the NULL_RECORD, then process the new INIT_TABLE containing pointers to the
per-instance calibration data.
• The Overlay Init Table can be used for general-purpose configuration, as well as
Overlay configuration. For example, typically one would encode a VARIABLE_SET_V1
record within the Overlay Init Table to set SYSMGR_CONFIG_MODE. This determines
the next action during the System Configuration phase (see Table 54).
Table 54:
.
Using SYSMGR_CONFIG_MODE to control the System Configuration Phase
SYSMGR_CONFIG_MODE
Description
2: AUTO
The firmware will use the state of sample the auto-configuration pins, configure the device according
to the state of these pins, then perform a Change-Config operation to start streaming.
3: HOST
The firmware will enter a quiescent state, waiting for the Host to configure the device via I2C.
4: CHANGE-CONFIG
The firmware will perform a Change-Config operation (applies the current configuration variables to
the sensor and SOC hardware) which will commence streaming.
AND9333/D Rev. 1, Pub. 11/15
43
©Semiconductor Components Industries, LLC, 2015.
ASX340AT: Non-Volatile Memory (NVM) Contents Encoding Specification
Appendix E: MT9V126 Rev2 to ASX340AT Changes
Appendix E: MT9V126 Rev2 to ASX340AT Changes
The changes from MT9V126 Rev2 to ASX340AT are summarized in Table 55:
Table 55:
MT9V126 Rev2 to ASX340AT Changes
Change
Description
Removed DEWARP_CONFIG_TOC and DEWARP_CONFIG_V1
records
The ASX340AT does not include a DEWARP module, so all support
has been removed
Dewarp Init Table and Dewarp Config TOC fields in the TOC
record are not supported.
These fields should be set to 0x0.
Now termed the NVM Encoding Specification
MT9V126 only supports SPI Flash device. ASX340AT extends support
to SPI EEPROM.
Appendix F: Record Quick Reference
Table 56:
Record Quick Reference
Record Type
Encoding
NULL_RECORD
0x00
EXTENDED_RECORD
END_MARKER
Record Type
Encoding
REGISTER_ARRAY_V1
0x40
0xFE
REGISTER_INIT_V1
0x41
0xFF
VARIABLE_ARRAY_V1
0x50
TOC
0xF1
VARIABLE_INIT_V1
0x51
INIT_TABLE
0xF2
REGISTER_SET_V1
0x60
PATCH_TOC
0xF3
REGISTER_MASKED SET_V1
0x61
OVERLAY_BITMAP_TOC
0xF4
VARIABLE_SET_V1
0x70
OVERLAY_STRING_TOC
0xF5
VARIABLE_MASKED_SET_V1
0x71
COMMAND_SEQ_TOC
0xF6
PATCH_V1
0x80
COMMAND_SEQ_V1
0xB0
OVERLAY_BITMAP_V1
0x90
COMMAND_V1
0xB1
OVERLAY_BITMAP_V2
0x91
OVERLAY_STRING_V1
0xA0
VENDOR_SPECIFIC_nn
0xE0-0xEF
ON Semiconductor and the ON logo are registered trademarks of Semiconductor Components Industries, LLC (SCILLC) or its subsidiaries in the United States and/or other countries. SCILLC owns the
rights to a number of patents, trademarks, copyrights, trade secrets, and other intellectual property. A listing of SCILLC’s product/patent coverage may be accessed at www.onsemi.com/site/pdf/
Patent-Marking.pdf. SCILLC reserves the right to make changes without further notice to any products herein. SCILLC makes no warranty, representation or guarantee regarding the suitability of its
products for any particular purpose, nor does SCILLC assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including
without limitation special, consequential or incidental damages. “Typical” parameters which may be provided in SCILLC data sheets and/or specifications can and do vary in different applications
and actual performance may vary over time. All operating parameters, including “Typicals” must be validated for each customer application by customer’s technical experts. SCILLC does not convey
any license under its patent rights nor the rights of others. SCILLC products are not designed, intended, or authorized for use as components in systems intended for surgical implant into the body,
or other applications intended to support or sustain life, or for any other application in which the failure of the SCILLC product could create a situation where personal injury or death may occur.
Should Buyer purchase or use SCILLC products for any such unintended or unauthorized application, Buyer shall indemnify and hold SCILLC and its officers, employees, subsidiaries, affiliates, and
distributors harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of, directly or indirectly, any claim of personal injury or death associated with such
unintended or unauthorized use, even if such claim alleges that SCILLC was negligent regarding the design or manufacture of the part. SCILLC is an Equal Opportunity/Affirmative Action Employer.
This literature is subject to all applicable copyright laws and is not for resale in any manner.
AND9333/D Rev. 1, Pub. 11/15
44
©Semiconductor Components Industries, LLC, 2015.