I am trying to debug the NXP BESS demo board with S32K358 micro using their provided debug configuration "Reference_Application_1500_Debug_FLASH_PNE_group" with my new Multilink Universal FX but am running into an issue where the debug process claims the 'monitor' command is not supported. I get a message box the quickly flashes and then disappears on its own with the caption "Error" and the message "Runtime error 216 at 515BA7AE". The Debug Console has the following output:
GNU gdb (GDB src=g2b2d27aa26 bld=gd2333b8c -v s=GDB-12-1 -L64 -W32 Earm) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=i686-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>;.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>;.
For help, type "help".
Type "apropos word" to search for commands related to "word".
monitor setexceptioncatching 2033
load C:\\NXP\\workspaceS32DS.3.5_BESS\\Reference_Application_1500_M7_0_0/../Reference_Application_1500_M7_0_2/Debug_FLASH/Reference_Application_1500_M7_0_2.elf
Loading section .flash, size 0x535a4 lma 0x800000
Loading section .ARM.exidx, size 0x8 lma 0x8535a4
Loading section .sram_data, size 0x1070 lma 0x8535ac
Loading section .non_cacheable_data, size 0x118 lma 0x85461c
Start address 0x00800420, load size 345908
Transfer rate: 1449 KB/sec, 1091 bytes/write.
load C:\\NXP\\workspaceS32DS.3.5_BESS\\Reference_Application_1500_M7_0_0\\Debug_FLASH\\Reference_Application_1500_M7_0_0.elf
Loading section .s32_saf_bss_sram_2, size 0x20 lma 0x204b0100
Loading section .qspi, size 0x8 lma 0x68000000
Loading section .flash, size 0x77a28 lma 0x400000
Loading section .ARM.exidx, size 0x8 lma 0x477a28
Loading section .sram_data, size 0x2be0 lma 0x477a30
Loading section .non_cacheable_data, size 0x2ac lma 0x47a610
Loading section .shareable_data, size 0xb0 lma 0x47a8bc
Loading section .flash_1, size 0x20 lma 0x600000
Loading section .flash_2, size 0x20 lma 0x9fffe0
Loading section .flash_3, size 0x20 lma 0xa00000
Loading section .dflash, size 0x20 lma 0x10000000
Start address 0x00400c20, load size 502292
Transfer rate: 1597 KB/sec, 1070 bytes/write.
monitor endmultiload
Remote communication error. Target disconnected.: No error.
monitor selectcore 0
"monitor" command not supported by this target.
continue
The program is not being run.
******** End of Log ********
I have updated the Multilink Universal FX's firmware (11.52) and set the target architecture to "ARM" using the Multilink Firmware Config Utility. I have tried other, more simple projects and get the same result. I've been working with NXP support, but they suspect this is a debugger issue.
Thanks,
Brian
Any feedback on next steps?
It seems that all I needed was to check the "Delay after reset and before communicating to target for" option and set the delay value to 500 ms. I walked the value down as low as 50 ms, and it seems to still be working.
To clarify, the change mentioned above is in the "Debug Configuration", on the "PEMicro Debugger" tab, in the "Target Communication Speed" group.
Hi,
The "Delay after reset and before communicating to target for" option is designed to add a pause after the target device has been reset and before the programming or debugging tool attempts to communicate with it.
This delay is important to accommodate the behavior of the reset circuitry on the target board. Often, the reset signal line has components such as capacitors or reset ICs that cause the reset signal to rise or stabilize more slowly than an ideal sharp edge. If the debugger or programmer tries to communicate with the target immediately after releasing reset, it might fail because the target is not ready yet.
Typically, this delay is around 200 milliseconds. It is particularly useful for devices and boards that have a reset circuitry causing slower reset signal stabilization. Adding this delay can improve communication reliability and reduce errors related to timing issues after reset.
Do you mind giving me the exact part number of your eval board?
I am still trying to get the exact one that you have to replicate the issue. If I can replicate it, we may consider making the 50 ms reset delay a default for this device so that other users do not run into this same issue when they are working with this eval board.
Thank you for bringing it to our attention.
Regards,
Johnny
PEmicro