M4 Segger jlink debug reset

gerko · November 9, 2023, 4:51am

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?

Best
Gerald

henrique.tx · November 13, 2023, 12:42pm

Hi @gerko !

Thanks for reaching out to Toradex Community

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,

henrique.tx · November 13, 2023, 8:38pm

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,

gerko · November 20, 2023, 2:56pm

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)

Best
Gerald

gerko · November 21, 2023, 8:28am

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:

First

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

Second

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!

gerko · November 22, 2023, 12:29pm

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.

Best
Gerald

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

gerko · November 27, 2023, 2:21pm

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.

henrique.tx · November 27, 2023, 2:24pm

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

Best regards,

gerko · December 7, 2023, 10:41am

There’s no way to say “OK, I have to deal with it.”

In particular, developing an RPMSG in x tasks application can be extremely stressful.
Now I also had to realize that the #.bin file that you store under /var and then load into the M4 via UBOOT when booting up is not always exactly the one you just copied. Not even after a sync or sync -f. I’m completely at a loss.

henrique.tx · December 7, 2023, 3:00pm

Hi @gerko!

This is strange

If you need help with it, could you please create a new thread for this?

Since this topic is solved, it is better from an organizational point of view to have a new topic for a different issue.

Thanks for the comprehension

Best regards,