NB: I am using an .elf file that has been linked to RAM instead of flash.
I've been using "/usr/local/LinkServer/LinkServer gdbserver -a MIMXRT1021" in the background and then connecting to it from within gdb (via "target extended-remote :3333"). This works in principle to control the MCU but has some major problems if the device is not in the correct state. Normally, (i.e. with any gdb server from any other mcu vendor) one can tell gdb to transfer the binary with "load" and start debugging. With NXP an additional step is necessary to get the device into a sane state by using the .scp scripts interpreted by redlink. When using MCUX the respective script gets run before a gdb is connected but when simply using "LinkServer gdbserver" this does not happen and makes debugging impossible.
To work around this, one has to run "/usr/local/LinkServer/LinkServer probe 0 runscript /usr/local/LinkServer/binaries/Scripts/RT1020_connect.scp" before running LinkServer as gdbserver.
But then it does not work still. I am not 100% sure why the debugger or mcu is not in the right state by then but loading a binary does not result in the memory to be written correctly with the instructions. I have to so a single step ("si") before issuing the load command. Then it finally works.
This is still quite complicated because it requires LinkServer to be run separately in the background since it does not support talking to gdb via pipes.
Alternatively, using redlink directly one can simply use it from within gdb... the only disadvantage is that one needs the XML files describing the memory layout (generated by MCUX when starting a debug session).
target extended-remote | \
/usr/local/LinkServer/binaries/crt_emu_cm_redlink \
-x ${xml_dir}/ \
-pMIMXRT1021xxxxx \
--rtos on \
--mi \
--connectscript RT1020_connect.scp"
I've spent way too much time getting this to work. Hopefully it help somebody else.
From NXP I'd wish that
- this would be a supported use case (we don't want to be forced to run eclipse for developing, CI, manufacturing, or automatic testing).
- LinkServer gdbserver should make sure that the emulator and MCU is in a viable state to actually debug.
- LinkServer gdbserver should support talking to gdb via pipes.
cheers (and thanks erich for your blog posts on linkserver and scp scripting - invaluable)