I have an application running on an LPC4357, that uses both the M4 and M0 cores, which works almost all of the time. One of the features we use is being able to control which application the M0 is running, so we can do different types of acquisition, or reset the internal state of the application we're running.
The problem I'm seeing is that about 1 out of every 200 times, the M0 doesn't come out of reset. I can repeat the issue reliably by continually resetting the M0, until eventually it stops exhibiting its normal behaviour (writing to shared memory, and sending event interrupts to the M4).
Our M0 reset code looks like this (uses NXP BSP library) :
// Make sure the M0 core is being held in reset via the RGU
// clear out the memory
memset((void*)M0_APP_LOCATION, 0, M0_APP_MAX_SIZE);
memset((void*)M0_MEM_LOCATION, 0, M0_MEM_SIZE);
// Copy image to execution location
memcpy((void*)M0_APP_LOCATION, (const void*)pimage->start, size);
if(memcmp((void*)M0_APP_LOCATION, (void*)pimage->start, size))
DEBUGSTR("* Verification Failed - Aborting\n");
/* Keep in mind the M0 image must be aligned on a 4K boundary */
Chip_CREG_SetM0AppMemMap(M0_APP_LOCATION); // Location is 0x20000000
// release from reset
DEBUGSTR("* M0 released from reset\n");
After resetting the M0 until it doesn't work, I can stop the M4 in the debugger, and I see the following values on these related RGU registers:
According to these, the M4 should assume that the M0 core is out of reset, and running.
Once it fails to come out of reset, subsequent commands don't cause it to recover. I also can't connect to the M0 over JTAG once it fails. I checked the errata, and RESET.1 and RESET.2 seem similar to the problem I'm seeing, but don't mention this M0 behaviour.
I've never noticed this issue when the processor first starts up and runs our default M0 appliation. It's only after we stop and start the M0 that it fails.