S32 Debugger has a set of scripts for each NXP device that it supports. The scripts are either executed from the S32DS IDE (selected in Debug Configurations) or from GDB command line (for example in regression suites). All scripts are written in Python and by default run in gdb-python environment built with Python version 2.7.x. Scripts have a dependency on Python Enum package. Please refer to /S32DS/help/pdf/S32DS_Installation_Guide.pdf about details. Most common initialization scripts that are used with S32DS bare board projects are called *_generic_bareboard.py. These scripts initialize SRAM, ECC, disable watchdog interrupts, bring main Arm cores out of reset and put them in the debug state. Accelerator cores are typically not enabled in *_generic_bareboard.py. They should be initialized either in the application or by *_generic_bareboard_all_cores.py script. S32 Debugger scripts that are used to attach to the core that has already been initialized are called *_attach.py. No hardware initialization or reset is performed by these scripts. *_attach_first_instruction.py scripts halt the cores at the first instruction to be executed if the device is booted from flash and the application starts in SRAM. *_generic_bareboard__lockstep.py scripts configure the lockstep mode if supported by the target. There are also scripts that program flash via JTAG (*_flash.py) and initialize DDR (*_generic_bareboard_*_ddr_*.py). *_i2c_RCON.py configures the boot options for the device (QuadSPI, eMMC, SD). Common Known Issues and Limitations for NXP devices that are supported by S32 Debugger: - Attempt to read/write the peripheral registers will fail if the peripheral module is not initialized and clocked properly. Workaround: do not read/write registers of uninitialized peripheral module. Remove uninitialized peripheral registers from the S32DS IDE view before restarting the debug session. - Eclipse CDT may not handle cases when identical cores are executing same elf code. It will treat multicore debug session as a single core session. The total number of the HW breakpoints and watchpoints will be set to the number of the HW breakpoints and watchpoints of the single core. - Reset detection is not supported in S32 Debugger. The user should avoid resetting the target when the debug session is in progress. - S32 Debugger does not alter MPU configuration (on cores that implement MPU). If the user application is configuring MPU in such a way that it disables write permissions for the memory on which the code is executed, the debug session may become unstable due to the fact that S32 Debugger will be unable to set software breakpoints. - All cores on S32 devices have a limited number of hardware breakpoints and watchpoints. Max number of hardware breakpoints and watchpoints could be found in S32DS device specific README.txt files and in *_cores.py script. More info about GDB breakpoints and watchpoints can be found here: https://sourceware.org/gdb/onlinedocs/gdb/Set-Breaks.html https://sourceware.org/gdb/onlinedocs/gdb/Set-Watchpoints.html - CDT/Eclipse limitation: A hardware breakpoint set at the address (from either disassembly view in S32DS IDE or from GDB command line) will show up in each debug context (thread) and may affect starting the debug session. Workaround: Avoid setting hardware breakpoints at the address. - Due to the possibility of muxing JTAG pins while using S32 Debug Probe, the debug connection may be affected (lost). SWD debugger connection should be used when modifying GPIO signals, and S32 Debugger does not support SWD. SWO trace should be disabled if using the GPIO on the pin. - GDB limitation: Printing the variable in a different format (p /x /o /t) may not be correct. GDB takes the bits of the value as an integer and prints it in hex/octal/binary format. For floating point variables GDB first performs conversion to an integer and then displays the value in hex/octal/binary format. For example for the value 2.1 GDB will display only 0x2 and not 0x4000cccccccccccd (correct value). - Attaching to C++ project with semihosting enabled may cause inconsistent debugger behavior since I/O descriptors have not been initialized on the host during attach debug session. - Using the "Set program counter at" functionality in Design Studio debug configuration will only set the program counter to the specified value, but will not trigger an update in the UI (call stack and disassembly view). Any subsequent run control operation will continue execution from that PC and the core will continue execution upon hitting a stop condition, in which case UI will be updated. - Performing run control debug operations (ex. stepping/resuming) right after scrolling or resizing Disassembly view (while the debugger is still fetching data from memory to update the view) may lead to the unpredictable behavior. Device-specific Known Issues and Limitations can be found in S32Debugger User guide files for the corresponding target in \S32DS\help\pdf folder