Infineon TLE984 Series Firmware User Manual
TLE984x
Microcontroller with LIN and Power Switches for
Automotive Applications
Firmware User Manual (AE-step)
Revision 1.02
2019-04-24
Automotive Power
TLE984x Firmware User Manual
Revision History
Microcontroller with LIN and Power Switches for Automotive Applications
Page or Item Subjects (major changes since last revision)
Revision 1.02, 2019-04-24
Error code listing updated (Appendix A)
User API routines user_nvm_write and user_nvm_write_branch, count range changed to 1128 bytes
User API user_vbg_temperature_get removed (no possible use-case)
Revision 1.01, 2016-04-05
Initial release
Firmware User Manual (AE-step) 2 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Abbreviations and Special Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Firmware Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Program Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 RAM Structure for User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 BootROM Startup procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Startup Program Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Boot Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Debug Support Mode entry (with SWD port) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 NAC Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5 User and BSL Mode Entry (UM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5.1 Unlock BSL Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5.2 Post User Mode Entry Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6 Flowcharts for User BSL / Debug Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7 Reset Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.8 Startup Procedure Submodules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.8.1 Watchdog Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.8.2 RAM Test (MBIST) and RAM Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.8.3 Analog Module Trimming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8.4 Startup Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8.5 No Activity Counter (NAC) Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8.6 LIN Node Address for Diagnostics (NAD) Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Boot Strap Loader (BSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 BSL overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1 BSL Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.2 BSL Interframe Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.3 NVM / RAM Range Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.4 LIN / FastLIN Passphrase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.5 BSL Message Parsing & Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.6 Command Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.7 Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.8 BSL Interframe timeout behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 BSL via LIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1 LIN frame format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.1.1 Command Message Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.1.2 Response Message Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1.3 Node Address for Diagnostic (NAD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1.4 Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.2 LIN Message Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.3 LIN HAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 BSL via FastLIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 BSL commands - Protocol (Version 2.0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4.1 Command 02
– RAM: Write Data/Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
H
Firmware User Manual (AE-step) 3 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
4.4.2 Command 83H – RAM: Execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4.3 Command 84
4.4.4 Command 05
4.4.5 Command 86
4.4.6 Command 87
4.4.7 Command 88
4.4.8 Command 89
4.4.9 Command 0D
4.4.10 Command 8E
4.4.11 Command 8F
4.4.12 Command 90
4.4.13 Command 91
4.4.14 Command 92
4.4.15 Command 93
4.4.16 Acknowledge Response Message (81
5 NVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1 NVM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2 NVM Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3 Data Flash Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
– RAM: Read Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
H
– NVM: Write Data/Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
H
– NVM: Execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
H
– NVM: Read Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
H
– NVM: Erase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
H
– NVM: Protection Set / Clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
H
– NVM: 100TP Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
H
– NVM: 100TP Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
H
– BSL: Option Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
H
– BSL: Option Get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
H
– LIN: NAD Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
H
– LIN: NAD Get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
H
– FastLIN: Set Session Baudrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
H
) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
H
6 User Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.1 List of Supported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2 Reentrance Capability and Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.3 Parameter Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.4 NVM Region Write Protection Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.5 Watchdog handling when using NVM functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.6 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.7 Resources used by user API functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.8 User API Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.8.1 user_nvm_mapram_init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.8.2 user_bsl_config_get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.8.3 user_bsl_config_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.8.4 user_ecc_events_get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.8.5 user_ecc_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.8.6 user_mbist_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.8.7 user_nac_get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.8.8 user_nac_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.8.9 user_nad_get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.8.10 user_nad_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.8.11 user_nvm_100tp_read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.8.12 user_nvm_100tp_write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.8.13 user_nvm_config_get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.8.14 user_nvm_password_clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.8.15 user_nvm_password_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.8.16 user_nvm_protect_get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.8.17 user_nvm_protect_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.8.18 user_nvm_protect_clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.8.19 user_nvm_ready_poll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Firmware User Manual (AE-step) 4 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
6.8.20 user_nvm_page_erase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.8.21 user_nvm_page_erase_branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.8.22 user_nvm_sector_erase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.8.23 user_nvm_write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.8.24 user_nvm_write_branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.8.25 user_ram_mbist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.8.26 user_nvm_clk_factor_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.9 NVM Protection API types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.9.1 user_callback_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.10 Data Types and Structure Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.10.1 Enumerator Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.10.1.1 BSL_INTERFACE_SELECT_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.10.1.2 NVM_PASSWORD_SEGMENT_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.10.2 Constant Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Appendix A – Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Appendix B – Stack Usage of User API Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Appendix C – BootROM User API Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Appendix D – Analog Module Trimming (100TP Pages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Appendix E – Device settings in NVM CS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Appendix F – Execution time of BootROM User API Functions . . . . . . . . . . . . . . . . . . . . . . . . . 114
Appendix G – Change of register reset values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Firmware User Manual (AE-step) 5 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
Introduction
1 Introduction
This document specifies the BootROM firmware behavior for the TLE984x microcontroller family.
The specification is organized into the following major sections:
Table 1-1 Document Content Description
Topic Description
Startup procedure BootROM Startup procedure: An overview on the Startup procedure:
the first steps executed by the BootROM after a reset
LIN and Fast LIN BSL features
NVM structure NVM: An overview on the NVM : the module used to initialize and
Boot Strap Loader (BSL): An overview on the BSL : the module used
to download and to run code from NVM and RAM
BSL commands - Protocol (Version 2.0) : Details and Commands
description
BSL via LIN (Local Interconnected Network)
BSL via FastLIN (UART via LIN)
program the NVM sectors and pages
User routines description User Routines : User routines description
1.1 Purpose
The document describes the functionality of the BootROM firmware.
1.2 Scope
The BootROM firmware for the TLE984x family will provide the following features
• Startup procedure for stable operation of TLE984x chip
• Debugger connection for proper code debug
• BSL mode for users to download and run code from NVM and RAM
• NVM operation handling, e.g. program and erase
1.3 Abbreviations and Special Terms
A list of terms and abbreviations used throughout the document is provided in “Terminology” on Page 102.
Firmware User Manual (AE-step) 6 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
ARM CORTEX-M0
BootROM
(ROM)
SRAMNVM FLASH
Serial Communication
Interfaces
(Fast-LIN (with UART
protocol) / LIN)
Timer GPT12
Watchdog WDT1
Systembus
Chip Environment
(PMU/SCU/PLL)
Overview
2 Overview
This specification includes the description of all firmware features including the operations and tasks defined
to support the general startup behaviour and various boot options.
2.1 Firmware Architecture
The BootROM in the TLE984x consists of a firmware image located inside the device’s ROM. It consists of the
startup procedure, the bootstrap loader via LIN, the bootstrap loader via Fast- LIN, NVM user routines and NVM
integrity handling routines.
The BootROM in TLE984x is located at the address 00000000
routine. The BootROM firmware is executed in the ARM Cortex CPU core and uses the SRAM for variables and
software stack.
Figure 2-1 shows the TLE984x components used during execution of the BootROM.
, and so represents the standard reset handler
H
Figure 2-1 Block Diagram of the BootROM and its Interaction with other TLE984x Components
The startup procedure is the first software-controlled operation in the BootROM that is automatically
executed after every reset. Certain startup submodules are skipped depending on the type of reset (more
details are provided in “Reset Types” on Page 14) and the error which might occur (more details are provided
in “Startup Error Handling” on Page 17).
The startup procedure includes the NVM initialisation, PLL configuration, enabling of NVM protection,
branching to the different modes and other startup procedure steps.
There are two (2) operation modes in the BootROM :
•User/BSL mode
•Debug Support mode
The deciding factor will be on the latch values of TMS and P0.0 upon a reset. During reset, these signals are
latched at the rising edge of RESET pin. Details are provided in “Boot Modes” on Page 10.
Firmware User Manual (AE-step) 7 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
Overview
2.2 Program Structure
The different sections of the BootROM provide the following basic functionality.
Startup procedure
The startup procedure is the main control program in the BootROM. It is the first software-controlled
operation in the BootROM that is executed after any reset.
The startup procedure performs initialization steps and decode the pin-latched values of the TMS and P0.0 to
determine which mode to execute.
User mode
It is used to support user code execution in the NVM address space. However, if the NVM is not protected and
the Bytes at address 11000004
If a valid user reset vector was found at 11000004
and a proper NAC value is found then the BootROM proceeds into user mode.
In case an invalid No Activity Counter value is found (see also “NAC Definition” on Page 11), the device waits
indefinitely for a FastLIN BSL communication.
-11000007H are erased (FFH), then device enters sleep mode.
H
(values at 11000004H - 11000007H not equal to FFFFFFFFH)
H
LIN BSL mode
It is used to support BSL via LIN like protocol. Downloading of code/data to RAM and NVM related
programming is supported in this mode.
FastLIN BSL mode
It is used to support BSL via FastLIN protocol. Downloading of code/data to RAM and NVM is supported in this
mode.
2.3 RAM Structure for User
With user mode entry, the entire RAM is available to the user, but upon a reset the BootROM uses parts of the
RAM for variables and for its program stack. For a reset type with no RAMBIST execution (e.g. softreset), user
data outside the BootROM reserved RAM range will not get changed.
The BootROM RAM range is defined to go from 0x1800.0000 - 0x1800.03FF
Firmware User Manual (AE-step) 8 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
SWD Debug
Mode
STARTUP_ARCHITECTURE_UM
.
Libraries
(used by all
modules)
MBIST
NVM /
CS
NVM HALRAM
Timer
Watchdog
Clock / PLL
Analog Module
Trimming
Clock / PLL
HAL
Analog Module
HAL
BootROM Startup procedure
3 BootROM Startup procedure
This chapter describes the BootROM startup procedure in TLE984x.
The startup procedure is the first software-controlled operation in the BootROM that is automatically
executed after every reset.
There are 2 operation modes in the BootROM :
•User/BSL mode
•Debug Support mode
The operation modes get selected dependent on the latch values of two (2) pins upon reset. Details are
provided in “Boot Modes” on Page 10.
For each HW module a HW abstaction layer (HAL) is implemented with its associated module specific firmware
functions called by the BootROM startup procedure.
Figure 3-1gives an overview by showing the startup code partitioning into firmware modules and the
corresponding dataflow.
Figure 3-1 Startup Procedure Architecture Overview
The startup code performs different device initialization steps.
After initialization, the BootROM either starts BSL communication (according to configuration) or jumps to
user mode code execution.
For user mode, BootROM will execute the startup procedure, redirect the vector table to the beginning of the
NVM in user accessible space (by proper setting of the VTOR register) and jump to the customer defined reset
handler routine (jump to the address pointed by the address 11000004
) to execute the user program.
H
3.1 Startup Program Structure
The first task executed by the BootROM startup procedure is to check the reset type.
The BootROM also reads the logical state of certain external Pins (see “Boot Modes” on Page 10) to decide
which initialization sub modules to be executed or to be skipped during the startup sequence.
Firmware User Manual (AE-step) 9 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
BootROM Startup procedure
A list of supported boot mode pin selections is given in “Boot Modes” on Page 10.
Many of the called initialization parts require further configuration parameters which are stored in the NVM CS
(Configuration Sector).
The initialization process differs slightly between each selected boot mode. Each boot mode has a different
set of initialization steps to be performed. For instance, some initialization steps might be skipped for one
mode but carried out for another mode.
The functional blocks are listed in Table 3-1.
Table 3-1 Functional Blocks
Block Description Reference
Watchdog Disable The WDT1 is disabled, depending on the boot mode. Section 3.8.1
RAM MBIST Performs RAM MBIST (optional).
RAM Init Inits RAM to zero (mandatory).
MapRAM Init Inits MapRAM based on MapBlock data Section 5.3
Analog Module
Trimming
Analog module NVM CS trimming values are configured in the hardware. Section 3.8.3
Section 3.8.2
PLL Init Switch system clock to PLL Section 3.5
Start NAC Timer Start a timer which is dedicated to the user mode / BSL “no activity count
timeout” calculation.
BSL BSL communication Chapter 4
Section 3.8.5
3.2 Boot Modes
The different BootROM-supported boot modes are listed in Table 3-2 “BootROM Boot Modes” on Page 10.
These boot modes are pin-latched during reset release. The mode decides which initialization parts are to be
executed by BootROM.
Table 3-2 BootROM Boot Modes
TMS /
SWD_IO
0X USER_BSL_MODE User Mode / BSL Mode
11 SWD_DEBUG_MODE Debug Support Mode with SWD port
All other values Reserved for internal use
P0.0 /
SWD_CLK
Mode / Comment
3.3 Debug Support Mode entry (with SWD port)
Debug support mode is available for SWD. The BootROM starts the overall device initialization as described in
“Startup Program Structure” on Page 9.
The BootROM then enters a waiting loop to synchronize with the debugger connected to the Serial Wire Debug
(SWD) interface. After that, the BootROM finishes the boot process and starts to execute user code under
control of the debugger.
Firmware ensures that jumping to user code in user mode entry or customer debug entry is performed with
identical RAM and SFR content, except WDT1.
Firmware User Manual (AE-step) 10 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
BootROM Startup procedure
The watchdog is always disabled in debug support mode, except when the debug error loop is entered after a
boot error.
3.4 NAC Definition
The No Activity Counter (NAC) value defines the time window after reset release within the firmware is able to
receive BSL connection messages. If no BSL messages are received on the selected BSL interface during the
NAC window and NAC time has expired the firmware code proceeds to user mode.
NAC is a byte value which describes the timeout delay with a granularity of 5 ms. The NAC timeout supports a
maximum of 140 ms.
For example:
•NAC=05
•NAC=16
After ending the start up procedure, the program will detect any activity on the LIN/ FastLIN interface for the
remaining NAC window. When noactivity is detected, the program will jump to user mode. To determine the
minimum required NAC value, the baudrate, the interframe gap and the BSL passphrase requirements need
to be taken into account. For more details, refer to “LIN / FastLIN Passphrase” on Page 20
In case a valid BSL passphrase is detected during the BSL window the firmware suspends the counting of the
WDT1 in order to avoid that requested BSL communication is broken by a WDT1 reset. The firmware will then
re-enable WDT1 before jumping to user code.
indicates a timeout delay of 25 ms (5D x 5 ms) before jumping to user mode
H
indicates a timeout delay of 110 ms (22D x 5 ms) before jumping to user mode
H
If NAC is 00
, the BSL window is closed, no BSL connection is possible and the user mode is entered without
H
delay.
If NAC is FF
, no timeout is used, BootROM code will switch off WDT1 and wait indefinitely for a BSLconnection
H
attempt.
3.5 User and BSL Mode Entry (UM)
Entry to user mode is determined by the No Activity Count (NAC) value,see “NAC Definition” on Page 11.
After waiting the time defined by the current NAC value, the startup procedure sets the VTOR register to point
to the beginning of the NVM (11000000
) and jumps to the reset handler. If a NVM double Bit error occurs when
H
reading the NAC value, the system goes into an endless loop waiting for BSL communication. Before entering
User mode (except for Hot Reset, see Figure 3-2 “Flowchart – Start BootROM” on Page 13), the system clock
frequency is switched to PLL output and to the max. frequency as stated in the datasheet. In case PLL has not
locked within 1 ms, the clock source fINTOSC/4 (20 MHz) will be used.
User mode is entered by jumping to the reset handler. This can happen directly from startup routine, after a
waiting time for possible BSL communication, or as a result of BSL commands. In all these cases, a jump to
user mode will only occur if the NVM content at 11000004
-11000007H is not FFFFFFFFH. Otherwise, the
H
BootROM executes an endless loop.
3.5.1 Unlock BSL Communications
The BootROM locks the BSL LIN and FastLIN communication after reset to avoid unexpected BSL
communication on the customer side. The host needs to unlock the communication by sending a passphrase
sequence to the BootROM.
Details about this passphrase and how it influences the NAC timeout are given in “LIN / FastLIN Passphrase”
on Page 20.
Firmware User Manual (AE-step) 11 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
BootROM Startup procedure
3.5.2 Post User Mode Entry Recommendations
Upon USER MODE entry, it is highly recommended to to perform the following checks and actions:
Prior to any NVM operation, it is recommended to implement a test of SYS_STRTUP_STS.Bit1.
If the bit is clear then the data flash mapping is consistent NVM write/erase operation can be performed. To
see if the Service Algorithm might have been active the user has to check the MEMSTAT register. If the Service
Algorithm was active the user has to expect that expected logical data flash pages are not present anymore.
The user has to take care of this and reconstruct any missing page. Furthermore it might be possible that the
Service Algorithm reports an unrecoverable failure inside the Data Flash, then the same corrective actions
shall be applied as described in the following paragraph for the case that SYS_STRTUP_STS.Bit1 is set.
If the SYS_STRTUP_STS.Bit1 is set, then the data flash mapping is inconsistent, the mapping might not be
complete and any NVM operation like write or erase is not safe and might cause further inconsistencies inside
the data flash. As corrective actions the user might reset the device (cold reset) in order to give the Service
Algorithm a chance to repair the data flash sector. If this attempt fails again, then a sector erase is needed to
reinitialize the data flash sector and to remove any mapping inconsistency. After the data flash sector has
been erased the user has to take care of reconstructing the expected logical data flash pages.
The reset source should get read from the PMU Reset Status Register (PMU_RESET_STS). Clearing
PMU_RESET_STS is strongly recommended in the user startup code, as uncleared bits can cause a wrong reset
source interpretation in the BootROM firmware after the next reset (e.g. handling a warm reset as a cold reset)
The system startup status register SCU.SYS_STRTUP_STS should get checked for any startup fails. The bit
INIT_FAIL which is a logical or of all modul status bits should get checked at least. See the TLE984xQX User’s
Manual for a detailed register description
3.6 Flowcharts for User BSL / Debug Modes
This section provides the firmware flow charts that are relevant for user and debug boot modes.
Firmware User Manual (AE-step) 12 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
STARTUP_FLOW_RESET_UM
Boot mode
select
Start
Start Timer
Cold_ Reset
OR
NVM_CS bit0 = 1
RAM MBIST
Disable W atchdo g
Ena ble debug loop
Clear Timer
Clear RAM
Warm_Rese t?
RAM test OK? RAM test OK?
Loop forev er
SWD De bu g mod e
User BSL mode
Yes
No
No
Yes
Yes
No
No
Yes
user_mode_entry
(debug = Disabled)
user_mode_entry
(debug = Enabled)
NVM_CS is
CS_NVM_RAM_MBIST
Boot mode selection is done via
TMS and P 0.0 pins :
1) 0X = USER_BSL_MODE
2) 11 = SWD_DEBUG_MODE
Ena ble Watc hdog
BootROM Startup procedure
Figure 3-2 Flowchart – Start BootROM
Firmware User Manual (AE-step) 13 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
user_mode_entry
(debug)
Hot_Reset?
BSL
Use r mode error
handling
(NVM init)
OR (NVM Pr otection)
OR (Analog module Trimm)
Error?
Clk to PLL
switch
Clear inter rupts
Time r, UART, LIN
registers reset
debug =
Enabled?
Wait for
debugger
Clear RAM
Use r code addr.
is Valid?
Re-map vector table to NVM
Loop forever
(unprotected code area)
Jump to user code
NoYes
Yes
No
Yes
No
Dev ice conf igur ation
prep ar e
Loop forever
(protec ted cod e area)
Yes
No
Init N VM
Apply NVM Protection
Analog module Trim
BootROM Startup procedure
Figure 3-3 Flowchart – User BSL Mode
3.7 Reset Types
The BootROM classifies the different hardware resets according to the following reset types:
•Cold reset
•Warm reset
•Hot reset
Firmware User Manual (AE-step) 14 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
BootROM Startup procedure
Cold reset
The reset events generated from the following sources, are classified as cold resets :
• POR : Power-on reset
•Pin reset
• Watchdog reset
•System fail
After a cold reset, all initialization steps, listed in Table 3-1 “Functional Blocks” on Page 10, are processed
in accordance with the boot mode.
Warm Reset
The reset events generated from the following sources, are classified as Warm resets :
• Sleep-exit reset
•Stop-exit reset
After a warm reset, the following initialization steps, listed in Table 3-1, are processed, except :
• RAM memory test - MBIST - (only executed if forced by NVM CS configuration, as described in “RAM Test
(MBIST) and RAM Initialization” on Page 16)
Hot Reset
The reset events generated from the following sources, are classified as Hot resets :
• Software triggered reset
• Lock-up reset
After a Hot reset, the following initialization steps, listed in Table 3-1, are processed, except :
• RAM memory test - MBIST - (only executed if forced by NVM CS configuration, as described in “RAM Test
(MBIST) and RAM Initialization” on Page 16)
• Download of analog module trimming parameters (incl. oscillator and PLL settings)
• Switch system clock to PLL output
Reset priority
In case more than one reset event occur, the post reset initialization procedure with the highest priority type
is executed. The priority is evaluated according to this priority order (where “1” is the highest priority):
1. Cold reset
2. Warm reset
3. Hot reset
Attention: The reset source is read from the PMU Reset Status Register (PMU_RESET_STS). Clearing
PMU_RESET_STS is strongly recommended in the user startup code, as uncleared bits can
cause a wrong reset source interpretation in the BootROM firmware after the next reset (e.g.
handling a warm reset as a cold reset).
See also “Post User Mode Entry Recommendations” on Page 12.
3.8 Startup Procedure Submodules
The following submodules are described in this section.
• Watchdog configuration
Firmware User Manual (AE-step) 15 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
BootROM Startup procedure
• RAM Test (MBIST) and RAM initialization
• Analog module trimming
• Startup Error Handling
• No Activity Counter (NAC) Configuration
• Node Address for Diagnostics (NAD) Configuration
3.8.1 Watchdog Configuration
After a reset, the watchdog WDT1starts with a long open window. For all the reset types, firmware startup in
user mode enables WDT1 before jumping to user code, and the watchdog cannot be disabled while user code
is being executed.
The watchdog WDT1is disabled before entering into debug mode. WDT1 continues running while waiting for
the first BSL frame. If host synchronisation is completed during the BSL waiting time (defined by NAC), WDT1
is disabled and its status is frozen.
WDT1 continues running while waiting for the first BSL frame. If host synchronisation is completed during the
BSL waiting time (defined by NAC), WDT1 is disabled and its status is frozen.
3.8.2 RAM Test (MBIST) and RAM Initialization
The RAM memory test is performed for cold reset type.
The RAM initialization is performed for cold and warm reset types.
It is possible to force a RAM test and the RAM initialization for the whole RAM range during startup regardless
of reset type. This can be done by enabling the feature using the user API function “user_mbist_set” on
Page 81. Exception for the forced test is that for WARM reset the first 1kB of the RAM will not be checked.
User_ram_mbist() must therefore be called by the user on the first 1kB RAM range to make sure RAM test and
RAM initialization is performed and no errors exist (user_ram_mbist(0x18000000, 0x180003FF) ).
When executed, the RAM MBIST test destroys the contents of the tested RAM. It consists of a linear write/read
algorithm using alternating data. RAM MBIST execution is user configurable for all reset types, see
“user_mbist_set” on Page 81.
Prior to calling MBIST to test the first 1kB of RAM, stack and variables must be moved to the already tested RAM
range above 1kB.
In case an error is detected in the RAM MBIST, the appropriate error status is captured and the device enters
an endless loop. As the watchdog is enabled when entering the endless error loop after a boot in user or
debugmode, a WDT1 cold reset is asserted after timeout and the RAM test is re-executed.
After five (5) consecutive watchdog resets, the device enters SLEEP mode (by hardware function).
The RAM initialization writes the whole RAM to zero with the proper ECC status. This is needed to prevent an
ECC error during user code execution due to a write operation to a non initialized location (with invalid ECC
code).
Note: The standard RAM interface is disabled during MBIST test execution.
Firmware User Manual (AE-step) 16 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
BootROM Startup procedure
3.8.3 Analog Module Trimming
During analog module trimming, the trimming values of PMU, voltage regulators, LIN module, temperature
sensor, oscillator, PLLand other analog modules are read from the NVM configuration sector and written into
the respective SFR registers. In case 100TP pages with data for the trimming process contains CRC errors, the
predefined ones are used.
• 100 Time Programmable data (user data)
– User has eight 100 time programmable pages. The values of the first (page 0) and second (page 1) pages
are automatically copied into the dedicated SFR registers after every COLD or WARM reset thus
replacing the registers default reset values. The user can check them by reading the dedicated SFRs or
by reading directly the content of the page.
– This procedure allows the user to configure the ADC1 . The complete list of SFR registers is provided in
“Appendix D – Analog Module Trimming (100TP Pages)” on Page 110
– In case the first and second 100TP NVM CS (Configuration Sector) pages do not contain valid trimming
data (CRC failure), the BootROM reports error and downloads alternative backup trimming values.
For BootROM reported error handling see “Post User Mode Entry Recommendations” on Page 12.
3.8.4 Startup Error Handling
To ensure that the device is properly booted, error checking and error handling are added to the startup
procedure
For USER_BSL_MODE, the overall startup sequence ends up in an endless loop or SLEEP mode in the event
that any called submodule returns an error.
If a startup error occurs – except for double-bit errors for NVM reading – and the boot option is
USER_BSL_MODE, the device is set to a safe mode with limited access to HW resources. If the errors persist
after five (5) WDT1 triggered timeouts, the device enters SLEEP mode.
Regardless of the boot mode, the system enters an endless loop in the case of NVM double-bit errors when
reading the NVM contents.
For BootROM reported error handling see “Post User Mode Entry Recommendations” on Page 12.
Note: MON inputs must not be floating in order to prevent an unintended wakeup.
3.8.5 No Activity Counter (NAC) Configuration
A NAC timeout value is stored in the NVM CS. It is stored as a value and bit-inverted value in a dedicated
NVM CS page.
During user mode, this parameter is read from the NVM CS (Configuration Sector) and verified against the
stored inverted value. This parameter is provided as an API parameter when calling the BSL module. For
details, refer to Section 3.4.
If the NVM CS does not contain a valid NAC, a “wait forever” NAC (NAC=FF
The BootROM offers 2 user API functions to read and write NAC parameter:
• user_nac_get
) is given to the BSL module .
H
• user_nac_set
Firmware User Manual (AE-step) 17 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
BootROM Startup procedure
3.8.6 LIN Node Address for Diagnostics (NAD) Configuration
For LIN, a NAD is stored in the NVM CS (Configuration Sector). It is stored as a value and bit-inverted value in a
dedicated NVM CS (Configuration Sector) page.
During user mode, this parameter is read from the NVM CS (Configuration Sector) and verified against the
stored inverted value. The parameter is provided as an API parameter when calling the LIN BSL module. For
details, please refer to “Node Address for Diagnostic (NAD)” on Page 33.
If the NVM CS (Configuration Sector) does not contain a valid NAD, a “broadcast” NAD (NAD=FF
LIN BSL module .
The BootROM offers user APIs for reading and writing NAD parameter:
• user_nad_get
• user_nad_set
) is given to the
H
Firmware User Manual (AE-step) 18 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
BSL Protocol
BSL
FAST-LIN
Protocol
UART
HAL/Drv
Libraries
(used by all
modules)
Timer
NVM /
CS
NVM
HAL
LIN
Prot oco l
LIN
HAL/Drv
Boot Strap Loader (BSL)
4 Boot Strap Loader (BSL)
The BSL (Boot Strap Loader) module supports handling of message-based command request and response
communication over the serial LIN interface. The received command messages are parsed and executed
according to the LIN or FastLIN protocol. Details about this message protocol are given in “BSL commands -
Protocol (Version 2.0)” on Page 38.
The device supports the following serial interfaces :
- LIN
- Fast-LIN (LIN interface using the UART protocol)
Figure 4-1 shows the various software submodules in the BSL module. The shared protocol is handled on a
single protocol level that processes all messages described in “BSL commands - Protocol (Version 2.0)” on
Page 38.
Figure 4-1 BSL Architecture
All command messages are encapsulated in an interface-specific frame format. This format includes specified
parameters, such as a checksum calculation and overall message size. Also specified on this level is whether
the interface is used as a peer-to-peer connection or as a master-slave-bus communication, which includes
device node addressing. This interface-specific frame handling is implemented in the interface-specific
protocol layer (e.g. LIN protocol).
The BSL protocol layer performs the command execution based on the parsed BSL commands. This results in
programming of the NVM, NVM CS (Configuration Sector), downloading to RAM or execution of NVM/RAM
code. It also includes the aspect that some commands are blocked based on applied hardware protection or
boot mode selection.
4.1 BSL overview
In this chapter, more details about the BSL mechanisms are provided.
Firmware User Manual (AE-step) 19 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
Boot Strap Loader (BSL)
4.1.1 BSL Selector
The BootROM supports specification of a BSL interface selector in the NVM CS for user-/debug mode. This
selector parameter is read and verified by the startup routine and provided as an API call parameter to the
software module.
This interface selector can be read with the user API routine user_bsl_config_get, and can be modified with
the routine user_bsl_config_set.
4.1.2 BSL Interframe Timeout
The interframe timeout is a configuration parameter read by BootROM startup code from the NVM CS
(Configuration Sector).
Interframe timeout parameter has the same format as NAC value (1 = 1x5ms, 2 = 2x5ms ...).
The paramter value is set to 0x38, which results in a timeout value of 280ms (0x38 x 5ms).
4.1.3 NVM / RAM Range Access
Some BSL commands allow access to the NVM and some to the RAM. In BSL mode the following memory
ranges are accessible for read and write operations:
• All user accessible NVM and NVM CS pages.
• The 100TP pages
• The RAM area , apart from the BootROM global variables and stack (648 bytes from 18000178H to
180003FFH).
4.1.4 LIN / FastLIN Passphrase
The BootROM locks the BSL LIN and FastLIN communication after reset to avoid unexpected BSL
communication on the customer side. The host needs to unlock the communication by sending a passphrase
sequence to the BootROM.
A passphrase consists of two (2) consecutive frames, where each frame contains a set pattern. To unlock the
BSL communication, both passphrase frames have to be sent by the host. Any other received message within
the passphrase sequence stops the unlock sequence. The unlock procedure always restarts on receiving the
first passphrase frame.
The contents of both passphrase frames are described in Figure 4-2.
Firmware User Manual (AE-step) 20 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
BSL20_ PASSPHRASE
.
0
0x46
‚F‘
1
0x4C
‚L‘
2
3 4 5 6
0x49
‚I‘
0x4E
‚N‘
0x50
‚P‘
0x41
‚A‘
0x53
‚S‘
Passphrase Frame #1:
0
0x53
‚S‘
1
0x50
‚P‘
2
3 4 5 6
0x48
‚H‘
0x52
‚R‘
0x41
‚A‘
0x53
‚S‘
0x45
‚E‘
Passphrase Frame #2:
Boot Strap Loader (BSL)
Figure 4-2 Passphrase Content
For LIN communication, the passphrase frames are encapsulated by sync break, sync char, protected ID, NAD
and checksum byte fields. A passphrase frame is rejected in case of incorrect received NAD or checksum bytes.
For FastLIN communication, the frames are extended by the checksum byte. Details about the encapsulation
are given in Section 4.2.
The BootROM ignores and rejects all received LIN and FastLIN frames if the communication is still locked. This
rejection includes frames with valid NAD and checksum fields. It does not reply to any received passphrase
frames.
The NAC timeout stops when the communication is unlocked after receiving the second valid passphrase
frame. For more details about NAC timout, refer to Section 3.4.
4.1.5 BSL Message Parsing & Responses
The BSL protocol provides single message commands and multimessage commands. A message state
machine is implemented, which first collects all command-related messages before executing the command.
It periodically polls the underlying interface protocol layer (e.g. LIN protocol layer) to collect all frames
belonging to a BSL command.
Command Message State Machine
Figure 4-3 gives an overview of the BSL command message state machine.
Firmware User Manual (AE-step) 21 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
BSL_MSG_PARSE _STAT ES
.
Po lling N ew Messag es
(Non Data or EOT Block ) ||
(length > message length)
Data Block
EOT Block
Command
processed
Multi
Message
Command
Single
Message
Command
Multi Message Collec t Command Process
Non Header
Block
Boot Strap Loader (BSL)
Figure 4-3 BSL Command Message State Machine
The state machine starts to wait for the header block. This could be either a command which consists of a
single header block (the message type MSB bit is set) or a command that consists of multiple messages (the
message type MSB bit is zero).
For multimessage commands, all message data is collected by receiving data block messages. The last
message data is always received by an EOT block message.
The EOT block message reception initiates command parsing and execution.
The command processing includes message validation, where the message parameters are checked for
boundaries, any hardware applied protection and if this message is supported for this boot mode.
The state machine aborts the multimessage collection if the overall data bytes of all collected messages have
exceeded the maximum message data buffer length of 137 bytes (7 bytes in the header block message +
130 EOT data bytes).
For single message commands, all command-related information is already available in the header block
message. The command parsing and execution start right after receiving the message.
After command execution and after a response has been sent, the state machine returns to the header block
polling state in order to wait for the next command.
Any received message which does not fit the current state or state transmission leads to an exit from the
current state and restarting of the whole state machine.
Response Message State Machine
The command response is specific to the used serial interface. For instance, LIN slave devices only send out
response frames if a slave response header was received from the LIN bus master. Further details are
described in the interface specific protocol layer part.
Figure 4-4 gives an overview of the LIN response message state machine.
Firmware User Manual (AE-step) 22 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
BSL_MSG_R ESPONSE _PAR SE _STATES
.
(Multi Msg Command &
Error occurred) ||
(Single Msg)
Multi msg command &
No error occurred
Response data left
greater than
EOT msg size
Response data left
not gr e ate r than
EOT msg size
Send Data Msg
Send EOT Msg
Send Response
Msg
Result ResponseEOT MsgData Msg
Command ProcessedData Response
Boot Strap Loader (BSL)
Figure 4-4 LIN Response Message State Machine
Some BSL messages request read-out of data from the device. These messages expect multimessage
responses. The responses are sent out using data block and EOT block messages, where the data block
messages are only used for the data that does not fit in the EOT block message. The EOT block message is the
last message for such responses.
Other BSL messages download data or initiate code execution. They do not request reading out of any data.
These messages only reply with a status response message.
A BSL command execution replies with a status response message in the event that the command execution
fails.
Attention: The BootROM responds to each incoming command. This is either the requested data or the
response block (e.g. success or error code). Only the code execution command does not reply
with a response message.
Firmware User Manual (AE-step) 23 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
Boot Strap Loader (BSL)
4.1.6 Command Execution
The command data is checked and validated after all the message data is received. This includes that the
message parameters are checked for boundaries, any hardware-applied protection (e.g. NVM protection) and
if this message is supported for this boot mode.
The following command classes are supported:
• RAM access – RAM accesses are directly done by the BSL protocol without the use of any other submodule.
• NVM access – NVM accesses (read/write) are performed using the NVM API.
• 100TP access – 100TP accesses are performed using the NVM CS (Configuration Sector) API.
• NVM CS (Configuration Sector) access – NVM CS (Configuration Sector) accesses are performed using the
NVM CS (Configuration Sector) API.
4.1.7 Timing Constraints
The host needs to add a delay between all sent BSL command header and EOT messages. Same delay must
be add between EOT and DATA block messages.
The BootROM also requires an additional waiting time to process the full received BSL command. The
BootROM is not able to provide the response messages or able to receive new commands before this period
expires. The host must wait this length of time before sending a new command or requesting the command
response (e.g. by sending a LIN slave response header).
To give BootROM time to process each byte and CMD/DATA/EOT frame, byte and frame timing must comply to
the values shown in Table 4-1.
Table 4-1 BSL Byte and Frame Timing Limits and Highest Transfer Rate
Delay type LIN (min.) FastLIN (min.)
Between bytes 4.1 µs 3.7 µs
Between end of CMD to
start of DATA or EOT frame
Interframe Timeout 280 ms 280 ms
Host waiting time for
message processing before
asking for response
Host waiting time after
response is received until a
new frame can be sent
* There are certain BSL commands that need longer processing time. These involve NVM write/erase
operations. The host waiting time is longer before a command response can be requested or before a result is
sent back. Changing a value in an already programmed NVM page, which happen if a setting is changed,
requires the following NVM steps:
- Read the full page into the HW buffer
- Update the HW buffer with new data
- Program the page from the HW buffer
20 µs 20 µs
100 µs * n/a
20 µs 20 µs
- Erase the old page
Firmware User Manual (AE-step) 24 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
Boot Strap Loader (BSL)
Total time: 8 ms
The processing time must always be taken into account.
4.1.8 BSL Interframe timeout behavior
To keep track of BSL frame transmission violations, interframe timeout is used (described also in
Chapter 4.1.2). This chapter summarizes the different use-case scenarions where BSL frame timeouts are
applied.
BSL frame transmission timeout is handled differently and depends on:
• BSL has not received any valid host synchronization yet. In this case NAC timeout value is used for all
timeout calculations. If timeout is reached this means NAC timer expired.
• BSL has completed host synchronization. All timeouts are based on interframe timeout value. This means
wait forever for frame start and once frame reception has started, time measurement against interframe
timeout are performed.
Once host synchronization is done there are different scenarios how timeout is used.
More details are provided in Figure 4-5 related LIN communication (same concept for FastLIN) .
Note: When a LIN frame is received, its PID and NAD numbers are checked. If one of them doesn’t match, the
current frame is discarded and frame reception process is restarted with detection of break/sync
sequence.
Note: Valid host synchronization: For FLIN/LIN the full passphrase has been received before NAC expires.
Firmware User Manual (AE-step) 25 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
BSL20_LIN _IN TER FR AME_ BEHAVIOR
.
Get frame bytes
Start fra me time me asurement
Poll break/sync detection
Interframe
timeout
Status: Valid frame received
within timeout period
Received bytes
Normal frame
reception:
Interframe
timeout
Status : Timeout =>
restart break/sync
detection
No break/sync
detected:
Status: Valid frame received but
invalid length => wait interframe
timeout , then restart break /sync
detection
Invalid length :
Get frame bytes
Start fra me time me asurement
Interframe
timeout
Received bytes
Host stops
transmitting
data:
Get frame bytes
Start fra me time me asurement
Interframe
timeout
Received bytes
Frame receive
time violation :
Status: Frame receive
timeout => wait
interframe timeout ,
then restart break /
sync detection
Get frame bytes
Start fra me time me asurement
Interframe
timeout
Received bytes
Poll break/sync detection
Poll break/sync detection
Status: Timeout =>
restart break/sync
detection
Poll break/sync detection
Poll break/sync detection
Boot Strap Loader (BSL)
Figure 4-5 Handling of LIN frame timeouts
Firmware User Manual (AE-step) 26 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
LIN_PROT OCOL_LAYER
.
BSL
Protocol
LIN
Protocol
LIN
HAL
Timer
4.2 BSL via LIN
The LIN BSL is a LIN-like protocol based on LIN 2.0 (refer to LIN Specification Package documentation,
Revision 2.0, 23 September 2003).
The LIN protocol layer module handles incoming LIN frames. It forwards the given commands and requests to
the BSL protocol layer and is responsible for response message handling.
This layer calls the LIN HAL API to access the LIN hardware module for baud rate management and LIN frame
exchange (transmission & reception).
The LIN interface supports baud rate detection including the standard rates from 9.6 kbit/s to 57.6 kbit/s.
The LIN HAL is described in “LIN HAL” on Page 36.
The BSL software module periodically polls the LIN protocol layer to receive incoming frames and send out
available response frames.
The LIN protocol layer parses all incoming LIN frames, it rejects frames with wrong checksum calculation or
invalid NAD values. The checksum calculation algorithm is done according to the LIN 2.0 standard. All received
messages are given to the BSL protocol layer, which concatenates it to complete commands.
Some BSL commands are shorter than the expected LIN frame. Those frames are filled up with dummy bytes.
BootROM reads such dummy bytes during checksum validation, but it ignores them during command
processing. The dummy Bytes in both directions are always set to zero.
Figure 4-6 shows the LIN protocol layer and its interaction with other software modules.
Figure 4-6 LIN Protocol Layer
Figure 4-7 shows the interaction between Hardware and software layers for the BSL LIN mode .
Firmware User Manual (AE-step) 27 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
BSL_LIN_MODE_LAYERS
SW
HW
SFRs
Tx Rx
LIN GND_LIN
LIN Tranc ei ver
Figure 4-7 BSL LIN Mode HW/SW Layers
4.2.1 LIN frame format
For all supported modes, the command messages (see Command Message Protocol) are transmitted from
the host to the BootROM, requesting the commands to be executed. The response request messages (see
Response Message Protocol) are transmitted to check the status of the operation and to read out the data
requested (e.g. read RAM command).Upon a response request message, the requested data is sent from the
BootROM to the host.
Figure 4-8 shows the Master Request Header, Slave Response Header, Command and Response LIN frames.
The command and response LIN frames are identified as diagnostic LIN frames which have a standard 9-byte
structure.
Firmware User Manual (AE-step) 28 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
B12PHASEDETAIL
.
SYN
Break
(At least
13 bit low)
SYN
Char
55
H
Protected
ID
3C
H
Host BootROM
7 Data bytes for
Command
Checksum
(1 byte)
Master Request Header
Command
Slave Response Header
Checksum
(1 byt e)
Res ponse
SYN
Break
(At least
13 bit low)
SYN
Char
55
H
Protected
ID
7D
H
NAD
7 Data bytes for
Command
NAD
Figure 4-8 LIN mode - LIN Frames
The Master Request Header is transmitted from the host to the BootROM, followed by the command, which is
the header block. The Slave Response Header is transmitted to check the status of the operation. To save
protocol overhead, the BootROM supports multiple data block transfers, sending a Slave Response Header is
only allowed after the EOT block has been sent. Sending a Slave Response Header between data blocks will
result in a communication error. As the commands are sent one after another without waiting for any status
indication, a certain delay is required (as shown in Figure 4-9) to ensure sufficient time is provided for the
BootROM to execute the desired operations.
Figure 4-9 shows the LIN frame communication for BSL commands, where no data blocks and EOT blocks are
involved.
Firmware User Manual (AE-step) 29 Revision 1.02
2019-04-24
TLE984x Firmware User Manual
LIN_FRAM E1_UML
Host BootROM
Master Request Header
Master Request Block (Command)
Sla ve Respo nse H eader
Slave Respons e Block
<<<< Delay >>>>
Slave Response communication
is not necessa ry and can
be skipped
Delay for processing and executing BSL command is needed.
Otherwise no response is possible
LIN_FRAM E2_UML
Host BootROM
Master Request Header
Master Request Block (Command)
Sla ve Respo nse H eader
Slave Respons e Block
Slave Response communication
is not necessary and can
be skipped
Delay for processing and executing BSL command is needed.
Otherwise no response is possible
Master Request Header
Master Request Block (Da ta)
<<<< Delay >>>>
Master Request Header
Master Request Block (Da ta)
…
…
…
...
Multiple Master Request Heade r and Blocks
are sent to download the all required data.
Master Request Header
Master Request Block (EOT)
Th e la st da ta ar e alwa ys se nt
with a EOT block frame.
This EOT triggers the BootROM
command processing
and execution.
Figure 4-9 LIN Communication: Command and Response
Figure 4-10 shows the LIN frame communication for BSL commands, where data are downloaded over data
blocks and EOT blocks.
Figure 4-10 LIN Communication: Data Command and Response
Firmware User Manual (AE-step) 30 Revision 1.02
2019-04-24
Loading...