Multi-core debugging on RT11776 causing peripheral initialisation problems

D_TTSA — Fri, 11 Feb 2022 06:04:30 GMT

Good day

I am developing a multi-core project on the RT1176 with the M7 core as the master and the M4 as the slave. By default, when I debug the processor, the launch configurations halt each core at automatically created breakpoints at the top of the M7's and M4's main()s.

In my project, the M7 boots the M4 just before the M7 starts initialising an external flash module I am using. I am using LPSPI to communicate with this module.

After some testing, I saw that the flash initialisation was failing when I debugged the processor. I know the init was failing because I could not read or write the flash module when debugging. This did not occur if the processor was run from a POR (Power On Reset), or from a full system reset.

After a lot of pain and more testing, I found that disabling the debugger's automatic breakpoint at the top of the M4's main() fixed this problem.

To discover why this was the case, I enabled the breakpoint in the M4's main() and then debugged the processor again. I ran the M7 debug but did not run the M4 - it remained halted on the automatic breakpoint. After a while, I paused the M7 core to see where it was. It was hanging in LPSPI_MasterTransferBlocking() - no matter how long I left it to run. I ran and paused it, but it was always somewhere in this function. None of the code in the M7's main() below my flash init function was executed unless I ran the M4's debug.

My colleague ran the same code, but the M7 hung in a different function call. However, he had the same problem with the flash communication not working after a debug.

Anyway, the better solution was to move the code that boots the M4 to after all the M7's peripheral init code has been executed. This way, even though the M4's main() breakpoint still halts the M7, this does not break any of the M7's functionality.

I hope that my above explanation can be of some use to someone in future so that they don't have to suffer through the same painful process.

I would like NXP's technical support team to explain why the automatically created breakpoint at the top of the M4's main() makes the M7 hang.

Re: Multi-core debugging on RT11776 causing peripheral initialisation problems

jingpan — Mon, 21 Feb 2022 07:59:18 GMT

Hi @D_TTSA ,

I can't image why the M4 core initializing breakpoint can cause LPSPI accessing spi-flash fail. Maybe it's a timing issue? Does the external spi-flash need reset when reboot the system?

Can you use a oscilloscope or a logic analyzer to trace the SPI signal?

Regards,

Jing

topic Re: Multi-core debugging on RT11776 causing peripheral initialisation problems in i.MX RT Crossover MCUs

Multi-core debugging on RT11776 causing peripheral initialisation problems

Re: Multi-core debugging on RT11776 causing peripheral initialisation problems