M4 Segger jlink debug reset

I would like to program and debug the M4 (0 and 1) in the Apalis iMX8QM module on a EVB + Segger Jlink.
Debugging is unexpected. Most reliable only after a complete hardware reboot and in a stopped U-Boot.
In particular, after executing a faulty program, a new debug session fails.
I suspect that a clean reset is not being performed.
Which reset strategy is used on the M4 in the imx8qm? Are there any known problems?


Hi @gerko !

Thanks for reaching out to Toradex Community :slight_smile:

Could you please share the output of tdx-info? (reference: Getting Device Information with Tdx-Info | Toradex Developer Center)

Also please share the version of the Apalis Evaluation Board you are using.

Although you are most probably aware, we have an article related to this topic: Cortex-M JTAG Debugging | Toradex Developer Center.

Could you specify which kind of faulty program? There are different kinds of faulty programs. Depending on the kind of fault on the Cortex M, you might be blocking it in a way that simply starting a new debug session might be not enough to start the core again.

I am not aware of any problems. The knowledge that we have around it is the content in the article I shared above.

Checking U-Boot’s source code, there is a function to start the cores and, if I understood it correctly, it will be called if the Auxiliary Core (the Cortex-M) is powered off: cpu.c « imx8 « mach-imx « arm « arch - u-boot-toradex.git - U-Boot bootloader for Apalis and Colibri modules

Digging into SCU’s API it could be possible to find a (cold) reset function to forcibly restart the Cortex-M. However, I am just not aware of the effects of doing it as the power domain of the Cortex-M might be shared with other important interfaces/devices.

Is resetting the whole CPU a problem for you (is it blocking you)? From resetting until U-Boot and loading the firmware to the Cortex-M doesn’t take so long.

Best regards,

Adding more comments here.

A possible cause for blocking the Cortex-M is that it is falling into some exception that your firmware is not treating accordingly. To do so, you would need to follow the related manuals to find out how to do it.

Depending on the type of the exception, a full reset of the hardware is the only way of recovering from it.

Best regards,

Sorry for the delay.
I will follow all of your advice and let you know if I gain any new insights.

quickly by the way

root@apalis-imx8-07278575:/var/rootdirs/home/torizon# tdx-info

Software summary
Bootloader:               U-Boot
Kernel version:           5.15.77-6.4.0-devel+git.ddc6ca4d76ea #1-TorizonCore SMP PREEMPT Thu Jun 29 10:14:22 UTC 2023
Kernel command line:      pci=nomsi root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/9a1bb57840c71afd6cacfbfef155b33ef10ed2fe9eeb77127f86093aae73d3e0/0
Distro name:              NAME="TorizonCore"
Distro version:           VERSION_ID=6.4.0-devel-20231006084430-build.0
Hostname:                 apalis-imx8-07278575

Hardware info
HW model:                 Toradex Apalis iMX8QM V1.1 on Apalis Evaluation Board
Toradex version:          0037 V1.1E
Serial number:            07278575
Processor arch:           aarch64

The EVB Version is: V1.1C (00000588)


I actually wanted to keep the thread general. But yes, we have to differentiate between handled and unhandled exceptions. And also the case when NO error has occurred and you want to change a value of a constant, for example.

However, to be clear, here are 2 examples:

  • Deviating from the article above, I use Windows 11 and VSCode.
  • From the MCUXpresso SDK Builder I load a demo standalone project ‘hello_world_m41’.
  • I use the ‘build_debug.bat’ to build the program and get a .elf and a .bin file.

now I have 2 options:


  • I configure the ‘launch.json’ so that the *.elf file is loaded onto the module before the debug process
  • A UART transceiver attached to the corresponding pins receives the ‘hello world’ and entered characters are sent back
  • … everything works as it should


  • I copy the *.bin file into the /var folder on the module and have the program pushed onto the M4 via the U-Boot an run it. (You can find instructions for this here How to Load Compiled Binaries into Cortex-M)
  • Now I can attach the debugger to the current running process
  • for this I use a new entry in the ‘launch.json’ > “configurations” where “request” is changed to “launch”.
  • works the same way

I just want to describe how it should normally work.

Here I have to point out another problem.
I’m using ‘Arm GNU Toolchain arm-none-eabi/12.2 rel1’. When calling ‘build_debug.bat’ from powershell the build process runs without an error message.
However, if the batch file is started as a ‘preLaunchTask’, a number of error messages appear. e.g.:
…\hello_world_m41\utilities\fsl_sbrk.c:22:1: error: unknown type name ‘caddr_t’
Apparently '__GNUC__' is not defined.
But that’s another problem. A debug without prelaunch works. I have to run the build prozess manually.
Or I use this as env in ‘tasks.json’ "ARMGCC_DIR": "C:/Program Files (x86)/GNU Tools ARM Embedded/8 2018-q4-major"
This also needs to be solved. I still have to check whether there are different behaviors.

Now I have to work out a concrete example in which the strangeness occurs.
It probably boils down to the fact that, especially under freeRTOS, you can provoke undefined states that require a complete reset.
However, this reset is a little more special in multi-core processors.

See you later!

It is difficult to create a comprehensible situation.
It happened in the following case:

  • From the NXP SDK we take a normal hello_world_m41 and a freertos_lpuart_m41.
  • In VSCode we start debugging the freertos_lpuart_m41 project using F5.
  • You can also provoke a buffer overrun there.
  • Stop this debugging and then switch to the hello_world_m41 project and run and debug it using F5.

If necessary, you can repeat this a few times.
At some point it is no longer possible to debug a program that normally runs smoothly.

@henrique.tx I now need to know whether this is only the case in my programming environment.


These problems also occur when trying around, exclusively in the ‘freertos_lpuart_m41’ project.

After further attempts I evaluate the following statement:

as answer / solution.
We have to be aware that the M4 MCU is not a stand-alone Cortex M4 that has its own peripherals.

Hi @gerko !

That’s indeed true!

Thanks for marking this topic as solved, but would you be able to explicitly state what you did to solve your issue? It would be valuable for other Community users :slight_smile:

Best regards,