Infineon TLE984x Firmware UserManual v01 04 en

MOTIX™ TLE984xQX
Microcontroller with LIN and po wer switches for automotive

applicati ons
Firmware User Manual (AE step and UD step)
About this document

This document specifies the BootROM firmware behavior for the TLE984xQX microcontroller family.
Firmware User Manual 1 Revision 1.04

www.infineon.com 2024-01-15
MOTIX™ TLE984xQX
Microcontroller with LIN and power switches for automotive applications
Table of contents
About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table of contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Abbreviations and special terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Firmware architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Program structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 RAM structure for user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 BootROM startup procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Startup program structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Boot modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Debug Support mode entry (with SWD port) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 NAC definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5 User and BSL mode entry (UM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5.1 Unlock BSL communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5.2 Post user mode entry recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.8.2 RAM test (MBIST) and RAM initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.8.3 Analog module trimming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.8.4 Startup error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.8.5 No Activity Counter (NAC) configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.8.6 LIN Node Address for Diagnostics (NAD) configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Boot Strap Loader (BSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1 BSL overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1 BSL selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.2 BSL interframe timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.3 NVM / RAM range access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.4 LIN / FastLIN passphrase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.5 BSL message parsing and responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.6 Command execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.7 Timing constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.8 BSL interframe timeout behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 BSL via LIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1 LIN frame format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1.1 Command message protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1.2 Response message protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.1.3 Node Address for Diagnostic (NAD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1.4 Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 LIN message examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.3 LIN HAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2024-01-15
MOTIX™ TLE984xQX
4.3 BSL via FastLIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4 BSL commands - protocol (version 2.0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4.1 Command 02H – RAM: Write Data/Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4.2 Command 83H – RAM: Execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.3 Command 84H – RAM: Read Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.4 Command 05H – NVM: Write Data/Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.5 Command 86H – NVM: Execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.6 Command 87H – NVM: Read Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.7 Command 88H – NVM: Erase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.8 Command 89H – NVM: Protection Set / Clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.9 Command 0DH – NVM: 100TP Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4.10 Command 8EH – NVM: 100TP Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.11 Command 8FH – BSL: Option Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.12 Command 90H – BSL: Option Get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4.13 Command 91H – LIN: NAD Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4.14 Command 92H – LIN: NAD Get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.4.15 Command 93H – FastLIN: Set Session Baudrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4.16 Acknowledge Response Message (81H) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5 NVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1 NVM overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2 NVM write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3 Data flash initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6 User routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.1 List of supported features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2 Reentrance capability and interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.3 Parameter checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.4 NVM region write protection check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.5 Watchdog handling when using NVM functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.6 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.7 Resources used by user API functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.8 User API routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.8.1 user_nvm_mapram_init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.8.2 user_bsl_config_get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.8.8 user_nac_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.8.9 user_nad_get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.8.10 user_nad_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.8.11 user_nvm_100tp_read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.8.12 user_nvm_100tp_write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.8.13 user_nvm_config_get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.8.14 user_nvm_password_clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.8.15 user_nvm_password_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.8.16 user_nvm_protect_get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

2024-01-15
MOTIX™ TLE984xQX
6.8.17 user_nvm_protect_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.8.18 user_nvm_protect_clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.8.19 user_nvm_ready_poll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.8.20 user_nvm_page_erase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.8.21 user_nvm_page_erase_branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.8.22 user_nvm_sector_erase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.8.23 user_nvm_write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.8.24 user_nvm_write_branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.8.25 user_ram_mbist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.8.26 user_nvm_clk_factor_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.9 NVM protection API types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.9.1 user_callback_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.10 Data types and structure reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.10.1 Enumerator reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.10.1.1 BSL_INTERFACE_SELECT_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.10.1.2 NVM_PASSWORD_SEGMENT_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.10.2 Constant reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Appendix A – error codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Appendix B – stack usage of user API functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Appendix C – BootROM user API functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Appendix D – analog module trimming (100TP pages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Appendix E – device settings in NVM CS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Appendix F – execution time of BootROM user API functions . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Appendix G – change of register reset values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

2024-01-15
MOTIX™ TLE984xQX
Introduction
1 Introduction
This document specifies the BootROM firmware behavior for the TLE984xQX microcontroller family.
The specification is organized into the following major sections:
Table 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 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)
NVM structure NVM: An overview on the NVM: the module used to initialize and
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 TLE984xQX family will provide the following features:
• Startup procedure for stable operation of TLE984xQX 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 123.

2024-01-15
MOTIX™ TLE984xQX
Overview
2 Overview
This specification includes the description of all firmware features including the operations and tasks defined
to support the general startup behavior and various boot options.
2.1 Firmware architecture

The BootROM in the TLE984xQX 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 TLE984xQX is located at the address 00000000H, and so represents the standard reset handler
routine. The BootROM firmware is executed in the ARM Cortex CPU core and uses the SRAM for variables and
software stack.
Figure 1 shows the TLE984xQX components used during execution of the BootROM.
BootROM
ARM CORTEX-M0 NVM FLASH SRAM
(ROM)
Systembus
Serial Communication
Timer GPT12 Chip Environment Interfaces
Watchdog WDT1 (PMU/SCU/PLL) (Fast-LIN (with UART
protocol) / LIN)
Figure 1 Block diagram of the BootROM and its interaction with other TLE984xQX 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 16).
The startup procedure includes the NVM initialization, 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 9.

2024-01-15
MOTIX™ TLE984xQX
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 11000004H - 11000007H are erased (FFH), then device enters Sleep mode.
If a valid user reset vector was found at 11000004H (values at 11000004H - 11000007H not equal to FFFFFFFFH)
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 10), the device waits
indefinitely for a FastLIN BSL communication.
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. soft reset), user
data outside the BootROM reserved RAM range will not get changed.
The BootROM RAM range is defined to go from 18000000H - 180003FFH.

2024-01-15
MOTIX™ TLE984xQX
BootROM startup procedure
3 BootROM startup procedure

This chapter describes the BootROM startup procedure in the TLE984xQX.
The startup procedure is the first software-controlled operation in the BootROM that is automatically
executed after every reset.
There are two 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 9.
For each HW module a HW abstraction layer (HAL) is implemented with its associated module specific
firmware functions called by the BootROM startup procedure.
Figure 2 gives an overview by showing the startup code partitioning into firmware modules and the
corresponding dataflow.
Libraries
(used by all
SWD Debug
modules)
Mode
Analog Module
MBIST Clock / PLL
Trimming
Timer
NVM /
CS
Watchdog
Clock / PLL Analog Module

RAM NVM HAL
HAL HAL
. STARTUP_ARCHITECTURE_UM
Figure 2 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 11000004H) to execute the user program.

2024-01-15
MOTIX™ TLE984xQX
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 9) to decide
which initialization sub modules to be executed or to be skipped during the startup sequence.
A list of supported boot mode pin selections is given in “Boot modes” on Page 9.
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 2.
Table 2 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) Section 3.8.2
RAM Init Inits RAM to zero (mandatory)
MapRAM Init Inits MapRAM based on MapBlock data Section 5.3
Analog Module Analog module NVM CS trimming values are configured in the hardware Section 3.8.3
Trimming
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 Section 3.8.5
timeout” calculation
BSL BSL communication Chapter 4
3.2 Boot modes

The different BootROM-supported boot modes are listed in Table 3. These boot modes are pin-latched during
reset release. The mode decides which initialization parts are to be executed by BootROM.
Table 3 BootROM boot modes

TMS / P0.0 / Mode / comment
SWD_IO SWD_CLK
0 X USER_BSL_MODE User mode / BSL mode
1 1 SWD_DEBUG_MODE Debug Support mode with SWD port
All other values Reserved for internal use

2024-01-15
MOTIX™ TLE984xQX
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.
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 = 05H indicates a timeout delay of 25 ms (5D x 5 ms) before jumping to user mode
• NAC = 16H indicates a timeout delay of 110 ms (22D x 5 ms) before jumping to user mode
After ending the start up procedure, the program will detect any activity on the LIN/ FastLIN interface for the
remaining NAC window. When no activity 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 19.
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.
If NAC is 00H, the BSL window is closed, no BSL connection is possible and the user mode is entered without
delay.
If NAC is FFH , no timeout is used, BootROM code will switch off WDT1 and wait indefinitely for a BSL connection
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 10.
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 (11000000H) and jumps to the reset handler. If a NVM double Bit error occurs when
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), 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 11000004H - 11000007H is not FFFFFFFFH. Otherwise, the
BootROM executes an endless loop.

2024-01-15
MOTIX™ TLE984xQX
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 19.
3.5.2 Post user mode entry recommendations

Upon user mode entry, it is highly recommended 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 module status bits should get checked at least.
See the TLE984xQX user manual for a detailed register description.

2024-01-15
MOTIX™ TLE984xQX
3.6 Flowcharts for user BSL / debug modes

This section provides the firmware flow charts that are relevant for user and debug boot modes.
Start
NVM_CS is Start Timer

CS_NVM_RAM_MBIST
Cold_ Reset No
OR
NVM_CS bit0 = 1
Yes
RAM MBIST
Warm_Reset?
Yes
No
Clear RAM
Boot mode selection is done via
TMS and P0.0 pins :
1) 0X = USER_BSL_MODE
2) 11 = SWD_DEBUG_MODE
Enable debug loop
Boot mode
User BSL mode SWD Debug mode
select
Disable Watchdog
No No
RAM test OK? RAM test OK?
Yes Yes
user_mode_entry user_mode_entry
(debug = Disabled) (debug = Enabled)
Enable Watchdog
Clear Timer
Loop forever
Figure 3 Flowchart – start BootROM

2024-01-15
MOTIX™ TLE984xQX
user_mode_entry Init NVM

(debug) Apply NVM Protection
Analog module Trim
Device configuration
prepare
(NVM init) debug = No

OR (NVM Protection) Enabled?
OR (Analog module Trimm) No
Yes Error? Yes
Yes No Wait for

Hot_Reset? debugger
BSL
Clk to PLL
switch
Clear interrupts
No User code addr. Yes

Timer, UART, LIN is Valid?
registers reset
Re-map vector table to NVM
Clear RAM
User mode error
handling
Loop forever Loop forever

Jump to user code
(protected code area) (unprotected code area)
Figure 4 Flowchart – user BSL mode

2024-01-15
MOTIX™ TLE984xQX
3.7 Reset types

The BootROM classifies the different hardware resets according to the following reset types:
• Cold reset
• Warm reset
• Hot reset
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 2, 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 2, 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 15)
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 2, 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 15)
• 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 11.

2024-01-15
MOTIX™ TLE984xQX
3.8 Startup procedure submodules

The following submodules are described in this section:
• Watchdog configuration
• RAM test (MBIST) and RAM initialization
• Analog module trimming
• Startup error handling
• No Activity Counter (NAC) configuration
• LIN 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)). 1)
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 1 kB. 1)
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 debug
mode, a WDT1 cold reset is asserted after timeout and the RAM test is re-executed.
After five (5) 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.
1) Valid for AE step only.

2024-01-15
MOTIX™ TLE984xQX
3.8.3 Analog module trimming

During analog module trimming, the trimming values of PMU, voltage regulators, LIN module, temperature
sensor, oscillator, PLL and 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 112
– 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 11.
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 11.
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=FFH) is given to the BSL module.
The BootROM offers 2 user API functions to read and write NAC parameter:
• user_nac_get
• user_nac_set

2024-01-15
MOTIX™ TLE984xQX
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 32.
If the NVM CS (Configuration Sector) does not contain a valid NAD, a “broadcast” NAD (NAD=FFH) is given to the
LIN BSL module.
The BootROM offers user APIs for reading and writing NAD parameter:
• user_nad_get
• user_nad_set

2024-01-15
MOTIX™ TLE984xQX
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 37.
The device supports the following serial interfaces:
• LIN
• Fast-LIN (LIN interface using the UART protocol)
Figure 5 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 37.
BSL Libraries
(used by all
BSL Protocol modules)
LIN FAST-LIN NVM /

Protocol Protocol CS
LIN UART NVM

Timer
HAL/Drv HAL/Drv HAL
Figure 5 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 commander-responder-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.

2024-01-15
MOTIX™ TLE984xQX
4.1 BSL overview

In this section, more details about the BSL mechanisms are provided.
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 = 1 x 5 ms, 2 = 2 x 5 ms, ...).
The parameter value is set to 0x38, which results in a timeout value of 280 ms (0x38 x 5 ms).
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 6.

2024-01-15
MOTIX™ TLE984xQX
Passphrase Frame #1:
0 1 2 3 4 5 6
0x46 0x4C 0x49 0x4E 0x50 0x41 0x53

‚F‘ ‚L‘ ‚I‘ ‚N‘ ‚P‘ ‚A‘ ‚S‘
Passphrase Frame #2:
0 1 2 3 4 5 6
0x53 0x50 0x48 0x52 0x41 0x53 0x45

‚S‘ ‚P‘ ‚H‘ ‚R‘ ‚A‘ ‚S‘ ‚E‘
. BSL 20_ PASSPHRASE
Figure 6 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 timeout, refer to Section 3.4.

2024-01-15
MOTIX™ TLE984xQX
4.1.5 BSL message parsing and responses

The BSL protocol provides single message commands and multi-message 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 7 gives an overview of the BSL command message state machine.
Non Header
Block
Command
Polling New Messages processed
(Non Data or EOT Block) ||

(length > message length)
Single
Message
Multi
Command
Message
Command
Multi Message Collect Command Process
EOT Block
Data Block
. BSL _MSG_PARSE _STATES
Figure 7 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 multi-message 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 multi-message 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.

2024-01-15
MOTIX™ TLE984xQX
Response message state machine

The command response is specific to the used serial interface. For instance, LIN responder devices only send
out response frames if a responder response header was received from the LIN bus commander. Further
details are described in the interface specific protocol layer part.
Figure 8 gives an overview of the LIN response message state machine.
Send Data Msg

Multi msg command &
No error occurred
Data Response Command Processed
Response data left Response data left (Multi Msg Command &
greater than not greater than Error occurred) ||
EOT msg size EOT msg size (Single Msg)
Data Msg EOT Msg Result Response
Send Response
Send EOT Msg
Msg
. BSL _MSG_RESPONSE _PARSE _STATES
Figure 8 LIN response message state machine
Some BSL messages request read-out of data from the device. These messages expect multi-message
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.

2024-01-15
MOTIX™ TLE984xQX
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 responder 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.
Table 4 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 20 µs 20 µs
Interframe timeout 280 ms 280 ms
Host waiting time for message processing before asking for response 100 µs *) n/a
Host waiting time after response is received until a new frame can be sent 20 µs 20 µs
*) 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
• Erase the old page
Total time: 8 ms
The processing time must always be taken into account.

2024-01-15
MOTIX™ TLE984xQX
4.1.8 BSL interframe timeout behavior

To keep track of BSL frame transmission violations, interframe timeout is used (described also in
Section 4.1.2). This section summarizes the different use-case scenarios 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 9 related LIN communication (same concept for FastLIN).
Notes
1. When a LIN frame is received, its PID and NAD numbers are checked. If one of them does not match, the current
frame is discarded and frame reception process is restarted with detection of break/sync sequence.
2. Valid host synchronization: For FLIN/LIN the full passphrase has been received before NAC expires.

2024-01-15
MOTIX™ TLE984xQX
Poll break/sync detection

Start frame time measurement
Normal frame Interframe
reception: Get frame bytes timeout
Received bytes
Status: Valid frame received
within timeout period
No break/sync Poll break/sync detection

Interframe
detected: timeout
Status: Timeout =>

restart break /sync
detection

Interframe
Invalid length : Get frame bytes timeout
Received bytes Status: Valid frame received but

invalid length => wait interframe
timeout , then restart break /sync
detection

Host stops
transmitting
Interframe
Get frame bytes timeout
data:
Status: Timeout =>
Received bytes
restart break /sync
detection

Frame receive Interframe
time violation : Get frame bytes timeout
Status: Frame receive
timeout => wait
Received bytes
interframe timeout ,
then restart break /
sync detection
. BSL 20_LIN_INTERFRAME_ BEHAVIOR
Figure 9 Handling of LIN frame timeouts

2024-01-15
MOTIX™ TLE984xQX
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 and 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 35.
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 10 shows the LIN protocol layer and its interaction with other software modules.
BSL
Protocol
LIN
Timer
Protocol
LIN
HAL
. LIN_PROTOCOL_LAYER
Figure 10 LIN protocol layer
Figure 11 shows the interaction between hardware and software layers for the BSL LIN mode.

2024-01-15
MOTIX™ TLE984xQX
SW
SFRs HW
Tx Rx
LIN Tranceiver
LIN GND_LIN
BSL_LIN_MODE_LAYERS
Figure 11 BSL LIN mode HW/SW layers
4.2.1 LIN frame format

For all supported modes, the command messages (see “Command message protocol” on Page 30) are
transmitted from the host to the BootROM, requesting the commands to be executed. The response request
messages (see “Response message protocol” on Page 31) 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 12 shows the Commander Request Header, Responder 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.

2024-01-15
MOTIX™ TLE984xQX
Host BootROM
Commander Request Header Command
SYN
SYN Protected
Break 7 Data bytes for Checksum
Char ID NAD
(At least Command (1 byte)
55H 3CH
13 bit low)
Responder Response Header
SYN
SYN Protected
Break
Char ID
(At least
55H 7DH
13 bit low)
Response
7 Data bytes for Checksum

NAD
Command (1 byte)
. B12PHASEDETAILS
Figure 12 LIN mode - LIN frames
The Commander Request Header is transmitted from the host to the BootROM, followed by the command,
which is the header block. The Responder Response Header is transmitted to check the status of the
operation. To save protocol overhead, the BootROM supports multiple data block transfers, sending a
Responder Response Header is only allowed after the EOT block has been sent. Sending a Responder
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 13) to
ensure sufficient time is provided for the BootROM to execute the desired operations.
Figure 13 shows the LIN frame communication for BSL commands, where no data blocks and EOT blocks are
involved.

2024-01-15
MOTIX™ TLE984xQX
Host BootROM
Commander Request Header
Commander Request Block (Command)

Delay for processing and executing BSL command is needed.
Otherwise no response is possible
<<<< Delay >>>>

Responder Response communication
is not necessary and can
Responder Response Block be skipped
LIN_ FRAME1_ UML
Figure 13 LIN communication: command and response
Figure 14 shows the LIN frame communication for BSL commands, where data are downloaded over data
blocks and EOT blocks.
Host BootROM

Multiple Commander Request Header and Blocks
Commander Request Block (Data) are sent to download the all required data
…
… The last data are always sent
… with a EOT block frame .
This EOT triggers the BootROM
...
command processing
Commander Request Header and execution
Commander Request Block (Data)
Commander Request Block (EOT)

<<<< Delay >>>> Otherwise no response is possible

Responder Response communication
Responder Response Block is not necessary and can
be skipped
LIN_ FRAME2_ UML
Figure 14 LIN communication: data command and response

2024-01-15
MOTIX™ TLE984xQX
Figure 15 shows the LIN frame communication for BSL commands, where data are read from the device.
BootROM provides such data over data blocks and EOT blocks.
Host BootROM
<<<< Delay >>>>

Otherwise no response is possible
Responder Response Block (Data)
…
… Multiple Responder Response Header are sent by the Host,
where BootROM replies with Data Blocks.
…
These Data Blocks contain the required data.
...
Responder Response Block (Data)

BootROM sends the last
Responder Response Header Bytes always with an EOT
packet.
Responder Response Block (EOT)
LIN_ FRAME3_ UML
Figure 15 LIN communication: request command and data response
4.2.1.1 Command message protocol

This section describes the Commander Request Header and the Commander Request Block which are sent
by the host for each LIN command frame. The Commander Request Header contains synchronization bytes to
detect the start of a frame and to detect the baud rate.
Synch Char Protected ID Commander Request Block

Synch Break
(1 byte) (1 byte) (9 byte)
COMMANDER_ REQUEST_ HEADER
Table 5 Commander Request Header field description

Field Description
Synch Break At least 13 bits must be low
Synch Char Always 55H
Protected ID Always 3CH
Commander Commands as described in “Commander Request Block” on Page 31.
Request Block

2024-01-15
MOTIX™ TLE984xQX
Commander Request Block

A simple protocol is defined for the communication between the host and BootROM. The Commander Request
Header is followed by the Commander Request Block.
NAD BSL Protocol Block Checksum

(1 byte) (7 bytes) (1 byte)
. LIN_ FRAME_FORMAT
Table 6 Commander Request Block field description

Field Description
NAD Node Address for Diagnostic, specifies the address of the active responder node.
See Section 4.2.1.3
BSL Protocol Block This field determines the type of the BSL message.
The size of this block is always 7 Bytes. The block is filled up with dummy Bytes (zeros) in
case the BSL message is smaller
Checksum This checksum is calculated based on the NAD and BSL protocol block.
See Section 4.2.1.4
4.2.1.2 Response message protocol

The BootROM reply is sent to the host only when a Responder Response Header frame is received. The
BootROM reply is always sent in a transfer block of 9 bytes (consisting of Responder Response Header and
Responder Response Block).
This header is sent by the host to initiate that the BootROM sends a Responder Response Block.
Synch Char Protected ID

Synch Break
(1 byte) (1 byte)
RESPONDER _ RESPONSE_ HEADER
Table 7 Responder Response Header field description

Field Description
Synch Break At least 13 bits must be low
Synch Char Always 55H
Protected ID Always 7DH
Responder Response Block
NAD BSL Protocol Data/EOT/Response Block Checksum

(1 byte) (7 bytes) (1 byte)
. LIN_RESPONSE _FORMAT

2024-01-15
MOTIX™ TLE984xQX
Table 8 Responder Response Block field description

Field Description
NAD Node address for diagnostics, specifies the address of the active responder node
BSL Protocol This field determines the type of the BSL message.
Data/EOT/Response Depending on the BSL command used, it could be either a data block, an EOT block or
Block a response block
Checksum The checksum is calculated based on NAD, Response and Response Data bytes. All
responses sent by the BootROM adopts the classic checksum. See Section 4.2.1.4
4.2.1.3 Node Address for Diagnostic (NAD)

This field specifies the address of the active responder node (only responder nodes have a NAD address). Each
Commander Request Block contains a NAD field. Table 9 lists the BootROM-supported NAD address range.
The used NAD parameter is given as a BSL API parameter (for details see also “User and BSL mode entry
(UM)” on Page 10).
Table 9 NAD address range

NAD Value Description
00H to 7FH Invalid responder address
80H to FFH Valid responder address
FFH Broadcast address.
Default address (NAD value is invalid or it is not programmed)
Note: The LIN block with the standard LIN broadcast NAD (7FH) is ignored.
The firmware treats a received BSL message with NAD value of FFH as 'broadcast' message. BSL responds to
this no matter which NAD value is stored inside the NVM CS. A device with an invalid NAD value in NVM CS only
responds to a BSL 'broadcast' message.
4.2.1.4 Checksum
The checksum contains the inverted eight-bit sum with a carry over all data bytes. Data bytes are defined as
all bytes in the LIN frame excluding the protected ID byte.
Checksum calculation over the data bytes only is referred to as a classic checksum. An eight-bit sum with carry
is equivalent to the sum of all values, subtracted by 255 every time the sum is greater than or equal to 256.
Enhanced checksums are normally used for LIN 2.x devices, but frame identifiers (PID) 3CH always uses the
classic checksum.
The checksum is the last field of Command and Response LIN frames.

2024-01-15
MOTIX™ TLE984xQX
4.2.2 LIN message examples

Figure 16 and Figure 17 provide some examples of how to write and read RAM using LIN BSL commands.
Host
BootROM
Commander Request Write RAM Data
Header &
Header Block: SYN 0x55 0x3C NAD Length *) 0x02 Address *) Res Num*) CHKS
<<< Delay >= BSL frame processing time >>>

Data Block: SYN 0x55 0x3C NAD Length *) 0x00 Data Bytes*) CHKS
…
<<< Multiple Data Blocks >>>
...
Data Block: SYN 0x55 0x3C NAD Length *) 0x00 Data Bytes*) CHKS
<<< Delay >= BSL frame processing time >>>
EOT Block: SYN 0x55 0x3C NAD Length *) 0x80 Data Bytes*) CHKS
<<< Delay >= BSL command processing time >>>
Responder Response Header: SYN 0x55 0x7D

<<< Delay >= Message timing contrains µs >>>
Response Block: NAD Length *) 0x81 Response Code CHKS
<<< Delay >= Message timing contrains µs >>>

*)
Length:
- 1-byte field
- Max. value: 129D
- Min. value: 2D
- Describes the amount of following bytes in the frame.
Num:
- 1-byte field
- Number of data bytes the host wants to read or write
(exchanged by data & EOT block frames)
Data Bytes:
- Data bytes read or written
Address:
- 24-bit RAM offset to write data
. LIN_FRAME_RAM_WRITE_EXAMPLES
Figure 16 BSL RAM write access frame examples

2024-01-15
MOTIX™ TLE984xQX
Host
BootROM
Commander Request Read RAM Data
Header &
Header Block: SYN 0x55 0x3C NAD Length *) 0x84 Address *) Res Num*) CHKS
<<< Delay >= BSL command processing time >>>

Data Block: NAD Length *) 0x00 Data Bytes*) CHKS
<<< Delay >= Message timing contrains >>>

…
<<< Multiple Responder Response Header & Data Blocks >>>
...
Data Block: NAD Length *) 0x00 Data Bytes*) CHKS
EOT Block: NAD Length *) 0x80 Data Bytes*) CHKS

*)
Length:
- 1-byte field
- Max. value: 129D
- Min. value: 1D
- Describes the amount of following bytes in the frame.
Num:
- 1-byte field
- Number of data bytes the host wants to read or write
(exchanged by data & EOT block frames)
Data Bytes:
- Data bytes read or written
Address:
- 24-bit RAM offset to read data
. LIN_FRAME_RAM_READ_EXAMPLES
Figure 17 BSL RAM read access frame examples

2024-01-15
MOTIX™ TLE984xQX
4.2.3 LIN HAL

The LIN HAL handles all SFR register accesses to the LIN hardware modules. These accesses include timing
critical register accesses and status polling mechanism.
Functionality
The following features are provided by the LIN HAL:
• BREAK condition detection on the LIN interface, used as indication for incoming packets.
• Baud rate detection
• Data reception
• Data transmission
LIN HW slope control is dependent on LIN or FastLIN mode selection:
• For LIN: fast slope is used
• For FastLIN: flash mode slope is used
The device requires some delay to process each received byte from header or EOT block or when transmitting
a response back.

2024-01-15
MOTIX™ TLE984xQX
4.3 BSL via FastLIN

FastLIN is a LIN enhancement supporting higher baud rates of up to 230.4 kBd. This rate is higher than the
standard LIN. FastLIN is especially useful during back-end programming, where faster programming time is
desirable.
The FastLIN BSL protocol supports baud rates of 38.4 kBd, 115.2 kBd and 230.4 kBd via the internal LIN TrxHW
module using the UART BSL protocol.
The FastLIN checksum calculation algorithm is the same algorithm used for the LIN interface (see “BSL via
LIN” on Page 26). The checksum is the last field of Command and Response FastLIN frames.
The FastLIN passphrase frame format is the same as used for the LIN see “LIN / FastLIN passphrase” on
Page 19.
For user mode, the default FastLIN baudrate is 115.2 kBd. The actual session baud rate can be changed with
the BSL command Command 93H – FastLIN: Set Session Baudrate.
Figure 18 shows the interaction between Hardware and software layers for the BSL FastLIN mode.
SW
SFRs HW
Tx Rx
LIN Tranceiver
LIN GND_LIN
BSL_FAST_LIN_MODE_LAYER
S
Figure 18 BSL FastLIN mode HW/SW layers

2024-01-15
MOTIX™ TLE984xQX
4.4 BSL commands - protocol (version 2.0)

This section describes the boot strap loader messages that are used by the LIN and FastLIN protocols. The
physical layer encapsulation of these messages is described in:
• “BSL via LIN” on Page 26
• “BSL via FastLIN” on Page 36
All commands support acknowledge response message, which contain an error code with the result of the
executed command. Some messages return a response message with the result of the executed command
and some messages also return requested data. For messages that return data, the data should be treated as
a response with no errors and the acknowledge response message will in this case not be sent. The messages
will either return an error code of a detected error or return the requested data. Data response messages are
described together with the command messages. The response and error code messages are described in
“Acknowledge Response Message (81H)” on Page 67.
Some commands do not intend to send any response message. For instance, the code execution command
messages directly jump to the requested code location. These messages will only send a response message if
the requested command could not be executed.
Each incoming message is verified. Inconsistent frames or messages (e.g. invalid checksum or length) are
rejected. Unknown messages and message types are also rejected. Discarding an invalid message is done
without any acknowledgement or notification.
Whether the host waiting time before response is sent back or whether a response can be asked for is defined
for each of the messages if it deviates from the definition given in Section 4.1.7.
The following BSL commands are supported:
• Command 02H – RAM: Write Data/Program
• Command 83H – RAM: Execute
• Command 84H – RAM: Read Data
• Command 05H – NVM: Write Data/Program
• Command 86H – NVM: Execute
• Command 87H – NVM: Read Data
• Command 88H – NVM: Erase
• Command 89H – NVM: Protection Set / Clear
• Command 0DH – NVM: 100TP Write
• Command 8EH – NVM: 100TP Read
• Command 8FH – BSL: Option Set
• Command 90H – BSL: Option Get
• Command 91H – LIN: NAD Set
• Command 92H – LIN: NAD Get
• Command 93H – FastLIN: Set Session Baudrate

2024-01-15
MOTIX™ TLE984xQX
Dummy bytes
Depending on the BSL frame data fill level, some frame data bytes are not used. Those bytes are filled with
dummy bytes, which are set to zero. The BootROM ignores dummy bytes, independent of their values.
Padding bytes
For FastLIN:
If the customer adds padding bytes, although this is not regular it is still supported by the firmware. Padding
bytes up to a data field size of 128 bytes are possible. The firmware will accept the real data and will find the
checksum byte after the last padding byte.
RAM access limitation
Access to the BootROM RAM is limited for the BSL commands Command 84H – RAM: Read Data and
Command 02H – RAM: Write Data/Program. In all boot modes, the full RAM range can be read but global
variables/data and stack area cannot be written to. Trying to write to these areas will result in an error.
RAM and NVM address range checks
All commands reading or writing the NVM or RAM check the address range and return an error if it is exceeded.
The number of bytes to be read or written must be greater than zero.
Blocking of BSL commands due to NVM protection
With any command, the BSL applies checks to determine if the command can get executed. BSL commands
accessing the NVM also check the applied read or write NVM HW protection scheme against the NVM access
request. Details are given specifically with each BSL command description. An error is returned upon any
access violation. Table 10 states which NVM protection group is checked before a given BSL command is
executed.
Definitions of NVM protection groups:
• Group 1 = NVM HW read or write protection applied to any NVM region. Reason for this: BSL download is
blocked in case any protection is set. This is done to avoid BSL download of code into any region (even
100TP pages)
• Group 2 = NVM HW read protection applied to any NVM region. Reason for this: BSL download is blocked in
case any protection is set. This is done to avoid BSL download of code into any region (even 100TP pages)
• Group 3 = NVM HW read protection applied to any NVM region and no write protection to NVM code region.
Reason for this: When in user mode, instead, the concept is that for CS accessible page (e.g. 100TP pages)
the FW should apply the same protection set for the user code region. This means that the 100TP write via
User API should be blocked only in case the write protection of the code region (checked by looking at the
NVM_PROT_STS bits) is set
• Group 4 = NVM HW read and write protection for all regions are ignored. Reason for this: For a command
that can change protection, must be allowed access independently of protection

2024-01-15
MOTIX™ TLE984xQX
Table 10 NVM protection check for BSL commands

NVM protection group (condition to block) BSL Command
Group 1 Command 02H – RAM: Write Data/Program
NVM HW read or write protection applied to any Command 05H – NVM: Write Data/Program
NVM region Command 88H – NVM: Erase
Group 2 Command 83H – RAM: Execute
NVM HW read protection applied to any NVM region Command 86H – NVM: Execute
Command 87H – NVM: Read Data
Command 84H – RAM: Read Data
Command 8EH – NVM: 100TP Read
Command 90H – BSL: Option Get
Command 92H – LIN: NAD Get
Command 93H – FastLIN: Set Session Baudrate
Group 3 Command 0DH – NVM: 100TP Write
NVM HW read protection applied to any NVM region Command 8FH – BSL: Option Set
and no write protection to NVM code region Command 91H – LIN: NAD Set
Group 4 Command 89H – NVM: Protection Set / Clear
NVM HW read and write protection for all regions are
ignored

2024-01-15
MOTIX™ TLE984xQX
4.4.1 Command 02H – RAM: Write Data/Program

Firmware supports downloading of data and code to the device’s internal RAM via command 02H.
The host initiates the RAM download by sending a header block message. This message contains information
about the RAM location (offset address based on RAM start address). The data bytes are followed by Data Block
messages and the last data bytes are sent by an EOT block message.
The overall download must be terminated with an EOT block message. The Data Block messages are used if
the downloaded data exceed the Data field size of the EOT block message.
This command does not support to write RAM locations which BootROM uses for global variable and stack
storage.
This command rejects the write operation if any NVM read or write protection is applied to any NVM region,
the offset is out of range, or offset plus count is out of range. Details about the NVM access protection are given
in Command 89H – NVM: Protection Set / Clear. It returns an error code in the response message.
This message supports downloading of a maximum of 128 bytes into the RAM. Larger memory blocks need to
be split into multiple Command 02H – RAM: Write Data/Program messages.
Header Block
0 1 2 3 4 5 6
Address Address
Message Address
Length Byte #0 Byte #2 Reserved Number
Type Byte #1
(MSB) (LSB)
. BSL 20_MODE00 _HEADER
Table 11 “Command 02H – RAM: Write Data/Program” Header Block Field Description
Field Description
Length Number of following bytes in the header block. Always set to 06H
Message Type RAM write command. Always set to 02H
Address Byte #0 (MSB) 24-bit RAM address offset where to store the download data.
Address Byte #1 The offset starts counting from the RAM start address 1800.0000H
Address Byte #2 (LSB)
Number 8-bit number of data bytes to write with the whole message. The BootROM expects to
receive these bytes in data blocks and an EOT block.
Maximum supported length: 128 bytes.
Data Block
This block is only used for LIN communication, because the LIN frame length is too short to place the
maximum supported data length into the EOT block.
0 1 2–6
Message
Length Data
Type
. BSL20 _MODE_DATA

2024-01-15
MOTIX™ TLE984xQX
Table 12 “Command 02H – RAM: Write Data/Program” Data Block Field Description
Field Description
Length Number of following bytes in the data block. Always set to 06H
Message Type Data block. Always set to 00H
Data It contains the downloaded data (no dummy data to fill up the packet).
EOT Block
0 1 2...129
Message
Length Data
Type
. BSL20_MODE_EOT
Table 13 “Command 02H – RAM: Write Data/Program” EOT Block Field Description
Field Description
Length Number of following bytes in the EOT block. The value depends on the size of the “Data”
field:
• LIN – always 2 to 6 bytes
• FastLIN – 2 ... 129 bytes
Message Type EOT block. Always set to 80H
Data The maximum size of the field depends on the BSL interface that is used:
• LIN – 5 bytes
• FastLIN – 128 bytes
Contains the downloaded data.
The EOT block message is the last message for a download and contains the last
downloaded bytes. The data download process does not use data block messages if the
overall data size is equal to or smaller than the “Data” field.
Returned error codes

The message can return the following error codes:
• ERR_LOG_SUCCESS
• ERR_LOG_CODE_NVM_IS_READ_PROTECTED
• ERR_LOG_ERROR (RAM range is invalid)
• ERR_LOG_CODE_MEM_READWRITE_PARAMS_INVALID

2024-01-15
MOTIX™ TLE984xQX
4.4.2 Command 83H – RAM: Execute

Firmware triggers execution of a RAM user program by the Host via command 83H. This code can be previously
downloaded by the BSL Command 02H – RAM: Write Data/Program.
The host initiates the RAM code execution by sending the header block message. This messages contains the
RAM address offset where to jump for code execution.
This command does not check if any valid code is placed in RAM before jumping to the given code location.
The watchdog timer got disabled when entering the BSL communication and stays disabled when jumping to
RAM.
Before jumping to RAM the following steps are done:
• The BootROM configures the stack pointer to 1800.0400H. It is recommended that the RAM code adapts the
stack pointer on demand
• The system clock is switched to PLL at the device default or user defined frequency from NVM CS settings.
• All interrupts are cleared
• The timer is cleared
• In the SCU_VTOR.VTOR register, VTOR_BYP is set to 01b (RAM)
It is not allowed for the RAM code to make a return call. ARM LR register has been set to zero when jumping to
RAM. If BSL should be re-entered a system reset must be performed.
This command does not support any Responder Response Header. It performs the RAM code execution right
after receiving the header block.
Command is rejected if there is any NVM HW read protection applied to any NVM region. Details about the NVM
access protection are given in Command 89H – NVM: Protection Set / Clear.
Header Block
0 1 2 3 4
Address Address
Message Address
Length Byte #0 Byte #2
Type Byte #1
(MSB) (LSB)
Table 14 “Command 83H – RAM: Execute” Header Block Field Description

Field Description
Message Type RAM execute command. Always set to 83H
Address Byte #0(MSB) 24-bit RAM address offset where to jump for code execution.
Address Byte #2(LSB)

2024-01-15
MOTIX™ TLE984xQX

• ERR_LOG_CODE_NVM_RAM_EXEC_PARAMS_INVALID

2024-01-15
MOTIX™ TLE984xQX
4.4.3 Command 84H – RAM: Read Data

Firmware supports reading of data and code from the device’s internal RAM via command 84H.
The host initiates the RAM read by sending a header block message. This message contains information about
the RAM location (offset address based on RAM start address) and the number of read data bytes.
BootROM sends back the requested data by Data Block message and by a terminating EOT block message. The
Data Block messages are used if the amount of read data exceed the Data field size of the EOT block message.
This command rejects the read operation if there is NVM HW read protection applied to any NVM region, the
offset is out of range, or offset plus count is out of range. Details about the NVM access protection are given in
Command 89H – NVM: Protection Set / Clear. It returns an error code in the response message.
This message supports reading of a maximum of 128 bytes from the RAM. Larger memory blocks need to be
split into multiple Command 84H – RAM: Read Data messages.
Header Block
0 1 2 3 4 5 6
Address Address
Message Address
Type Byte #1
(MSB) (LSB)
Table 15 “Command 84H – RAM: Read Data” Header Block Field Description
Field Description
Message Type RAM read data command. Always set to 84H
Address Byte #0(MSB) 24-bit RAM address offset where to read the data.
Number 8-bit number of data bytes to read. The BootROM will send these bytes in Data Blocks
and an EOT block.
Maximum supported length: 128 bytes
Data Block
0 1 2–6
Message
Length Data
Type
. BSL20 _MODE_DATA

2024-01-15
MOTIX™ TLE984xQX
Table 16 “Command 84H – RAM: Read Data” Data Block Field Description
Field Description
Data It contains the read data.
EOT Block
0 1 2...129
Message
Length Data
Type
. BSL20_MODE_EOT
Table 17 “Command 84H – RAM: Read” Data EOT Block Field Description
Field Description
Length Number of following bytes in the EOT block. The value depends on the size of the Data field:
Data The maximum size of the field depends on the used BSL interface:
• LIN – 5 bytes
Contains the read data.
The EOT block message is the last message for a read byte. The data read process does not
use Data Block messages if the overall data size is equal to or smaller than the “Data” field


2024-01-15
MOTIX™ TLE984xQX
4.4.4 Command 05H – NVM: Write Data/Program

Firmware supports programming of data and code to the device’s internal NVM via command 05H.
The host initiates the NVM program by sending a header block message. This message contains information
about the NVM location (offset address based on NVM start address). The data bytes follow by Data Block
messages and the last data bytes are sent by an EOT block message.
The overall download must be terminated with an EOT block message. The Data Block messages are used if
the downloaded data exceeds the Data field size of the EOT block message.
BootROM does not support NVM cross page boundary programming. It stops the programming when it
reaches a NVM page boundary. No bytes are programmed if the data does not fit the page size.
NVM pages can only be written if there is no NVM read or write protection applied to any NVM region. Details
about the NVM access protection are given in Command 89H – NVM: Protection Set / Clear.
This message supports downloading of a maximum of 128 bytes into the NVM. Larger memory blocks need to
be split into multiple Command 05H – NVM: Write Data/Program.
The host waiting time before response is sent back/can be asked for:
• 8 ms
Header Block
0 1 2 3 4 5 6
Address Address
Message Address
Type Byte #1
(MSB) (LSB)
Table 18 “Command 05H – NVM: Write Data/Program” Header Block Description

Field Description
Message Type NVM write data/program command. Always set to 05H
Address Byte #0(MSB) 24-bit NVM address offset where to store the download data.
Address Byte #1 The offset starts counting from the NVM start address 1100.0000H
receive these bytes in Data Blocks and an EOT block.

2024-01-15
MOTIX™ TLE984xQX
Data Block
0 1 2–6
Message
Length Data
Type
. BSL20 _MODE_DATA
Table 19 “Command 05H – NVM: Write Data/Program” Data Block Field Description
Field Description
Data It contains the downloaded data (no dummy data to fill up the packet)
EOT Block
0 1 2...129
Message
Length Data
Type
. BSL20_MODE_EOT
Table 20 “Command 05H – NVM: Write Data/Program” EOT Block Field Description
Field Description
Length Number of following bytes in the EOT block. The value depends on the size of the Data
field:
• LIN – 5 bytes
Contains the downloaded data.
The EOT block message is the last message for a download and contains the last
downloaded bytes. The data download process does not use Data Block messages if the
overall data size is equal to or smaller than the "Data" field

2024-01-15
MOTIX™ TLE984xQX

• ERR_LOG_SUCCESS
• ERR_LOG_ERROR (NVM range is invalid)
• ERR_LOG_CODE_USER_CROSS_PAGE_PRG_NOT_SUPPORTED
• ERR_LOG_CODE_USER_PROTECT_NVM_WRITE_PROTECTED
• ERR_LOG_CODE_NVM_SEMAPHORE_RESERVED
• ERR_LOG_CODE_ACCESS_AB_MODE_ERROR
• ERR_LOG_CODE_NVM_MAPRAM_UNKNOWN_TYPE_USAGE
• ERR_LOG_CODE_NVM_VER_ERROR
• ERR_LOG_CODE_NVM_PROG_MAPRAM_INIT_FAIL
• ERR_LOG_CODE_NVM_PROG_VERIFY_MAPRAM_INIT_FAIL

2024-01-15
MOTIX™ TLE984xQX
4.4.5 Command 86H – NVM: Execute

Firmware triggers execution of a NVM user program by the Host via command 86H. This code could be
previously downloaded by the BSL Command 05H – NVM: Write Data/Program.
The host initiates the NVM code execution by sending the header block message. This messages contains the
NVM address offset where to jump for code execution.
This command does not check if any valid code is placed in NVM before jumping to the given code location.
The watchdog timer got disabled when entering the BSL communication and stays disabled when jumping to
NVM.
Before jumping to NVM the following steps are done:
The BootROM configures the stack pointer to 1800.0400H. It is recommended that the NVM code adapts the
stack pointer on demand. The System clock is switched to PLL, interrupts are cleared, the GPT12E timer is
cleared, the SCU_VTOR.VTOR register is set to NVM (SCU.VTOR.VTOR_BYP = 10b).
It is not allowed for the NVM code to make a return call. ARM LR register has been set to zero when jumping to
NVM. If BSL should be re-entered a system reset must be performed.
This command does not support any Responder Response Header. It performs the NVM code execution right
after receiving the header block.
Command is rejected if there is NVM HW read protection applied to any NVM region. Details about the NVM
access protection are given in Command 89H – NVM: Protection Set / Clear.
Header Block
0 1 2 3 4
Address Address
Message Address
Type Byte #1
(MSB) (LSB)
Table 21 “Command 86H – NVM: Execute” Header Block Field Description

Field Description
Message Type NVM execute command. Always set to 86H
Address Byte #0 (MSB) 24-bit NVM address offset where to jump for code execution.
Address Byte #2 (LSB)

• ERR_LOG_CODE_NVM_ADDR_RANGE_INVALID
• ERR_LOG_CODE_NVM_RAM_EXEC_PARAMS_INVALID

2024-01-15
MOTIX™ TLE984xQX
4.4.6 Command 87H – NVM: Read Data

Firmware supports reading of data and code from the device’s internal NVM via command 87H.
The host initiates the NVM read by sending a header block message. This message contains information about
the NVM location (offset address based on NVM start address) and the number of read data bytes.
BootROM sends back the requested data by Data Block message and by a terminating EOT block message. The
Data Block messages are used if the amount of read data exceeds the Data field size of the EOT block message.
NVM pages can only be read if there is no NVM HW read protection applied to any NVM region. Details about
the NVM access protection are given in Command 89H – NVM: Protection Set / Clear. If reading from an
address, which belongs to the non-linear NVM region and the page is not mapped (previous programmed), the
read is rejected.
This message supports reading of a maximum of 128 bytes from the NVM. Larger memory blocks need to be
split into multiple Command 87H – NVM: Read Data messages.
• 8 ms
Header Block
0 1 2 3 4 5 6
Address Address
Message Address
Type Byte #1
(MSB) (LSB)
Table 22 “Command 87H – NVM: Read Data” Header Block Field Description
Field Description
Message Type NVM read data command. Always set to 87H
Address Byte #0(MSB) 24-bit NVM address offset where to read the data.
Number 8-bit number of data bytes to read. The BootROM will send these bytes in Data Blocks
and an EOT block.

2024-01-15
MOTIX™ TLE984xQX
Data Block
0 1 2–6
Message
Length Data
Type
. BSL20 _MODE_DATA
Table 23 “Command 87H – NVM: Read Data” Data Block Field Description
Field Description
Data It contains the read data
EOT block
0 1 2...129
Message
Length Data
Type
. BSL20_MODE_EOT
Table 24 “Command 87H – NVM: Read Data” EOT Block Field Description
Field Description
field:
• LIN – 5 bytes
The EOT block message is the last message for read bytes. The data read process does
not use Data Block messages if the overall data size is equal to or smaller than the “Data”
field

2024-01-15
MOTIX™ TLE984xQX

• ERR_LOG_CODE_NVM_PAGE_NOT_MAPPED
• ERR_LOG_CODE_ECC2READ_ERROR

2024-01-15
MOTIX™ TLE984xQX
4.4.7 Command 88H – NVM: Erase

This command supports the erasure of NVM pages and NVM sectors.
The host initiates the NVM erase operation by sending a header block message. This message contains
information about the NVM location (offset address based on NVM start address) and selects the erase
granularity.
The BootROM rejects the erase operation if the given NVM location is not page-aligned for page erase
operation, or not sector-aligned for sector erase operation.
Any NVM erase operation is rejected in case any NVM read or write protection is applied to any NVM region.
Details about the NVM access protection are given in Command 89H – NVM: Protection Set / Clear.
This erase command does not erase any NVM CS (Configuration Sector) pages.
• Page erase (128 bytes) / sector erase (4 KB): 5 ms
Header Block
0 1 2 3 4 5
Address Address
Message Address Erase
Type Byte #1 Type
(MSB) (LSB)
Table 25 “Command 88H – NVM: Erase” Header Block Field Description

Field Description
Message Type NVM erase command. Always set to 88H
Address Byte #0(MSB) 24-bit NVM address offset for page or sector erase selection.
Erase Type Supported erase type field values:
• 0 - NVM page erase
• 1 - NVM sector erase

• ERR_LOG_SUCCESS
• ERR_LOG_CODE_NVM_ERASE_PARAMS_INVALID (includes NVM write protection check)
• ERR_LOG_CODE_NVM_ERASE_ADDR_INVALID
• ERR_LOG_CODE_NVM_SECT_ERASE_ADDR_INVALID
• ERR_LOG_CODE_NVM_INIT_MAPRAM_SECTOR

2024-01-15
MOTIX™ TLE984xQX
4.4.8 Command 89H – NVM: Protection Set / Clear

Firmware supports setting and clearing of NVM protection for different NVM regions via command 89H. These
regions are the customer Bootloader NVM sector, code and data NVM sectors (multiple sector regions).
NVM region protection includes access protection for read and/or write/erase.
Any NVM protection clear operation ignores the password parameter if there is currently no protection
password installed for that region.
A valid password must be not equal to 0000.0000H or 3FFF.FFFFH. The password is checked during startup.
Only if the password is valid, the given protection gets applied to the HW. This command only updates the
specified NVM CS region password and does not apply it to the HW. This is done at the next device boot.
It is only possible to set a new password if one is not installed for the region. An error is returned otherwise. To
update an existing password, the current one must be cleared first and then a new one can be set. When the
password has been successfully cleared, the password specified for the region in the options field will get set
to 0xFFFFFFFF. If the password used for clearing does not match the one installed, all region passwords and
the whole NVM are erased. Clearing of the password for the customer Bootloader (CBSL) region is not
supported.
When comparing a given password with one installed, the protection part of the password is ignored.
This command can be used regardless of the current applied NVM HW protection for any region.
The host waiting time before a response is sent back/can be asked for:
• 8 ms
Header Block
0 1 2 3 4 5 6
Password Password
Message Password Password
Length Byte #0 Byte #3 Options
Type Byte #1 Byte #2
(MSB) (LSB)
Table 26 “Command 89H – NVM: Protection Set / Clear” Header Block Field Description
Field Description
Message Type NVM protection set/clear command. Always set to 89H
Password Byte #0(MSB) 32-bit password parameter. (see also “NVM password format” on Page 68)
Password Byte #1
Password Byte #2
Password Byte #3(LSB)
Options The options field is described in Table 27

2024-01-15
MOTIX™ TLE984xQX
Table 27 “Command 89H – NVM: Protection Set / Clear” Header Block Options Field Description
Field Bits Description
Res 7:3 Reserved
Password Selector 2:1 Password Selector
Password selection to set or reset.
00B Customer Bootloader Password
01B Code Segment Password
10B Data Segment Password
11B Reserved
Operation 0 Set/Clear the password protection
0B Clear, The password protection is cleared if the provided password
matches the installed password for the region
1B Set, Password protection is installed for the region if the selected
password protection is currently not installed

• ERR_LOG_SUCCESS
• ERR_LOG_CODE_USER_NVM_PROTECT_SEGMENT_INVALID
• ERR_LOG_CODE_USER_PROTECT_PWD_INVALID
• ERR_LOG_CODE_CS_PAGE_CHECKSUM
• ERR_LOG_CODE_CS_PAGE_ECC2READ
• ERR_LOG_CODE_USER_PROTECT_NO_CBSL_PWD_CLEAR
• ERR_LOG_CODE_USER_PROTECT_NO_PASSWORD_EXISTS
• ERR_LOG_CODE_NVM_ERASE_ADDR_INVALID
• ERR_LOG_CODE_NVM_SECT_ERASE_ADDR_INVALID
• ERR_LOG_CODE_NVM_PROTECT_REMOVE_PASSWORD_FAILED
• ERR_LOG_CODE_USER_PROTECT_NVM_AND_PWD_ERASED
• ERR_LOG_CODE_NVM_ERASE_PARAMS_INVALID (includes NVM write protection check)
• ERR_LOG_CODE_USER_PROTECT_PWD_EXISTS

2024-01-15
MOTIX™ TLE984xQX
4.4.9 Command 0DH – NVM: 100TP Write

Firmware supports programming of data in the customer-specific 100TP pages via command 0DH.
Any page programming is rejected if the page specific programming limit (100 times) is exceeded.
The header block message contains parameter about the 100TP page index, the offset inside that page. The
data bytes follow by Data Block messages and the last data bytes are sent by an EOT block message.
This command rejects the page write operation if the offset is out of range, or offset plus count is out of range.
NVM 100TP pages can only be written if there is no NVM read protection applied to any NVM region and write
protection to code segment (linear sectors). It returns an error code in the response message. It supports
partial page programming, preserving the page data not passed as an input
After successful write operation, the page write counter and checksum parameter are updated. These two
bytes are stored at the end of the page. These two internal bytes reduce the usable page size (126 bytes
instead of 128 bytes).
• 8 ms
Header Block
0 1 2 3 4 5 6
Message CS
Length Reserved Offset Reserved Number
Type Index
. BSL20_MODE0B_HEADER
Table 28 “Command 0DH – NVM: 100TP Write” Header Block Field Description
Field Description
Message Type NVM 100TP write command. Always set to 0DH
CS Index 100TP Selector.
Supported range: 0 ... 7
Offset Byte offset within page, valid range 0 ... 125
receive these bytes in Data Blocks and an EOT block.
Data Block

2024-01-15
MOTIX™ TLE984xQX
0 1 2–6
Message
Length Data
Type
. BSL20 _MODE_DATA
Table 29 “Command 0DH – NVM: 100TP Write” Data Block Field Description
Field Description
Data It contains the downloaded data (no dummy data to fill up the packet).
EOT Block
0 1 2...127
Message
Length Data
Type
. BSL20 _BSL _NVM_100TP_WRITE_EOT
Table 30 “Command 0DH – NVM: 100TP Write” EOT Block Field Description
Field Description
field:
• LIN – 5 bytes
not use Data Block messages if the overall data size is equal to or smaller than the “Data”
field.

• ERR_LOG_SUCCESS
• ERR_LOG_CODE_USERAPI_CONFIG_SECTOR_WRITE_PROTECTED

2024-01-15
MOTIX™ TLE984xQX
• ERR_LOG_CODE_100TP_WRITE_ADDRESS_INVALID
• ERR_LOG_CODE_100TP_WRITE_COUNT_EXCEEDED

2024-01-15
MOTIX™ TLE984xQX
4.4.10 Command 8EH – NVM: 100TP Read

Firmware supports reading of data from the customer-specific 100TP page via command 8EH.
The header block message contains parameter about the 100TP page index, the offset inside that page and
the number of read data bytes. The BootROM sends the data bytes by Data Block messages and the last data
bytes by an EOT block message.
This command rejects the read operation if the 100TP page checksum is invalid, the offset is out of range, or
offset plus count is out of range. NVM 100TP pages can only be read if there is no NVM HW read protection
applied to any NVM region
The read command allows reading the internal used page programming counter. Those parameters are set
during the write operation. Details can be found in Command 0DH – NVM: 100TP Write.
Header Block
0 1 2 3 4 5 6
Message CS
Length Reserved Offset Reserved Number
Type Index
. BSL20 _MODE0C_HEADER
Table 31 “Command 8EH – NVM: 100TP Read” Header Block Field Description
Field Description
Message Type NVM 100TP read command. Always set to 8EH
CS Index 100TP Selector.
Supported range: 0 ... 7
Offset Byte offset within page, valid range 0 ... 126
Number Number of data bytes to read. The BootROM will send these bytes in Data Blocks and an
EOT block.
Data Block
0 1 2–6
Message
Length Data
Type
. BSL20 _MODE_DATA

2024-01-15
MOTIX™ TLE984xQX
Table 32 “Command 8EH – NVM: 100TP Read” Data Block Field Description
Field Description
Data It contains the read data
EOT Block
0 1 2...129
Message
Length Data
Type
. BSL20_MODE_EOT
Table 33 “Command 8EH – NVM: 100TP Read” EOT Block Field Description
Field Description
field:
• LIN – 5 bytes
• FastLIN – 128 bytes.
not use Data Block messages if the overall data size is equal to or smaller than the "Data"
field

• ERR_LOG_CODE_100TP_READ_ADDRESS_INVALID
• ERR_LOG_CODE_CS_PAGE_CHECKSUM
• ERR_LOG_CODE_CS_PAGE_ECC2READ

2024-01-15
MOTIX™ TLE984xQX
4.4.11 Command 8FH – BSL: Option Set

Firmware supports setting of some BSL option data, including BSL timeout (NAC) and BSL interface selector,
via command 8FH.
The header block message contains the selected BSL interface and the NAC value.
The given configuration is stored in the device NVM CS and is used for the next startup.
The current BSL option can be read by the Command 90H – BSL: Option Get command.
The command can only be used if there is no NVM read protection applied to any NVM region and write
protection to code segment (linear sectors).
• 8 ms
Header Block
0 1 2 3
BSL BSL
Message
Length Interface Timeout
Type
Selector (NAC)
. BSL20 _BSL _OPTION_ SET_HEADER
Table 34 “Command 8FH – BSL: Option Set” Header Block Field Description
Field Description
Message Type BSL option set. Always set to 8FH
BSL Interface BSL Interface Selector to be used for the next startup:
Selector • 0 - LIN
• 1 - FastLIN
BSL Timeout (NAC) BSL Timeout before jumping to the User Mode Code execution. The timeout starts
counting from device reset release.
A maximum of 140 ms is supported.
The BSL timeout parameter counts the amount of 5 ms (01H = 5 ms, 02H = 10 ms and so
on). The value FFH waits forever.
A value = 00H disables the BSL mode and the BootROM directly jumps to user mode

• ERR_LOG_SUCCESS
• ERR_LOG_CODE_USERAPI_CONFIG_SET_PARAMS_INVALID

2024-01-15
MOTIX™ TLE984xQX
4.4.12 Command 90H – BSL: Option Get

Firmware supports reading the current configured BSL option data from the NVM CS, including BSL timeout
(NAC) and BSL interface selector, via command 90H.
The header block message contains the information request. The BootROM sends the selected BSL interface
and the NAC parameter by an EOT block message.
The command is rejected if NVM HW read protection is applied to any NVM region.
The BSL option can be changed by the Command 8FH – BSL: Option Set.
Header Block
0 1
Message
Length
Type
. BSL20 _BSL_ OPTION_ GET_HEADER
Table 35 “Command 90H – BSL: Option Get” Header Block Field Description
Field Description
Message Type BSL option set. Always set to 90H
EOT block
0 1 2 3
BSL BSL
Message
Length Interface Timeout
Type
Selector (NAC)
. BSL 20_ BSL_OPTION_GET _EOT
Table 36 “Command 90H – BSL: Option Get” EOT Block Description

Field Description
Length Number of following bytes in the EOT block. Always set to 03H
BSL Interface BSL Interface Selector to be used for the next startup:
Selector • 0 - LIN
• 1 - FastLIN
BSL Timeout (NAC) BSL Timeout before jumping to the User Mode Code execution. The timeout starts
counting from device reset release.
A maximum of 140 ms is supported.
The BSL timeout parameter counts the amount of 5 ms (01H = 5 ms, 02H = 10 ms and so
on). The value FFH waits forever.
A value = 00H disables the BSL mode and the BootROM directly jumps to user mode

2024-01-15
MOTIX™ TLE984xQX


2024-01-15
MOTIX™ TLE984xQX
4.4.13 Command 91H – LIN: NAD Set

Firmware supports setting of the LIN NAD via command 91H.
The header block message contains as a parameter the LIN NAD value.
The given NAD address is stored in the device NVM CS and is used for the next startup.
The command can only be used if there is no NVM read protection applied to any NVM region and write
protection to code segment (linear sectors).
The current NAD value can be read by the Command 92H – LIN: NAD Get command.
• 8 ms
Header Block
0 1 2
Message LIN
Length
Type NAD
. BSL20 _BSL _NAD_ SET_HEADER
Table 37 “Command 91H – LIN: NAD Set” Header Block Field Description
Field Description
LIN NAD New NAD value to be stored in the NVM CS

• ERR_LOG_SUCCESS
• ERR_LOG_CODE_NAD_VALUE_INVALID

2024-01-15
MOTIX™ TLE984xQX
4.4.14 Command 92H – LIN: NAD Get

Firmware supports reading the currently configured LIN NAD value via command 92H.
The header block message contains the information request. The BootROM sends the current LIN NAD value
by an EOT block message.
The command is rejected if NVM HW read protection is applied to any NVM region.
The given NAD address is read from the NVM CS.
The NAD value can be changed by the Command 91H – LIN: NAD Set command.
Header Block
0 1
Message
Length
Type
. BSL20 _BSL _NAD_ GET_HEADER
Table 38 “Command 92H – LIN: NAD Get” Header Block Field Description
Field Description
EOT Block
0 1 2
Message
Length NAD value
Type
. BSL 20_ BSL_NAD_GET _EOT
Table 39 “Command 92H – LIN: NAD Get” EOT Block Field Description
Field Description
Length Number of following bytes in the EOT block. Always set to 02H
NAD value The configured LIN NAD value


2024-01-15
MOTIX™ TLE984xQX
4.4.15 Command 93H – FastLIN: Set Session Baudrate

Firmware supports changing the FastLIN baudrate for the current FastLIN BSL session via command 93H.
The header block message contains the new FastLIN baud rate selection for the current FastLIN session. The
given parameter is not stored inside the NVM CS, and the FastLIN default baud rate takes effect when the
response has been sent back to the host.
This command is rejected if the BSL communication currently uses a different interface than FastLIN. The
command is also rejected if NVM HW read protection is applied to any NVM region.
• 8 ms
Note: When sending this command, the response to the command will use the old baudrate. The new
baudrate will be set only after the response has been transmitted.
0 1 2
Fast-LIN
Message
Length Baudrate
Type
Selector
. BSL20 _BSL _FAST_LIN_ BAUDRATE_ SET_HEADER
Table 40 “Command 93H – FastLIN: Set Session Baudrate” Header Block Field Description
Field Description
Message Type BSL Set session baud rate. Always set to 93H
FastLIN Baudrate Baud rate to be used, starting from the next frame:
Selector • 0 - 38.4 kBd
• 1 - 115.2 kBd
• 2 - 230.4 kBd

• ERR_LOG_SUCCESS
• ERR_LOG_CODE_FASTLIN_BAUDRATE_SET_FAIL

2024-01-15
MOTIX™ TLE984xQX
4.4.16 Acknowledge Response Message (81H)

Firmware supports sending back acknowledge response message (81H) if the requested BSL command does
not retrieve any data or the requested data cannot be provided. It is also sent if a problem occurred during
processing the requested command data.
Response Block
0 1 2 3
Response Response
Message Code Code
Length
Type Byte #0 Byte #1
(MSB) (LSB)
. BSL20 _MODE_RESPONSE
Table 41 Acknowledge Response Block Field Description

Field Description
Length Number of following bytes in the Response Block. Always set to 03H
Message Type Response Block. Always set to 81H
Response Code Signed 16-bit command response code. The value is set to zero if the requested
Byte #0 (MSB) command could be executed without any problems
Response Code
Byte #1 (LSB)

2024-01-15
MOTIX™ TLE984xQX
NVM
5 NVM
5.1 NVM overview

The NVM module consists of three regions, the config sector, the user code region and the user data region.
The config sector holds device specific information as well the eight 100TP pages. The config sector is not
directly addressable by the user. To access the 100TP pages dedicated user API functions are provided.
USER CODE region
The user code region is intended to store the user application and/or constant user configurations. The user
code area is divided into two parts. The first 4 KB are called customer BSL region. It is a user code area which
can be protected separately from the remaining user code. The customer BSL region is provided to store a user
defined boot up code. The remaining user code is used to store the user application code. The entire user code
area is directly addressable for read accesses. For writing/erasing data to the user code area dedicated user
API functions are provided.
USER DATA region
The last 4 KB of the NVM module are the user data flash region. For this sector an EEPROM emulation is
implemented. It is intended to store dynamically application data inside this NVM region. Constant data is
recommended to be stored inside the user code area.
The EEPROM emulation is being achieved by the implementation of an address translation table, the so called
MapRAM. All accesses to the data flash, read or write, the user given address (logical) is being translated to the
physical address by using the MapRAM. The data flash is directly addressable for read accessed (through the
MapRAM), but only mapped pages return data. The read access to an unmapped page causes a NMI, to signal
to the user application the attempt of reading not existing data. For writing/erasing data to the user data area
dedicated user API functions are provided.
NVM password protection
Firmware supports setting and clearing of NVM protection for different NVM regions. These regions are the
customer Bootloader NVM sector, code and data NVM sectors. NVM region protection includes access
protection for read and/or write/erase. NVM protection passwords are 32-bit in length, the two MSBs are
reserved for read/write protection handling.
Bit: 31 30 29 0
R W Password
Password value (Bit 29..0)

Write protection (1: enable protection 0: disable protection)
Read protection (1: enable protection 0: disable protection)
. NVM_PASSWORD_FORM
Figure 19 NVM password format
See also “Command 89H – NVM: Protection Set / Clear” on Page 54 for details on how to set or clear the NVM
protection password.

2024-01-15
MOTIX™ TLE984xQX
NVM
5.2 NVM write

It is strongly recommended to the user that no flash operations which modify the content of the flash, like
write and erase, get interrupted at any time.
In order to write/modify data to a NVM page inside the user code or user data area, several user API functions
are provided. From a user point of view there is no need to differentiate between the two major user NVM areas
by using the API functions. The called user API functions are identifying by the given address the target user
NVM region.
For writing a NVM page two scenarios are considered:
1. Writing a new page (erased or unmapped)
2. Writing a used page
The handling of these two scenarios, differ slightly between user code area and user data area. All the
following described actions are performed by the user API functions, it does not describe user activities.
For writing a new code flash page the assembly buffer (AB) is opened. The AB is a small portion of SRAM inside
the NVM hardware module to buffer the content of a NVM page for write activities. The AB is filled with 0xFF,
the content of an erased page. The AB is updated with the data provided by the user along with the calling of
the user API function. Then the content of the AB is written to the erased page addressed by the address
provided by the user as parameter for the user API function.
For writing a used code flash area the AB is opened and the data inside the used page is copied into the
assembly buffer. The AB is updated with the data provided by the user along with the calling of the user API
function. The addressed NVM page is being erased afterwards the content of the AB is written to the erased
page.
For writing a new data flash page, the user API function checks the content of the MapRAM for the given
address. Since the page is not used, the MapRAM entry is marked unused. An internally maintained spare page
points to a randomly selected erased physical data flash page. The assembly buffer (AB) is opened for the
selected physical data flash page. The AB is updated with the data provided by the user along with the calling
of the user API function. Then the content of the AB is written to the page addresses by the spare page. The
link to the physical page is entered into the MapRAM and a new spare page is randomly selected.
For writing a used data flash page, the user API function checks the content of the MapRAM for the given
address. The AB is opened and the data of the used (still mapped) page is copied into the AB. The AB is updated
with the data provided by the user along with the calling of the user API function. Then the content of the AB
is written to the page addresses by the spare page. The link to the new physical page is entered into the
MapRAM. Now the old data flash page is being erased and a new spare page is randomly selected.
For all of these four scenarios the data just written is verified against the content of the AB. The user can select
whether a retry (erase-write) is performed in case the verify failed.
For the data flash along with the enabled retry feature also the Disturb Handling (DH) feature gets enabled.
The goal of the Disturb Handling is to compensate for retention losses of pages long time not updated by the
user. Retry and Disturb Handling are executed exclusively, either of the two can be executed with one user API
call but not both. In case no retry is performed and based on a pseudo-random number generator the DH is
called (in average on every 1000th write operation), a copying of a used page (not the one which was just
written) is triggered. The actions performed by copying a used page inside the data flash sector are the same
as for writing a used data flash page.

2024-01-15
MOTIX™ TLE984xQX
NVM
5.3 Data flash initialization

After a reset the volatile memory, MapRAM, has to be recovered in order to be able to perform the address
translation for data flash accesses. The content of the MapRAM is being recovered out of the MapBlock, control
information stored along with each data flash page. If during the initialization of the MapRAM an error
occurred, i.e. a MapBlock of a data flash page contains ECC failures or if two pages are pointing to the same
MapRAM entry (double mapping) then a repair function is called, the Service Algorithm (SA).
The Service Algorithm (SA) is executed only during startup, by the MapRAM initialization function and only if
failures occurred during the MapRAM initialization. The Service Algorithm scans the entire data flash sector
and tries to repair as much as possible faulty pages, pages with ECC failures in the MapBlock. The SA further
scans for double mappings, pages which point to the same MapRAM entry. Up to one double mapping can be
resolved by deleting one of the two pages. If more than one double mapping is existent the SA is not able to
repair.
The result of the Service Algorithm is being reflected in the register MEMSTAT. The user shall read this register
upon user code entry and in case unrecoverable failures in the data flash are signaled appropriate data flash
recovery has to be performed by the user, such as erase of the entire data flash sector. It is not recommended
to perform any write/erase action to the data flash if the mapping integrity is not given, the status of the
mapping integrity is stored inside MEMSTAT and shall be evaluated by the user upon user code entry.

2024-01-15
MOTIX™ TLE984xQX
User routines
6 User routines
The BootROM exports some library functions to the user mode software. These library functions allow to
configure the device boot parameter and access the NVM.
6.1 List of supported features

• Read and write the various 100TP pages inside the NVM
• Read, write and erase the NVM pages and sectors
• Configure the BSL parameter (e.g. interface selection, timeout configuration, LIN address)
• Retrieve the customer identification number
• Perform a RAM MBIST test
• Check for ECC single- and double-errors on NVM and RAM
All library functions are accessible over a branch table, where the user mode software can directly jump to.
The branch table is stored at a fix location and in return branches to the function implementation.
An API reference to the user routines is given in “User API routines” on Page 73.
6.2 Reentrance capability and interrupts

With the exception of a few functions, no support is provided for reentrance of user API routines – user calls
must be atomic (i.e., they must not be interrupted and reentered before completion). The customer
application must not call these routines from different multitask levels (e.g. different thread/interrupt levels).
As user API routines are potentially timing dependent, it is recommended to disable interrupts prior to calling
API routines.
6.3 Parameter checks

Some of the user API implementations use pointers to exchange data with the API. All pointers must point to
a valid RAM address range. If the address points outside the valid RAM area, an error code is returned.
Other routines support branching or callbacks. If the callback is different from zero, it must point to a valid
NVM or RAM range. Otherwise an error is returned.
6.4 NVM region write protection check

The user API functions writing to a page in NVM or NVM-CS check for NVM region write protection, and return
an error code if the protection is set for that page.
6.5 Watchdog handling when using NVM functions

The execution time of all user API functions is given in “Appendix F – execution time of BootROM user API
functions” on Page 118. This has to be observed for watchdog timeout calculations, especially when NVM
operations are involved (programming or erase). Prior to invoking NVM write routines, it is recommended to
do the following:
• Perform a short-open-window trigger to WDT1 before a NVM operation is called
• Invoke NVM write routine
• Reconfigure watchdog for normal operation
Doing this ensures that the watchdog will not expire and cause reset during NVM operations.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.6 Interrupts
System interrupts are not used by any BootROM functions during startup or when any user APIs are executed.
Customer software must service system interrupts in a normal fashion, which means installing interrupt
vectors at the correct locations for the system CPU.
6.7 Resources used by user API functions

Listed below is a list of user API functions with what kind of HW resources they use.
Stack usage of the functions are listed in Appendix B – stack usage of user API functions.
Table 42 Resources used by user API functions

User API function Non re-entrance NVM HW GPT12 timer
user_nvm_mapram_init X X (HW init)
user_bsl_config_get X (read)
user_bsl_config_set X X (write)
user_ecc_events_get X
user_ecc_check X X (read)
user_mbist_set X X (write)
user_nac_get X (read)
user_nac_set X X (write)
user_nad_get X (read)
user_nad_set X X (write)
user_nvm_100tp_read X X (read)
user_nvm_100tp_write X X (write)
user_nvm_config_get X (read)
user_nvm_password_clear X X (write)
user_nvm_password_set X X (write)
user_nvm_protect_get
user_nvm_protect_set X X (write)
user_nvm_protect_clear X X (write)
user_nvm_ready_poll
user_nvm_page_erase / X X (write)
user_nvm_page_erase_branch /
user_nvm_sector_erase
user_nvm_write / user_nvm_write_branch X X (write)
user_ram_mbist X
user_nvm_clk_factor_set

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8 User API routines

These routines are exported by the BootROM to the customer user mode software.
User API Routines support features like accessing memory resources like NVM and 100TP pages. They also
support to configure some protection mechanism and BSL parameters. The API functions check the valid
parameter range, which is depending on the device.
Table 43 User API routines function overview

Name Description
user_bsl_config_get This user API function reads the user BSL interface selection value.
user_bsl_config_set This user API function writes the user BSL interface selection value. This
function returns an error in case the NVM code segment is write protected.
user_ecc_check This user API function checks for single and double ECC checking over the
entire NVM (all NVM linear and NVM non-linear sectors). Any existing ECC
errors are cleared before the read starts.
user_ecc_events_get This user API function checks if any single or double ECC events have
occurred during runtime. It reports any single or double ECC event coming
from NVM. The corresponding last double ECC failure address is returned
via modified pointer.
user_mbist_set This user API function enables a separate MBIST for all possible reset
sources, except POR reset and pin reset. The MBIST is always performed
for POR reset and pin reset. This function rejects with an error in case the
NVM code segment is write protected.
user_nac_get This user API function reads out the NAC value that is currently configured
in the non volatile device configuration memory.
user_nac_set This user API function configures the NAC value in the non volatile device
configuration memory.
user_nad_get This user API function reads out the LIN NAD value that is currently
configured in the non volatile device configuration memory.
user_nad_set This user API function configures the LIN NAD value in the non volatile
device configuration memory.
user_nvm_100tp_read This user API function reads data from the customer accessible
configuration pages (100TP), address is relative inside the configuration
NVM area (8x one page, 1024 bytes). It stops reading at page boundary. In
case the offset plus count is out of range or if count is zero it returns an
error and does not perform any read operation.
user_nvm_100tp_write This user API function writes data to the configuration NVM, address is
relative inside the configuration NVM area (8x one page, 1024 bytes). It
stops writing at page boundary. The function shall support partial page
programming, preserving the page data not passed as an input. The
function shall perform an implicit update of the page checksum and write
counter. The function does not allow the customer to change the page
checksum or write counter. In case the offset plus count is out of range or
if count is zero it returns an error and does not perform any program
operation. The function also returns an error in case the NVM code
segment is write protected. The write counter and the page checksum are
the last two bytes of the page.
2024-01-15
MOTIX™ TLE984xQX
User routines
Table 43 User API routines function overview (cont’d)

Name Description
user_nvm_clk_factor_set This user API function sets the SCU_SYSCON0.NVMCLKFAC divider.
user_nvm_config_get This user API function allows to gather the NVM configuration, this is the
number of sectors for user code, user data and user bsl.
user_nvm_mapram_init This user API function triggers NVM FSM MapRAM update sequence from
mapped sector.
user_nvm_page_erase This user API function erases a given NVM page (address). This function
rejects with an error in case the accessed NVM page is write protected. In
case of an unused (new) page in non-linear sector, the function does
nothing and returns success. In case of erasing a page in linear sector, the
function should always perform the erase.
user_nvm_page_erase_branch This user API function erases a given NVM page (address) and branches to
an address (branch_address) for code execution during the NVM
operation.
user_nvm_password_clear This user API function clears the NVM protection password for a given NVM
code or data segment (not supported for the BSL segment). The password
is only removed in case the correct password is provided.
user_nvm_password_set This user API function sets a read and/or write protection for any NVM
region individually. The API does not change the protection state for a
region where password protection is currently installed.
user_nvm_protect_clear This user API function clears a read and/or write protection for any NVM
region individually. The API changes the protection state for a region, but
does not update the installed password (config sector).
user_nvm_protect_get This user API function checks for the hardware current applied NVM
protection status.
user_nvm_protect_set This user API function sets a read and/or write protection for any NVM
region individually. The API changes the protection state for a region, but
does not update the installed password in configuration sector.
user_nvm_ready_poll This user API function checks for the readiness of the NVM module. The API
is called within the NVM programming or erase branch callback operation.
It checks if the NVM operation has finished and the callback could return to
the NVM routine.
user_nvm_sector_erase This user API function erases the NVM sector-wise. It operates on user code
and data NVM region.
user_nvm_write This user API function programs the NVM. It operates on the user NVM, as
well as on the user data NVM. The API shall write a number of bytes (count)
from the source (data) to the NVM location (address) with the
programming options (options). The options provide parameters like DH
and fail scenario handling.

2024-01-15
MOTIX™ TLE984xQX
User routines
Table 43 User API routines function overview (cont’d)

Name Description
user_nvm_write_branch This user API function programs the NVM. It operates on the user NVM, as
well as on the user data NVM. The API shall write a number of bytes (count)
from the source (data) to the NVM location (address) with the
programming options (options). During the NVM operation the program
execution branches to a given SRAM location (branch_address) and
continues code execution from there. The options provide parameters like
DH and fail scenario handling.
user_ram_mbist This user API function performs a MBIST on the integrated SRAM. The
range to check is provided as parameter. The function rejects the call in
case the parameter exceeds the RAM address range.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.1 user_nvm_mapram_init
Description
This user API function triggers NVM FSM MapRAM update sequence from mapped sector.In case of mapping
errors (double or multiple mapping or faulty pages) the initialization of the MapRAM is stopped on the first
error found and the routine is exited reporting an error indication.
In case of fail, the content of the MapRAM might be only partial and the mapping information might be
corrupted.
Prototype
int32_t user_nvm_mapram_init (void)
Parameters
void
Return Values
Data Type Description

int32_t Zero in case the function has been called successfully, otherwise a negative error
code. The returned code can be one of the following:
ERR_LOG_SUCCESS,
ERR_LOG_ERROR,
ERR_LOG_CODE_NVM_SEMAPHORE_RESERVED,
ERR_LOG_CODE_NVM_INIT_MAPRAM_SECTOR

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.2 user_bsl_config_get
Description
This user API function reads the user BSL interface selection value.
Prototype
BSL_INTERFACE_SELECT_t user_bsl_config_get (void)
Parameters
void
Return Values

BSL_INTERFACE_SELECT_t The currently selected BSL interface. It returns the default BSL_FAST_LIN
interface in case no configuration is given in the NVM CS

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.3 user_bsl_config_set
Description
This user API function writes the user BSL interface selection value. This function returns an error in case the
NVM code segment is write protected.
Prototype
int32_t user_bsl_config_set (
BSL_INTERFACE_SELECT_t ser_if
)
Parameters
Data Type Name Description Dir

BSL_INTERFACE_SELECT_t ser_if BSL interface selection -
Return Values

int32_t ERR_LOG_SUCCESS in case of success, otherwise a negative error code.
Returned error code can be one of the following:
ERR_LOG_SUCCESS,
ERR_LOG_CODE_USERAPI_CONFIG_SECTOR_WRITE_PROTECTED,
ERR_LOG_CODE_USERAPI_CONFIG_SET_PARAMS_INVALID,
ERR_LOG_CODE_ACCESS_AB_MODE_ERROR
Remarks
It is not allowed to be called by NVM callback routines.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.4 user_ecc_events_get
Description
This user API function checks if any single or double ECC events have occurred during runtime. It reports any
single or double ECC event coming from NVM. The corresponding last double ECC failure address is returned
via modified pointer. Upon exit, the function will clear the current ECC status in the NVM module.
Prototype
int32_t user_ecc_events_get (
uint32_t * pNVM_Addr
)
Parameters

uint32_t * pNVM_Addr Pointer to NVM Address variable where the double ECC -
error is stored. This pointer stays untouched in case no
NVM double ECC errors was detected. The double ECC
error address points to an 8-byte NVM block where the
error occurred. Pointer must be within valid RAM range
(0x18000000 + device RAM size) or an error code is
returned
Return Values

int32_t ERR_LOG_SUCCESS in case no single or double ECC event have occurred, A
negative error code for single, double or single and double ECC errors A negative
error code if the NVM semaphore is not free. Returned error code can be one of the
following:
ERR_LOG_SUCCESS,
ERR_LOG_CODE_USERAPI_POINTER_RAM_RANGE_INVALID,
ERR_LOG_CODE_SINGLE_ECC_EVENT_OCCURRED,
ERR_LOG_CODE_DOUBLE_ECC_EVENT_OCCURRED,
ERR_LOG_CODE_SINGLE_AND_DOUBLE_ECC_EVENT_OCCURRED
Remarks
It is not allowed to be called by NVM callback routines or any interrupt or multi-threaded environment in a re-
entrant context.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.5 user_ecc_check
Description
This user API function checks for single and double ECC checking over the entire NVM (all NVM linear sectors
and all mapped pages inside the mapped NVM sector). Any existing ECC errors are cleared before the read
starts. Upon exit, the function will clear the current ECC status in the NVM module.
Prototype
int32_t user_ecc_check (void)
Parameters
void
Return Values

int32_t ERR_LOG_SUCCESS in case no single or double ECC event have occurred, otherwise
a negative error code for single, double or single and double ECC errors. Returned
error code can be one of the following:
ERR_LOG_SUCCESS,
ERR_LOG_CODE_SINGLE_ECC_EVENT_OCCURRED,
ERR_LOG_CODE_DOUBLE_ECC_EVENT_OCCURRED,
ERR_LOG_CODE_SINGLE_AND_DOUBLE_ECC_EVENT_OCCURRED
Remarks
This routine does not provide the ECC error address. Please use the user_ecc_events_get routines to retrieve
the addresses.
entrant context.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.6 user_mbist_set
Description
This user API function enables a separate MBIST for all possible reset sources, except POR reset and pin reset.
The MBIST is always performed for POR reset and pin reset. This function rejects with an error in case the NVM
code segment is write protected.
Prototype
int32_t user_mbist_set (
bool bEnable
)
Parameters

bool bEnable Enable the MBIST test execution if the boolean parameter -
is set to TRUE, otherwise disable the MBIST test execution
Return Values

int32_t ERR_LOG_SUCCESS in case the configuration is set successfully, otherwise a
negative error code. Returned error code can be one of the following:
ERR_LOG_SUCCESS,
Remarks
entrant context.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.7 user_nac_get
Description
This user API function reads out the NAC value that is currently configured in the non volatile device
Prototype
uint8_t user_nac_get (void)
Parameters
void
Return Values

uint8_t NAC value that is found in the configuration memory. It returns "wait forever" (0xFF)
in case no NAC value is currently configured in the configuration memory

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.8 user_nac_set
Description
This user API function configures the NAC value in the non volatile device configuration memory.
This function rejects with an error in case the NVM code segment is write protected.
Prototype
int32_t user_nac_set (
uint8_t nac
)
Parameters

uint8_t nac NAC value to be stored in the device configuration -
memory
Return Values

int32_t ERR_LOG_SUCCESS in case of successful write operation, otherwise a negative
error code. Returned error code can be one of the following:
ERR_LOG_SUCCESS,
Remarks
Any NAC value larger than 28 gets clipped to 28.
entrant context.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.9 user_nad_get
Description
This user API function reads out the LIN NAD value that is currently configured in the non volatile device
Prototype
uint8_t user_nad_get (void)
Parameters
void
Return Values

uint8_t The LIN NAD value which is found in the configuration memory. It returns the
default broadcast address in case no LIN NAD value is currently configured in the
configuration memory

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.10 user_nad_set
Description
This user API function configures the LIN NAD value in the non volatile device configuration memory.
This function rejects with an error in case the NVM code segment is write protected.
Prototype
int32_t user_nad_set (
uint8_t nad
)
Parameters

uint8_t nad LIN NAD value to be stored in the device configuration -
memory. Valid range is from 0x80 - 0xFF
Return Values

ERR_LOG_SUCCESS,
ERR_LOG_CODE_ACCESS_AB_MODE_ERROR,
ERR_LOG_CODE_NAD_VALUE_INVALID
Remarks
entrant context.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.11 user_nvm_100tp_read
Description
This user API function reads data from the customer accessible configuration pages (100TP), the read address
is relative inside the configuration NVM area (8x one page, 1024 bytes). An invalid parameter setup (page
number out of range, offset plus count larger than page boundary, count is 0) returns an error, no read
operation is performed. In case of a checksum error, the function also returns an error.
A maximum number of 127 bytes can be read by this function (the last byte contains the checksum and the
byte before the last byte contains the page counter).
Prototype
int32_t user_nvm_100tp_read (
uint32_t page_num
uint32_t offset
void * data
uint32_t count
)
Parameters

uint32_t page_num Page number where to read from. Valid range: 0 to 7 -
uint32_t offset Byte offset inside the selected page address, where to start -
reading. Maximum is 127 bytes. If count plus offset is larger
than 127, an error code is returned
void * data Data pointer where to store the read data. Pointer plus valid -
count must be within valid RAM range or an error code is
returned
uint32_t count Amount of data bytes to read. If count is zero, there is no -
operation and an error code is returned. Maximum is 127 bytes
Return Values

int32_t ERR_LOG_SUCCESS in case of successful read operation, otherwise a negative error
code. Returned error code can be one of the following:
ERR_LOG_SUCCESS,
ERR_LOG_CODE_100TP_PARAM_INVALID,
ERR_LOG_CODE_100TP_READ_ADDRESS_INVALID,
ERR_LOG_CODE_CS_PAGE_CHECKSUM,
ERR_LOG_CODE_CS_PAGE_ECC2READ
Remarks
entrant context.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.12 user_nvm_100tp_write
Description
This user API function writes data to the configuration NVM, the write address is relative inside the
configuration NVM area (8x one page, 1024 bytes). The function supports partial page programming,
preserving page data not passed as new input. The function performs an implicit update of the page checksum
and the write counter. The write counter is increased by 1 at each write operation, when 99 is reached, an error
is reported. The function does not allow the customer to change the page checksum or write counter. An
invalid parameter setup (page number out of range, offset plus count larger than page boundary, count is 0)
returns an error, no write operation is performed. The function also returns an error in case the NVM code
segment is write protected. The write counter and the page checksum are located in the last two bytes of the
page.
The maximum value for writing is 126 bytes.
Prototype
int32_t user_nvm_100tp_write (
uint32_t page_num
uint32_t offset
const void * data
uint32_t count
)
Parameters

uint32_t page_num Page number where to write to. Valid range: 0 to 7 -
uint32_t offset Byte offset inside the selected page address, where to start -
writing. Maximum is 126 bytes.
const void * data Data pointer where to read the data to write. Pointer plus valid -
count must be within valid RAM range or an error code is
returned
uint32_t count Amount of data bytes to write. If count is zero, there is no -
operation and an error code is returned. Maximum is 126 bytes

2024-01-15
MOTIX™ TLE984xQX
User routines
Return Values

ERR_LOG_SUCCESS,
ERR_LOG_CODE_100TP_PARAM_INVALID,
ERR_LOG_CODE_100TP_WRITE_ADDRESS_INVALID,
ERR_LOG_CODE_100TP_WRITE_COUNT_EXCEEDED,
ERR_LOG_CODE_NVM_VER_ERROR
Remarks
entrant context.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.13 user_nvm_config_get
Description
This user API function allows to gather the NVM configuration, this is the number of sectors for user code, user
data and user bsl.
Pointer must be within valid RAM range or an error code is returned.
Prototype
int32_t user_nvm_config_get (
uint8_t * cbsl_nvm_size
uint8_t * code_nvm_size
uint8_t * data_nvm_size
)
Parameters

uint8_t * cbsl_nvm_size Pointer where to store the retrieved NVM cbsl size. -
Valid RAM range is 0x18000000 + device RAM size
uint8_t * code_nvm_size Pointer where to store the retrieved NVM code size. -
uint8_t * data_nvm_size Pointer where to store the retrieved NVM data size. -
Return Values

int32_t ERR_LOG_SUCCESS in case of successful configuration retrieve operation,
otherwise a negative error code. Returned error code can be one of the following:
ERR_LOG_SUCCESS,
ERR_LOG_CODE_NVM_CONFIG_NOT_READY,
ERR_LOG_CODE_USERAPI_POINTER_RAM_RANGE_INVALID

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.14 user_nvm_password_clear
Description
This user API function clears the NVM protection password for a given NVM code or data segment (not
supported for the BSL segment). The password is only removed in case the correct password is provided.
This function only removes the protection password from the device NVM configuration sector. It does not
remove the currently applied NVM HW access protection. The protection will not be applied until the next
system reboot, in case the password got removed successfully.
All NVM segment data (BSL-, Code- and Data- regions) and all passwords are erased in case a wrong password
is provided. Before erasing starts, all interrupts including NMI are temporarily disabled and any NVM and NVM
CS protection is disabled. Once erase is completed, protection and interrupts are restored to their original
state. The current protection status is not touched. The function rejects with an error in case the NVM code
segment is write protected.
Prototype
int32_t user_nvm_password_clear (
uint32_t password
NVM_PASSWORD_SEGMENT_t segment
)
Parameters

uint32_t password Current active password for the segment. A valid -
password parameter consists of a 30-bit password
(bits 0 ... 29), bits 30 and 31 are ignored
NVM_PASSWORD_SEGMENT_t segment Segment where password should be cleared -
Return Values

int32_t ERR_LOG_SUCCESS in case the password could be successfully applied,
otherwise a negative error code. Returned error code can be one of the
following:
ERR_LOG_SUCCESS,
ERR_LOG_CODE_USER_PROTECT_NO_CBSL_PWD_CLEAR,
ERR_LOG_CODE_USER_NVM_PROTECT_SEGMENT_INVALID,
ERR_LOG_CODE_CS_PAGE_ECC2READ,
ERR_LOG_CODE_USER_PROTECT_NO_PASSWORD_EXISTS,
ERR_LOG_CODE_NVM_PROTECT_REMOVE_PASSWORD_FAILED,
ERR_LOG_CODE_USER_PROTECT_NVM_AND_PWD_ERASED,

2024-01-15
MOTIX™ TLE984xQX
User routines
Remarks
entrant context.
6.8.15 user_nvm_password_set
Description
This user API function sets a read and/or write protection for any NVM region individually. The API does not
change the protection state for a region where password protection is currently installed.
The password parameter consists of a 30-bit password (bit 0 ... 29) and two additional protection bits
(bit 30 + bit 31).
A valid password must be different from 0x3FFFFFFF and 0x00000000 (bit 0 ... 29). The two MS bits in the
password contain the protection type, where setting bit 31 activates the read protection and setting bit 30
activates the write protection. A non-compliant password is rejected. The function rejects with an error in case
the NVM code segment is write protected.
A password can only be applied in case no valid password is currently set for the requested region.
Prototype
int32_t user_nvm_password_set (
uint32_t password
)
Parameters

uint32_t password Protection password to apply on the given segment -
NVM_PASSWORD_SEGMENT_t segment Segment which should be password protected -
Return Values

following:
ERR_LOG_SUCCESS,
ERR_LOG_CODE_USER_PROTECT_PWD_INVALID,
ERR_LOG_CODE_USER_PROTECT_PWD_EXISTS

2024-01-15
MOTIX™ TLE984xQX
User routines
Remarks
entrant context.
6.8.16 user_nvm_protect_get
Description
This user API function checks for the currently applied NVM hardware protection status.
Prototype
uint32_t user_nvm_protect_get (
)
Parameters

NVM_PASSWORD_SEGMENT_t segment Which NVM segment to retrieve the current password -
protection status
Return Values

uint32_t Current protection status of the NVM segment selected:
Protection disabled: 0x00000000
read protection enabled: 0x80000000
Write protection enabled: 0x40000000
Read and write protection enabled: 0xC0000000
Segment not recognized: 0xFFFFFFFF

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.17 user_nvm_protect_set
Description
This user API function sets a read and/or write protection for any NVM region individually. The API changes the
protection state for a region, but does not update the installed password in configuration sector.
A valid password must be provided in case any valid NVM protection password is installed for this region.
state.
Set bit 31 of the password parameter to enable read protection, set bit 30 of the password parameter to enable
write protection. The bits (0 ... 29) of the password parameter shall match the password installed before. In
case no valid protection password is currently installed, bits (0 ... 29) are ignored.
Prototype
int32_t user_nvm_protect_set (
uint32_t password
)
Parameters

Return Values

following:
ERR_LOG_SUCCESS,
ERR_LOG_CODE_NVM_PROTECT_REMOVE_PASSWORD_FAILED
Remarks
entrant context.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.18 user_nvm_protect_clear
Description
This user API function clears a read and/or write protection for any NVM region individually. The API changes
the protection state for a region, but does not update the installed password (config sector).
A valid password must be provided in case any valid NVM protection password is installed for this region.
state.
Set bit 31 of the password parameter to enable read protection, set bit 30 of the password parameter to enable
write protection. The bits (0 ... 29) of the password parameter shall match the password installed before. In
case no valid protection password is currently installed, bits (0 ... 29) are ignored.
Prototype
int32_t user_nvm_protect_clear (
uint32_t password
)
Parameters

Return Values

following:
ERR_LOG_SUCCESS,
ERR_LOG_CODE_NVM_PROTECT_REMOVE_PASSWORD_FAILED
Remarks
entrant context.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.19 user_nvm_ready_poll
Description
This user API function checks for the readiness of the NVM module. The API is called within the NVM
programming or erase branch callback operation. It checks if the NVM operation has finished and the callback
could return to the NVM routine.
Prototype
bool user_nvm_ready_poll (void)
Parameters
void
Return Values

bool True in case the requested NVM operation is already finished, otherwise false

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.20 user_nvm_page_erase
Description
This user API function erases a given NVM page (address). In case of an unused (new) page in non-linear sector,
the function does nothing and returns success. In case of erasing a page in linear sector, the function should
always perform the erase.
This function rejects with an error in case the accessed NVM page is write protected.
Prototype
int32_t user_nvm_page_erase (
uint32_t address
)
Parameters

uint32_t address Address of the NVM page to erase. Non-aligned address is -
accepted. Range is 0x11000000 + device NVM size
Return Values

int32_t ERR_LOG_SUCCESS in case of successful erase operation, otherwise a negative
ERR_LOG_SUCCESS,
ERR_LOG_CODE_NVM_ADDR_RANGE_INVALID,
ERR_LOG_CODE_USER_PROTECT_NVM_WRITE_PROTECTED,
ERR_LOG_CODE_NVM_SEMAPHORE_RESERVED
Remarks
This function does not support erasing any 100TP pages.
entrant context.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.21 user_nvm_page_erase_branch
Description
This user API function erases a given NVM page (address) and branches to an address (branch_address) for
code execution during the NVM operation.
Prototype
int32_t user_nvm_page_erase_branch (
uint32_t address
user_callback_t branch_address
)
Parameters

uint32_t address Address of the NVM page to erase. Non-aligned address is -
user_callback_t branch_address Function callback address where to jump while waiting for -
the NVM module to finish the erase operation. Address
must be within valid RAM range (0x18000000 + device RAM
size). RAM end address - 4 is the upper limit
Return Values

ERR_LOG_SUCCESS,
ERR_LOG_CODE_USER_API_BRANCH_ADDRESS_INVALID,
ERR_LOG_CODE_NVM_SEMAPHORE_RESERVED
Remarks
This function does not support to erase any 100TP pages.
entrant context.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.22 user_nvm_sector_erase
Description
This user API function erases the NVM sector-wise. It operates on user code and data NVM region.
Prototype
int32_t user_nvm_sector_erase (
uint32_t address
)
Parameters

uint32_t address Address of the NVM sector to erase. Non-aligned address is -
Return Values

ERR_LOG_SUCCESS,
ERR_LOG_CODE_NVM_INIT_MAPRAM_SECTOR
Remarks
entrant context.
In case of non linear sector, the sector erase function has to run mapram init starting from a random position
to get a random spare page (for the next programming).

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.23 user_nvm_write
Description
This user API function programs the NVM. It operates on the user NVM, as well as on the user data NVM. The API
shall write a number of bytes (count) from the source (data) to the NVM location (address) with the
programming options (options). The options provide parameters like DH and fail scenario handling.
Supported option parameters:
• NVM_PROG_CORR_ACT (Disturb handling & retry enabled)
• NVM_PROG_NO_FAILPAGE_ERASE
The page programming stops at page boundary. If data is lost due to page boundary, an error code informs
that crossing page boundary is not supported. The firmware preserves the non-programmed page data.
Prototype
int32_t user_nvm_write (
uint32_t address
const void * data
uint8_t count
uint8_t options
)
Parameters

uint32_t address NVM address where to program the data. Range is -
0x11000000 + device NVM size
const void * data Pointer to the data where to read the programming data. -
Pointer must be within valid RAM range (0x18000000 +
device RAM size) or an error code is returned
uint8_t count Amount of bytes to program. Range from 1 - 128 bytes -
uint8_t options NVM programming options (e.g. NVM_PROG_CORR_ACT | -
NVM_PROG_NO_FAILPAGE_ERASE)

2024-01-15
MOTIX™ TLE984xQX
User routines
Return Values

ERR_LOG_SUCCESS,
ERR_LOG_CODE_PARAM_INVALID,
ERR_LOG_CODE_USER_CROSS_PAGE_PRG_NOT_SUPPORTED,
ERR_LOG_CODE_NVM_MAPRAM_UNKNOWN_TYPE_USAGE,
ERR_LOG_CODE_NVM_VER_ERROR,
ERR_LOG_CODE_NVM_PROG_MAPRAM_INIT_FAIL,
ERR_LOG_CODE_NVM_PROG_VERIFY_MAPRAM_INIT_FAIL,
ERR_LOG_CODE_NVM_ADDR_RANGE_INVALID
Remarks
entrant context.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.24 user_nvm_write_branch
Description
This user API function programs the NVM. It operates on the user NVM, as well as on the user data NVM. The API
shall write a number of bytes (count) from the source (data) to the NVM location (address) with the
programming options (options). During the NVM operation the program execution branches to a given SRAM
location (branch_address) and continues code execution from there. The options provide parameters like DH
and fail scenario handling.
Supported option parameters:
• NVM_PROG_CORR_ACT (Disturb handling & retry enabled)
• NVM_PROG_NO_FAILPAGE_ERASE
The page programming stops at page boundary. The firmware preserves the non-programmed page data.
Prototype
int32_t user_nvm_write_branch (
uint32_t address
const void * data
uint8_t count
uint8_t options
user_callback_t branch_address
)
Parameters

uint32_t address NVM address where to program the data. Range is -
0x11000000 + device NVM size
const void * data Pointer to the data where to read the programming data. -
Pointer must be within valid RAM range (0x18000000 +
device RAM size) or an error code is returned
uint8_t count Amount of bytes to program. Range from 1 - 128 bytes -
uint8_t options NVM programming options (e.g. NVM_PROG_CORR_ACT | -
NVM_PROG_NO_FAILPAGE_ERASE)
user_callback_t branch_address Function callback address where to jump while waiting for -
the NVM module to finish the program operation. Address
must be within RAM range (0x18000000 + device RAM size).
RAM end address - 4 is the upper limit

2024-01-15
MOTIX™ TLE984xQX
User routines
Return Values

ERR_LOG_SUCCESS,
ERR_LOG_CODE_PARAM_INVALID,
ERR_LOG_CODE_USER_API_BRANCH_ADDRESS_INVALID,
ERR_LOG_CODE_USER_CROSS_PAGE_PRG_NOT_SUPPORTED,
ERR_LOG_CODE_NVM_MAPRAM_UNKNOWN_TYPE_USAGE,
ERR_LOG_CODE_NVM_VER_ERROR,
ERR_LOG_CODE_NVM_PROG_MAPRAM_INIT_FAIL,
ERR_LOG_CODE_NVM_PROG_VERIFY_MAPRAM_INIT_FAIL,
ERR_LOG_CODE_NVM_ADDR_RANGE_INVALID
Remarks
entrant context.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.25 user_ram_mbist
Description
This user API function performs a MBIST on the integrated SRAM. The range to check is provided as parameter.
The function rejects the call in case the parameter exceeds the RAM address range.
Prototype
int32_t user_ram_mbist (
uint32_t start_address
uint32_t end_address
)
Parameters

uint32_t start_address RAM memory address where to start the MBIST test. Range -
is 0x18000000 + device RAM size
uint32_t end_address RAM memory address till where to perform the MBIST test. -
Range is 0x18000000 + device RAM size
Return Values

int32_t ERR_LOG_SUCCESS in case of successful MBIST execution, otherwise a negative
ERR_LOG_SUCCESS,
ERR_LOG_CODE_MBIST_RAM_RANGE_INVALID,
ERR_LOG_CODE_MBIST_FAILED,
ERR_LOG_CODE_MBIST_TIMEOUT
Remarks
Customer needs to make attention to not destroy the BootROM stack pointer.

2024-01-15
MOTIX™ TLE984xQX
User routines
6.8.26 user_nvm_clk_factor_set
Description
This user API function sets the SCU_SYSCON0.NVMCLKFAC divider
Prototype
void user_nvm_clk_factor_set (
uint8_t clk_factor
)
Parameters

uint8_t clk_factor Sets the clock factor directly to the value specified. -
No checks are done on the value. It is the responsibility of
the user to know the range based on device technical
datasheet

2024-01-15
MOTIX™ TLE984xQX
User routines
6.9 NVM protection API types
6.9.1 user_callback_t
Description
User NVM callback function
Prototype
typedef void(* user_callback_t) (void)
6.10 Data types and structure reference

This section contains the reference of data types and structures of all modules.
6.10.1 Enumerator reference

This section contains the enumerator reference.
Table 44 Enumerator overview

Name Description
BSL_INTERFACE_SELECT_t User API BSL interface selection.
NVM_PASSWORD_SEGMENT_t NVM protection API password segment
6.10.1.1 BSL_INTERFACE_SELECT_t
Description
User API BSL interface selection.
Prototype
typedef enum
{
BSL_IF_LIN = 0,
BSL_IF_FAST_LIN = 1,
}BSL_INTERFACE_SELECT_t;
Parameters
Name Value Description

BSL_IF_LIN 0 LIN used as BSL interface
BSL_IF_FAST_LIN 1 Fast-LIN used as BSL interface

2024-01-15
MOTIX™ TLE984xQX
User routines
6.10.1.2 NVM_PASSWORD_SEGMENT_t
Description
NVM protection API password segment
Prototype
typedef enum
{
NVM_PASSWORD_SEGMENT_BOOT = 0,
NVM_PASSWORD_SEGMENT_CODE = 1,
NVM_PASSWORD_SEGMENT_DATA = 2,
}NVM_PASSWORD_SEGMENT_t;
Parameters

NVM_PASSWORD_SEGMENT_BOOT 0 NVM password for customer segment, used
for customer bootloader
NVM_PASSWORD_SEGMENT_CODE 1 NVM password for customer code segment,
which is not used by the customer bootloader
NVM_PASSWORD_SEGMENT_DATA 2 NVM password for customer data segment
6.10.2 Constant reference

This section contains the constant reference.
Table 45 Constant overview

NVM_PASSWORD_PROTECTION_NONE 0x00000000u NVM protection API password protection status NVM
segment no protection enabled
NVM_PASSWORD_PROTECTION_READ 0x80000000u NVM segment read protection enabled
NVM_PASSWORD_PROTECTION_WRITE 0x40000000u NVM segment write protection enabled
NVM_PROG_FLAG_NULL 0x00u NVM programming options No options provided
NVM_PROG_CORR_ACT 0x02u Disturb handling enabled
NVM_PROG_NO_FAILPAGE_ERASE 0x04u Programmed data erased/not erased in case of fail

2024-01-15
MOTIX™ TLE984xQX
Appendix A – error codes

The following table lists all available error codes.
Table 46 List of possible errors during startup

User Error name Error Errors description
API code
x ERR_LOG_SUCCESS 0D No Error
x ERR_LOG_ERROR -1D Standard Error
ERR_LOG_CODE_MEM_READWRITE_PARAMS_INVALID -7D Invalid BSL parameters to
RAM/NVM/NVM_CS read/write
command and/or NVM write
protection is enabled
ERR_LOG_CODE_NVM_IS_READ_PROTECTED -8D No BSL messages are allowed
access when NVM is read protected
ERR_LOG_CODE_NVM_RAM_EXEC_PARAMS_INVALID -9D Invalid BSL parameter to NVM/RAM
EXECUTE command
ERR_LOG_CODE_NVM_ERASE_PARAMS_INVALID -10D Invalid BSL parameters to NVM
erase command
ERR_LOG_CODE_FASTLIN_BAUDRATE_SET_FAIL -11D Invalid FastLIN baudrate
parameter or current BSL interface
is not FASTLIN
x ERR_LOG_CODE_NVM_ADDR_RANGE_INVALID -21D NVM address range is invalid
ERR_LOG_CODE_ECC2READ_ERROR -22D ECC2READ error generated when
reading NVM data
x ERR_LOG_CODE_NVM_SEMAPHORE_RESERVED -24D NVM semaphore already reserved
ERR_LOG_CODE_NVM_ERASE_ADDR_INVALID -27D NVM page erase invalid sector
ERR_LOG_CODE_NVM_SECT_ERASE_ADDR_INVALID -28D NVM sector erase address range is
invalid
x ERR_LOG_CODE_NVM_VER_ERROR -30D 2 or more bit errors detected in
NVM page when verifying NVM data
after linear/mappped page
programming
x ERR_LOG_CODE_NVM_PROG_MAPRAM_INIT_FAIL -31D NVM MapRAM update failed after
mapped page programming or
after execution of DH
x ERR_LOG_CODE_NVM_PROG_VERIFY_MAPRAM_INIT_ -32D NVM programming and MapRAM
FAIL init update failed after mapped
page programming
x ERR_LOG_CODE_NVM_MAPRAM_UNKNOWN_TYPE_U -33D MAPRAM physical page number for
SAGE a given logical sector/page is larger
than the number of physical pages
in a sector
ERR_LOG_CODE_NVM_PAGE_NOT_MAPPED -34D NVM page is not mapped

2024-01-15
MOTIX™ TLE984xQX

API code
x ERR_LOG_CODE_NVM_INIT_MAPRAM_SECTOR -35D Mapped page has double mapping
or ECC2 error when trying to init
MapRAM
x ERR_LOG_CODE_ACCESS_AB_MODE_ERROR -37D Error when setting the assembly
buffer mode
x ERR_LOG_CODE_NVM_PROTECT_REMOVE_PASSWOR -39D Removing region password(s)
D_FAILED failed when trying to remove all
region passwords
x ERR_LOG_CODE_100TP_READ_ADDRESS_INVALID -43D Attempt to read NVM 100TP
address outside of the valid range
x ERR_LOG_CODE_100TP_WRITE_COUNT_EXCEEDED -44D NVM 100TP page write count was
exceeded
x ERR_LOG_CODE_100TP_WRITE_ADDRESS_INVALID -45D Attempt to write NVM 100TP
address outside of the valid range
x ERR_LOG_CODE_CS_PAGE_CHECKSUM -46D NVM config sector checksum
calculation failed
x ERR_LOG_CODE_CS_PAGE_ECC2READ -47D NVM config sector checksum
calculation failure based on NVM
ECC2 error
x ERR_LOG_CODE_MBIST_FAILED -62D MBIST test detected an error
x ERR_LOG_CODE_MBIST_TIMEOUT -63D MBIST test failed due to timeout
x ERR_LOG_CODE_USERAPI_CONFIG_SECTOR_WRITE_ -64D Not allowed to change values in
PROTECTED write protected config sector
x ERR_LOG_CODE_USERAPI_CONFIG_SET_PARAMS_IN -65D Invalid parameters given to
VALID user_bsl_config_set
x ERR_LOG_CODE_NAD_VALUE_INVALID -66D Invalid NAD value given in
user_nad_set()
x ERR_LOG_CODE_100TP_PARAM_INVALID -67D user_nvm_100tp_read/write():
Bad data parameter
x ERR_LOG_CODE_NVM_CONFIG_NOT_READY -68D Data for user_nvm_config_get() is
not available
x ERR_LOG_CODE_PARAM_INVALID -69D user_nvm_write/branch(): data
parameter is invalid
x ERR_LOG_CODE_USER_CROSS_PAGE_PRG_NOT_SUP -70D user_nvm_write/branch cross-
PORTED page programming is not
supported
x ERR_LOG_CODE_USER_PROTECT_NVM_WRITE_PROT -71D user_nvm_write/branch operation
ECTED not allowed when NVM is write
protected
x ERR_LOG_CODE_MBIST_RAM_RANGE_INVALID -72D user_ram_mbist() RAM range for
MBIST is invalid

2024-01-15
MOTIX™ TLE984xQX

API code
x ERR_LOG_CODE_USER_PROTECT_NO_PASSWORD_E -74D user_nvm_password_clear() no
XISTS password installed when trying to
clear password
x ERR_LOG_CODE_USER_PROTECT_NVM_AND_PWD_E -75D user_nvm_password_clear()
RASED wrong password given, all NVM
sections + NVM passwords are
erased
x ERR_LOG_CODE_USER_PROTECT_NO_CBSL_PWD_CL -76D user_nvm_password_clear() clear
EAR password for CBSL not supported
x ERR_LOG_CODE_USER_PROTECT_PWD_INVALID -77D user_protect_password_set()
provided password not valid
x ERR_LOG_CODE_USER_PROTECT_PWD_EXISTS -78D nvm_protect_password_set()
segment password already exists
when trying to set a new one in
x ERR_LOG_CODE_USER_NVM_PROTECT_SEGMENT_IN -79D Provided segment to change
VALID protection is invalid
x ERR_LOG_CODE_SINGLE_ECC_EVENT_OCCURRED -80D user_ecc_events_get()/user_ecc_
get() single ECC event has occurred
x ERR_LOG_CODE_DOUBLE_ECC_EVENT_OCCURRED -81D user_ecc_events_get()/user_ecc_
get() double ECC event has
occurred
x ERR_LOG_CODE_SINGLE_AND_DOUBLE_ECC_EVENT -82D user_ecc_events_get()/user_ecc_
_OCCURRED get() single and double ECC events
have occurred
x ERR_LOG_CODE_USERAPI_POINTER_RAM_RANGE_IN -83D Provided pointer does not point to
VALID a valid RAM range
x ERR_LOG_CODE_USER_API_BRANCH_ADDRESS_INVA -84D Provided callback branch address
LID is not within a valid RAM range

2024-01-15
MOTIX™ TLE984xQX
Appendix B – stack usage of user API functions

The following table lists the maximum used stack for each user API function.
Table 47 Maximum used stack for user API functions

User API function Maximum stack usage (bytes) Maximum stack usage (bytes)
AE step UD step
user_bsl_config_get 8D 8D
user_bsl_config_set 104D 188D
user_ecc_check 72D 68D
user_ecc_events_get 72D 68D
user_mbist_set 104D 188D
user_nac_get 8D 8D
user_nac_set 104D 188D
user_nad_get 8D 8D
user_nad_set 104D 188D
user_nvm_100tp_read 96D 96D
user_nvm_100tp_write 136D 220D
user_nvm_config_get 48D 48D
user_nvm_mapram_init 48D 40D
user_nvm_page_erase 128D 212D
user_nvm_page_erase_branch 128D 212D
user_nvm_password_clear 160D 260D
user_nvm_password_set 152D 236D
user_nvm_protect_clear 184D 284D
user_nvm_protect_get 16D 16D
user_nvm_protect_set 184D 284D
user_nvm_sector_erase 128D 212D
user_nvm_write 224D 276D
user_nvm_write_branch 208D 260D
user_ram_mbist 64D 64D
user_nvm_ready_poll 0D 0D
user_nvm_clk_factor_set 0D 0D

2024-01-15
MOTIX™ TLE984xQX
Appendix C – BootROM user API functions

The following table lists all exported BootROM functions and their addresses that can be called by user code.
Table 48 User API functions adresses

User API function BootROM thumb address
user_bsl_config_get 00000101H
user_bsl_config_set 00000103H
user_nvm_protect_clear 00000105H
user_nvm_protect_set 00000107H
user_nvm_protect_get 00000109H
user_ecc_events_get 0000010DH
user_ecc_check 0000010FH
user_mbist_set 00000111H
user_nac_get 00000113H
user_nac_set 00000115H
user_nad_get 00000117H
user_nad_set 00000119H
user_nvm_100tp_read 0000011BH
user_nvm_100tp_write 0000011DH
user_nvm_config_get 0000011FH
user_nvm_page_erase 00000121H
user_nvm_page_erase_branch 00000123H
user_nvm_ready_poll 00000125H
user_nvm_sector_erase 00000127H
user_nvm_write 00000129H
user_nvm_write_branch 0000012BH
user_ram_mbist 0000012DH
user_nvm_mapram_init 00000131H
user_nvm_clk_factor_set 00000133H
user_nvm_password_set 00000135H
user_nvm_password_clear 00000137H

2024-01-15
MOTIX™ TLE984xQX
Appendix D – analog module trimming (100TP pages)

The TLE984xQX contains 8 x 100TP (100 Time Programmable) pages and each page has a size of 128 bytes but
only the first 126 bytes are usable. The last two bytes of each 100TP page store the programming counter
followed by the page checksum byte.
The first page is 100TP_Page0 and the latest one is 100TP_Page7.
User could read and write into the 100TP pages using the user API functions:
• user_nvm_100tp_read
• user_nvm_100tp_write
In case the checksum of any page is incorrect, the whole content of the 100TP pages is ignored and considered
as unsafe.
Each user_nvm_100tp_write page programming operation leads to a programming counter increase.
user_nvm_100tp_write returns with an error in case the user tries to program one page where the counter has
reached 100 programming cycles. Page programming counter range is from 0 - 99.
The first and second 100TP pages contain customer specific analog module trimming values.
Table 49 100TP page 0 and page 1: analog module trimming registers

Data 100 TP Page 0 100 TP Page 1
offset SFR Registers to TRIM SFR Registers to TRIM
0x00 ADC1_DUIN_SEL ADC1_SQ2_3
0x04 ADC1_MMODE0_11 ADC1_SQ0_1
0x08 ADC1_DCHCNT1_4_UPPER ADC1_OFFSETCALIB
0x0C ADC1_CNT8_11_UPPER
0x10 ADC1_CNT4_7_UPPER
0x14 ADC1_CNT0_3_UPPER
0x18 ADC1_DCHCNT1_4_LOWER
0x1C ADC1_CNT8_11_LOWER
0x20 ADC1_CNT4_7_LOWER
0x24 ADC1_CNT0_3_LOWER
0x28 ADC1_DCHTH1_4_UPPER
0x2C ADC1_TH8_11_UPPER
0x30 ADC1_TH4_7_UPPER
0x34 ADC1_TH0_3_UPPER
0x38 ADC1_TH8_11_LOWER
0x3C ADC1_CTRL2
0x48 ADC1_FILT_LO_CTRL
0x4C ADC1_FILT_UP_CTRL
0x50 ADC1_FILTCOEFF0_11
0x54 ADC1_CAL_CH10_11
0x58 ADC1_CAL_CH8_9

2024-01-15
MOTIX™ TLE984xQX
Table 49 100TP page 0 and page 1: analog module trimming registers

Data 100 TP Page 0 100 TP Page 1
offset SFR Registers to TRIM SFR Registers to TRIM
0x5C ADC1_CAL_CH6_7
0x60 ADC1_CAL_CH4_5
0x64 ADC1_CAL_CH2_3
0x68 ADC1_CAL_CH0_1
0x6C ADC1_SQ10_11
0x70 ADC1_SQ8_9
0x74 ADC1_SQ6_7
0x78 ADC1_SQ4_5
Example
Table 50 100TP analog module trimming example

Code example
#define PAGE0 (uint32_t 0)
#define ADC1_CNT_UPPER_OFFSET (uint32_t 0x0C)
#define ADC1_CNT_UPPER_LEN (uint32_t sizeof(ADC1_TRIM_Data_table))
uint32_t ADC1_TRIM_Data_table[]= {0x11111111, 0x12121212, 0x13131313};
int32_t User_Trimming_100TP(void)
{
int32_t status=0;
status = user_nvm_100tp_write(PAGE0,
ADC1_CNT_UPPER_OFFSET,
ADC1_TRIM_Data_table,
ADC1_CNT_UPPER_LEN);
return status;
}
Description
This function write into the 100TP page 0 at the offset 0x0C, which correspond to the address allowed for
ADC1_CNT8_11_UPPER. The length of the data to write is 12 bytes, which means 3 words:
ADC1_CNT8_11_UPPER, then ADC1_CNT4_7_UPPER and finally ADC1_CNT0_3_UPPER.
This function trims the following registers:
• ADC1_CNT8_11_UPPER = 0x11111111
• ADC1_CNT4_7_UPPER = 0x12121212
• ADC1_CNT0_3_UPPER = 0x13131313

2024-01-15
MOTIX™ TLE984xQX
Table 51 Alternative predefined values to trim in case 100TP page 0 and page 1 CRC is incorrect
100TP page 0
Data offset SFR registers Alternative backup values
0x00 ADC1_DUIN_SEL 0x00000000
0x04 ADC1_MMODE0_11 0x00000000
0x08 ADC1_DCHCNT1_4_UPPER 0x00000000
0x0C ADC1_CNT8_11_UPPER 0x00000000
0x10 ADC1_CNT4_7_UPPER 0x00000000
0x14 ADC1_CNT0_3_UPPER 0x00001b1a
0x18 ADC1_DCHCNT1_4_LOWER 0x00000000
0x1C ADC1_CNT8_11_LOWER 0x00000000
0x20 ADC1_CNT4_7_LOWER 0x00000000
0x24 ADC1_CNT0_3_LOWER 0x00001312
0x28 ADC1_DCHTH1_4_UPPER 0x00000000
0x2C ADC1_TH8_11_UPPER 0xffffffff
0x30 ADC1_TH4_7_UPPER 0xffffffff
0x34 ADC1_TH0_3_UPPER 0xffffc5c0
0x38 ADC1_TH8_11_LOWER 0x00000000
0x3C ADC1_CTRL2 0x00000fff
0x40 ADC1_TH4_7_LOWER 0x00000000
0x44 ADC1_TH0_3_LOWER 0x0000423a
0x48 ADC1_FILT_LO_CTRL 0x0000ffff
0x4C ADC1_FILT_UP_CTRL 0x0000ffff
0x50 ADC1_FILTCOEFF0_11 0x00ffffff
0x54 ADC1_CAL_CH10_11 0x00000000
0x58 ADC1_CAL_CH8_9 0x00000000
0x5C ADC1_CAL_CH6_7 0x00000000
0x60 ADC1_CAL_CH4_5 0x00000000
0x64 ADC1_CAL_CH2_3 0x00000000
0x68 ADC1_CAL_CH0_1 0x00000000
0x6C ADC1_SQ10_11 0x00000000
0x70 ADC1_SQ8_9 0x00000000
0x74 ADC1_SQ6_7 0x00000000
0x78 ADC1_SQ4_5 0x00000000
100TP page 1
Data Offset SFR registers Alternative backup values
0x00 ADC1_SQ2_3 0x00000000
0x04 ADC1_SQ0_1 0x00000000
0x08 ADC1_OFFSETCALIB 0x00000000

2024-01-15
MOTIX™ TLE984xQX
Appendix E – device settings in NVM CS

The BootROM uses pre-configured settings written to NVM CS, which all are used to perform various tasks
inside the device. This section shows the settings used for different modules.
Table 52 BSL module configuration

NVM CS entry Value Description
CS_CUST_BSLSIZE 0x00 Size definition of Customer BSL region:
• 0x00 = CBSL Size is 4 K
CS_NVM_BSL_INTERFACE 0x01 BSL Interface Selection:
• 0x00 = LIN
• 0x01 =FastLIN
CS_NVM_BSL_NAD 0xFF BSL LIN NAD value
CS_NVM_BSL_INTERFRAME_TO 0x0038 BSL FastLIN and LIN interface timeout.
1 step is 5 ms
CS_NVM_BSL_NAC 0xFF BSL NAC value.
1 step is 5 ms up to 140 ms.
0xFF: no timeout used, wait forever

2024-01-15
MOTIX™ TLE984xQX
Table 53 Startup module configuration

CS_SCU_APCLK_CFG 0x02000B00 or PLL divider settings, depends on device variant:
0x02001301 • 0x02000B00 (25 MHz)
• 0x02001301 (40 MHz)
Analog Module Clock Factor (APCLK1FAC)[1:0]:
• 0x00 = divide by 1
Slow Down Clock Divider for TFILT_CLK Generation
(APCLK2FAC) [12:8]:
• 0x01 = fsys/2
• ...
• 0x12 = fsys/12
• 0x1E = fsys/31
• 0x1F = fsys/32
Bandgap Clock Selection (BGCLK_SEL)[24]:
• 0 = LP_CLK is selected
• 1 = fsys is selected
Bandgap Clock Divider (BGCLK_DIV)[25]:
• 0 = divide by 2
• 1 = divide by 1

2024-01-15
MOTIX™ TLE984xQX
Table 53 Startup module configuration

CS_SCU_PLL_DIVIDER_CFG 0x006E or PLL divider settings, depends on device variant:
0x004A • 0x6E (25 MHz)
• 0x4A (40 MHz)
PLL PDIV-Divider [7:6] = Register SCU_CMCON1.PDIV:
• 0x00: PDIV = 4
• 0x01: PDIV = 5
• 0x02: PDIV = 6
• 0x03: PDIV = 6
PLL K2-Divider [5:4] = Register SCU_CMCON1.K2DIV:
• 0x00: K2 = 2
• 0x01: K2 = 3
• 0x02: K2 = 4
• 0x03: K2 = 5
PLL N-Divider [3:0] = Register SCU_PLL_CON.NDIV:
• 0x00: N = 48
• 0x01: N = 50
• 0x02: N = 51
• 0x03: N = 52
• 0x04: N = 54
• 0x05: N = 60
• 0x06: N = 67
CS_NVM_RAM_MBIST 0x0000 RAM test (MBIST) performed during bootup besides POR:
• 0 = disabled
• 1 = enabled

2024-01-15
MOTIX™ TLE984xQX
Appendix F – execution time of BootROM user API functions

The following table lists the execution time of BootROM user API functions.
Table 54 User API execution time

User API function Execution time [ms]
Worst case operation 1) Normal operation 2)
25 MHz 40 MHz 25 MHz 40 MHz
user_bsl_config_get 0.0055 0.0034 0.0055 0.0034
user_bsl_config_set 7.6140 7.5905 7.2771 7.2837
user_ecc_events_get 0.0120 0.0075 0.0120 0.0075
user_ecc_check 4.3929 2.7580 4.3980 2.7524
user_mbist_set 7.6132 7.5958 7.2798 7.2824
user_nac_get 0.0055 0.0034 0.0055 0.0034
user_nac_set 7.6129 7.5949 7.2798 7.2809
user_nad_get 0.0055 0.0034 0.0055 0.0034
user_nad_set 7.6133 7.5948 7.2823 7.2833
user_nvm_100tp_read 0.1235 0.0774 0.1234 0.0774
user_nvm_100tp_write 7.7469 7.6796 7.4167 7.3657
user_nvm_config_get 0.0159 0.0099 0.0159 0.0099
user_nvm_password_clear 7.6547 7.6216 7.3220 7.3090
user_nvm_password_set 7.6550 7.6222 7.3198 7.3092
user_nvm_protect_get 0.0060 0.0038 0.0060 0.0038
user_nvm_protect_set 0.0473 0.0296 0.0473 0.0296
user_nvm_protect_clear 0.0462 0.0289 0.0461 0.0289
user_nvm_ready_poll N.A. N.A. N.A. N.A.
user_nvm_page_erase 4.0914 4.0852 3.9142 3.9174
user_nvm_sector_erase 4.0827 4.0801 3.9062 3.9123
3)
user_nvm_write 3.8392 3.7077 3.6844 3.5645
user_ram_mbist 0.0462 0.0290 0.0462 0.0290
user_nvm_mapram_init 0.0260 0.0163 0.0260 0.0163
user_nvm_clk_factor_set 0.0044 0.0028 0.0044 0.0028
1) Execution time relative to the following conditions : 3 V, 150°C.
2) Execution time relative to the following conditions : 12 V, 25°C.
3) Execution time values when writing to an erased page.

2024-01-15
MOTIX™ TLE984xQX
Appendix G – change of register reset values

Before the BootROM is executing user code, the startup boot sequence has been executed. This means
configuring the device with user parameters, setting up NVM to be ready for the user and other important
system settings. The following tables show an example of a device variant and list the registers with different
default values than what is defined in the specification.
Table 55 General example of registers with changed default values done by bootROM
Module name Register name Default reset value Reconfigured value
T21 CON1 0x00000003 0x00000000
T2 CON1 0x00000003 0x00000000
ADC1 CTRL3 0x401 0x400
LS LS1_TRIM 0 Trimming value
LS2_TRIM 0 Trimming value
HS HS1_TRIM 0 Trimming value
HS2_TRIM 0 Trimming value
MF TEMPSENSE_CTRL 0x03 Trimming value
ADC2 CTRL1 0 Trimming value
LIN CTRL 0x180007 0x180207
SCU VTOR 0 0x02
PLL_CON 0xA4 Device variant dependent
APCLK 0 Device variant dependent
SYSCON0 0x80 0
SYS_STRTUP_STS 0 0x10
OSC_CON 0x10 0x18
NVM_PROT_STS 0 0x403F
SCUPM SYS_SUPPLY_IRQ_CTRL 0xFF 0

2024-01-15
MOTIX™ TLE984xQX
Table 56 Example of registers with changed default values for TLE9844-2QX 1)

Register name Default reset value After reconfiguration
(Evalboard)
Reset type values ADC2
CAL_CH0_1 0000 0000H 0x0000001F
CAL_CH2_3 0000 0000H 0xFE000000
CAL_CH4_5 0000 0000H 0xF103FE00
CAL_CH6_7 0000 0000H 0x0000F004
CTRL1 0000 0000H 0x0000007F
CTRL2 0000 0000H 0x00000481
CTRL4 0000 0000H 0x0000007F
FILT_OUT0 0000 0XXXH 0x00000183
FILT_OUT1 0000 0XXXH 0x00000004
FILT_OUT2 0000 0XXXH 0x0000035C
FILT_OUT3 0000 0XXXH 0x00000273
FILT_OUT4 0000 0XXXH 0x000003B6
FILT_OUT5 0000 0XXXH 0x00000247
FILT_OUT6 0000 0XXXH 0x00000247
SQ_FB 00XX XX0XH 0x00030800
STATUS 0000 0000H 0x00000002
TH0_3_LOWER 9D6F BF25H 0x8F6FBF25
TH4_7_LOWER 00C8 D4D4H 0x00C2CFD4
TH0_3_UPPER EBE9 E9E4H 0xAFE9E9E8
TH4_7_UPPER 00E2 E2FBH 0x00DDDDFB
Reset type values ADC1
CAL_CH0_1 0000 0000H 0xFF170116
CAL_CH10_11 0000 0000H 0x00170018
CAL_CH2_3 0000 0000H 0xFE16FE17
CAL_CH4_5 0000 0000H 0xFE16FF16
CAL_CH6_7 0000 0000H 0x0017FF16
CAL_CH8_9 0000 0000H 0x0017FF18
CNT0_3_LOWER 1213 1312H 0x00001312
CNT0_3_UPPER 1213 1B1AH 0x00001B1A
CTRL2 0000 0000H 0x00000FFF
CTRL3 0000 0401H 0x00000400
FILT_LO_CTRL 0000 FFFFH 0x0000FFFF
FILT_UP_CTRL 0000 FFFFH 0x0000FFFF
FILTCOEFF0_11 00AA AAAAH 0x00FFFFFF
SQ_FB 00XX XX0XH 0x000B6800

2024-01-15
MOTIX™ TLE984xQX
Table 56 Example of registers with changed default values for TLE9844-2QX 1) (cont’d)
(Evalboard)
TH0_3_LOWER 1D2F 423AH 0x0000423A
TH0_3_UPPER AB8D C5C0H 0xFFFFC5C0
TH4_7_UPPER 0000 0000H 0xFFFFFFFF
TH8_11_UPPER 0000 0000H 0xFFFFFFFF
Reset type values CCU6
INP 0000 0000H 0x3940
Reset type values CPU
SYSTICK_CALIB X0XX XXXXH 0
SYSTICK_CVR 00XX XXXXH 0x00FFFFFF
SYSTICK_RVR 00XX XXXXH 0x00FFFFFF
Reset type values GPT12E
ID 0000 0000H 0x00005804
Reset type values HS
HS1_TRIM 0000 0000H 0x09070001
HS2_TRIM 0000 0000H 0x09070001
LS1_TRIM 0000 0000H 0x12033F0F
LS2_TRIM 0000 0000H 0x10033F0F
Reset type values MF
REF1_STS 0000 00C1H 0x000000C5
TEMPSENSE_CTRL 0000 0003H 0x00000201
Reset type values PMU
MON_CNF1 0000 0000H 0x4747C7C7
MON_CNF2 0000 0000H 0x00000047
RESET_STS 0000 0000H 0x000002C8
Reset type values Port
P0_DATA 0000 00XXH 0x0000003A
P2_DATA 0000 00XXH 0x00000004
Reset type values SCU
APCLK 0000 0000H 0x02001301
APCLK_STS 0000 0000H 0x01000000
IEN0 0000 0000H 0x00DFFFFF
NVM_PROT_STS 0000 0000H 0x0000003F
OSC_CON 0000 0010H 0x00000018
PLL_CON 0000 00A4H 0x000000A1
SYS_STRTUP_STS 0000 0000H 0x00000010
SYSCON0 0000 0080H 0
VTOR 0000 0000H 0x00000002

2024-01-15
MOTIX™ TLE984xQX
Table 56 Example of registers with changed default values for TLE9844-2QX 1) (cont’d)
(Evalboard)
Reset type values SCUPM
AMCLK_TH_HYS D4E1 94B3H 0xD4E194B3
1) Order according to Evalboard.
Table 57 Registers with changed default values done by hardware

Module name Register name Default reset value Reconfigured value
PMU RESET_STS 0 0x80

2024-01-15
MOTIX™ TLE984xQX
Terminology
#
100 Time The BootROM offers eight 100 Time Programmable pages to the user mode software. The
Programming size of a 100TP page is 128 bytes. The last two bytes of each 100TP page store the
(100TP) programming counter, followed by the page checksum byte
A
API Application Programming Interface
B
BootROM Device-internal ROM code that the CPU executes directly after reset release
BSL Boot Strap Loader
BSL command The BootROM receives these messages via LIN. A message of this kind contains commands
message and related data. A complete command could consist of multiple messages. The BootROM
processes and execute these commands
BSL response The BootROM replies to BSL command messages by BSL response messages. A response
message message contains requested data or an error code. The response message format and
content depend on the given command
C
CS Configuration sector, see also NVM CS
D
Data block Part of the BSL command message. This block follows a header block for data download
commands.A data block could also be part of a BSL response message if the header block
message requests read-out of some data from the device. The last data block is always
followed by an EOT block
E
EOT block End of Transmission (EOT) block, part of the BSL command message or BSL response
message. This block follows a data block to terminate a larger data download message
F
FastLIN FastLIN is a LIN enhancement supporting higher baud rates of up 230.4 kBd. This rate is
higher than the standard LIN. This mode is especially useful during back-end
programming, where faster programming time is desirable
fINTOSC Internal oscillator (80 MHz)
G
H
HAL Hardware Abstraction Layer. This software layer abstracts all module-specific hardware
registers by API functions. It performs all device hardware register (SFR) accesses, which
includes timing of critical register accesses and polling mechanisms.
This layer exports its functionality to other software modules by means of API functions
Header block Part of the BSL command message. The host initiates a command by sending the header
block. Some commands require further data transmission, during which the header block
is followed by one or multiple data blocks and a terminating EOT block

2024-01-15
MOTIX™ TLE984xQX
Host The host communicates with the TLE984x BootROM device over the LIN interface. The host
sends BSL command messages and receives BSL response messages
I
L
LIN Local Interconnect Network
M
MBIST Memory Built-In Self-Test (MBIST writes and reads all locations of the RAM to ensure that
its cells are operating correctly)
N
NAC No Activity Counter (millisecond timeout counter polling BSL LIN before jumping to user
mode code execution)
NAD Node Address for Diagnostics (LIN protocol parameter)
NVM Non-Volatile Memory (device-internal)
NVM CS NVM configuration sector. The BootROM uses one NVM sector to store device-specific
calibration and trimming values. It configures such values on the device during startup.
This sector also contains the One Time programmable and 100 Time programmable
sectors, which are offered to the user mode software.
The configuration sector is not directly accessible by user mode software
O
OSC Oscillator
P
POR Power-On Reset
PLL Phase-Locked Loop
Q
R
Response block Part of the BSL response message, in which the corresponding BSL command message
does not request read-out of data. This block reports the command execution status
ROM Read Only Memory
S
SA Service Algorithm
SCU System Control Unit
SFR Special Function Register (CPU memory-mapped device hardware registers)
SWD Serial Wire Debug

2024-01-15
MOTIX™ TLE984xQX
T
Tearing Safe The mapping mechanism of the NVM module is intended to be used like a log-structured
Programming file system: When a page is programmed in the cell array, the old values are not physically
overwritten, but a different physical page (the spare page) in the same sector is
programmed in fact. If the programming fails (e.g. because of power loss during the erase
or write procedure), either the old values are still present in the cell array or the verified
new values are present in the cell array. The firmware therefore can program a single page
in a tearing safe way
U
User mode code Customer application code for download and execution in NVM
UART Universal asynchronous receiver/transmitter
V
VTOR Vector Table Offset Register
W
WDT WatchDog Timer

2024-01-15
MOTIX™ TLE984xQX
Revision history
Revision Subjects (major changes since last revision)

Revision 1.04, 2024-01-15
“RAM test (MBIST) and RAM initialization”: added footnote
user_nvm_100tp_read: updated description
Appendix B - stack usage: added values for UD step
Moved “Terminology” and “Revision history” chapters to the end of the user manual
Renamed master to commander and slave to responder
Editorial changes
Revision 1.03, 2022-12-16
Updated Figure 3
Updated Table 51
Change of register reset values updated (Appendix G):
• Updated description
• In Table 55 changed reconfigured value of SCU.APCLK to “Device variant dependent”
• Added Table 56 “Example of registers with changed default values for TLE9844-2QX”
Editorial changes
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 1-
128 bytes
User API user_vbg_temperature_get removed (no possible use-case)
Revision 1.01, 2016-04-05
Initial release

2024-01-15
Trademarks
All referenced product or service names and trademarks are the property of their respective owners.
IMPORTANT NOTICE
Edition 2024-01-15 The information given in this document shall in no For further information on technology, delivery terms
event be regarded as a guarantee of conditions or and conditions and prices, please contact the nearest
Published by
characteristics ("Beschaffenheitsgarantie"). Infineon Technologies Office (www.infineon.com).
Infineon Technologies AG With respect to any examples, hints or any typical
81726 Munich, Germany values stated herein and/or any information regarding
the application of the product, Infineon Technologies WARNINGS
hereby disclaims any and all warranties and liabilities
© 2024 Infineon Technologies AG. of any kind, including without limitation warranties of Due to technical requirements products may contain
All Rights Reserved. non-infringement of intellectual property rights of any dangerous substances. For information on the types
third party. in question please contact your nearest Infineon
In addition, any information given in this document is Technologies office.
Do you have a question about any subject to customer's compliance with its obligations
aspect of this document? stated in this document and any applicable legal Except as otherwise explicitly approved by Infineon
Email: [email protected] requirements, norms and standards concerning Technologies in a written document signed by
customer's products and any use of the product of authorized representatives of Infineon Technologies,
Infineon Technologies in customer's applications. Infineon Technologies’ products may not be used in
The data contained in this document is exclusively any applications where a failure of the product or any
Document reference consequences of the use thereof can reasonably be
intended for technically trained staff. It is the
Z8F80561879 expected to result in personal injury.
responsibility of customer's technical departments to
evaluate the suitability of the product for the intended
application and the completeness of the product
information given in this document with respect to
such application.

Infineon TLE984x Firmware UserManual v01 04 en

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Infineon TLE984x Firmware UserManual v01 04 en

Uploaded by

Copyright:

Available Formats

MOTIX™ TLE984xQX

Microcontroller with LIN and po wer switches for automotive

Firmware User Manual (AE step and UD step)

About this document

Firmware User Manual 1 Revision 1.04

4.3 BSL via FastLIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Firmware User Manual 3 Revision 1.04

Firmware User Manual 4 Revision 1.04

Table 1 Document content description

1.3 Abbreviations and special terms

Firmware User Manual 5 Revision 1.04

2.1 Firmware architecture

Firmware User Manual 6 Revision 1.04

2.2 Program structure

2.3 RAM structure for user

Firmware User Manual 7 Revision 1.04

3 BootROM startup procedure

Clock / PLL Analog Module

Figure 2 Startup procedure architecture overview

The startup code performs different device initialization steps.

Firmware User Manual 8 Revision 1.04

3.1 Startup program structure

Table 2 Functional blocks

3.2 Boot modes

Table 3 BootROM boot modes

Firmware User Manual 9 Revision 1.04

3.3 Debug Support mode entry (with SWD port)

3.4 NAC definition

3.5 User and BSL mode entry (UM)

Firmware User Manual 10 Revision 1.04

3.5.1 Unlock BSL communications

3.5.2 Post user mode entry recommendations

Firmware User Manual 11 Revision 1.04

3.6 Flowcharts for user BSL / debug modes

NVM_CS is Start Timer

Figure 3 Flowchart – start BootROM

Firmware User Manual 12 Revision 1.04

user_mode_entry Init NVM

(NVM init) debug = No

Yes No Wait for

No User code addr. Yes

Re-map vector table to NVM

Loop forever Loop forever

Figure 4 Flowchart – user BSL mode

Firmware User Manual 13 Revision 1.04

3.7 Reset types

Firmware User Manual 14 Revision 1.04

3.8 Startup procedure submodules

3.8.1 Watchdog configuration

3.8.2 RAM test (MBIST) and RAM initialization

1) Valid for AE step only.

Firmware User Manual 15 Revision 1.04

3.8.3 Analog module trimming

3.8.4 Startup error handling

3.8.5 No Activity Counter (NAC) configuration

Firmware User Manual 16 Revision 1.04

3.8.6 LIN Node Address for Diagnostics (NAD) configuration

Firmware User Manual 17 Revision 1.04

4 Boot Strap Loader (BSL)

LIN FAST-LIN NVM /

LIN UART NVM

Figure 5 BSL architecture