LinkServ or redlink as gdbserver for command-line debugging on i.MX RT

[stefanct]

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

1. this would be a supported use case (we don't want to be forced to run eclipse for  developing, CI, manufacturing, or automatic testing).
2. LinkServer gdbserver should make sure that the emulator and MCU is in a viable state to actually debug.
3. LinkServer gdbserver should support talking to gdb via pipes.

cheers (and thanks erich for your blog posts on linkserver and scp scripting - invaluable)

[AdrianOltean]

I've been using "/usr/local/LinkServer/LinkServer gdbserver -a MIMXRT1021" in the background and then connecting to it from within gdb

Note that you're enabling "attach" mode by passing "-a". That's why you need to manually do all the other stuff you describe. See LinkServer's help sections (for "gdbserver" in particular).

Normally, if you don't initiate an "attach" debug session, LinkServer would execute the reset and also the required scripts when a GDB client connects to the gdbserver. For more details about what scripts are associated for each target, you can also inspect the json files available in the <LinkServer>/devices folder. These json files are somehow similar to the XMLs used by the IDE - you can also find the memory map defined in these.

Regards,

Adrian

[stefanct]

You are totally right about -a but that doesn't change a whole lot about the rest.
I could not get linkserver to work at all without -a before. I did not investigate that enough previously and LinkServer doesn't propagate errors to the user without increasing the log level. It simply disconnected the connecting gdb client immediately again without any indication what's wrong. The underlying reason for that is that my board is missing the external flash and the flash driver unsurprisingly has problems talking to it. I don't have that problem with Eclipse though... why?

But using a custom json without the flash section it gets past that, OK. However, the other problems are basically the same as mentioned before. I have to do a single step, then load again, before everything is working correctly etc.