ADSP-21584 failed to reprogram: failed to set expression, $RCU0_MSG, with the value, 1572864

A bit more information: after a power cycle of the board we can connect by setting the debugger to not reset the chip and to load symbols only.

When connected we see the PC at 0x0, and we are unable to write to any of the registers. 

Hi,

Apologies for delay in response.

Could you please confirm whether you are still facing same behavior with specific machine and same setup with same driver, ldr and configuration file (same commands) work as expected in other machines.

If you have access to ez-kit, please try with same setups on that specific machine and let us know how you gets on.This will help us to isolate whether issue is related to specific board.

Also, if possible could you please try same with cldp.exe included with latest CCES version. You can download and install the latest CCES 2.10.0 from the below link.
download.analog.com/.../ADI_CrossCoreEmbeddedStudio-Rel2.10.0.exe

If still facing issues, could you please share us the driver and configuration files that you are using to program using the cldp.

Best Regards,
Santhakumari.K

Correct, we did see the issue across different boards. We do not have access to an EZ-kit, but saw the same issue on newer CLDP.

I believe it is an issue with the software loaded on the unit: we haven't seen it with older software builds, and newer ones seem to not have this issue. 

One thing we did to bypass the issue was bringing all of the Boot Mode pins low. In this state I believe the SHARC doesn't load from Flash, and basically will be in a waiting state. We are able to reflash the device in this state without issues.

I can provide the driver and configuration as needed. One question I have is where in the chain does RCU0_MSG get set to values that are output? I assume they will trace to something as it is informational output... do you know if this is documented anywhere?

Hi Antony,

The RCU_MSG register is a general purpose register used by the boot ROM for updating the status of different stages in the boot process. The same register can also be used for handshaking between the cores.

You can find more details on RCU_MSG register on page no: 6–15 from the below linked ADSP-SC58x/ADSP-2158x SHARC+ Processor Hardware Reference manual.
www.analog.com/.../SC58x-2158x-hrm.pdf

Please refer the below link, which might be helpful to you.
ez.analog.com/.../128654

Regards,
Santhakumari.K

Thank you! While initially looking up the RCU_MSG register I was under the impression that it was just a 32-bit register; I missed the bit definitions on the hardware reference manual.

It looks like the  C1ACTIVATE and C2AVTIVATE bits aren't being set.. I will reference the other thread to see how those fit in, and that gives me something to look into.

For anyone experiencing this issue, we seem to have found a solution.

The issue appears to arise when a core (core 1) crashes; in our case the core's stack pointers do not point to valid internal memory. We are unclear as to how that happens. 

In the event where the crash is unpreventable (as was the case for us a few times), we found the following to work:

- Debug a bootloader image, using the ezkitSC584_preload_core0_v01, and a bootloader program to core 0. 

      - Note we ended up using the release build version, and didn't test the debug build version. 

- This debug should go fine, allowing you to attach a debugger. We mark that the image is bad in the bootloader code which prevents the image from loading. 

- The bootloader you loaded can then accept an image to flash over a serial interface, we have a serial port usart that we were able to program over.

Using those steps we were able to overwrite the image in flash, and recover the processor. I was not able to program using jtag using this method, other than to load a bootloader and invalidate the image. So a non-jtag programmer may need to be used/developed.

Hope this helps someone,

Jordan

Thank you Jordan. To add to the discussion (which I will mark as an answer) we went ahead and grounded all of the Boot Mode pins which put the bootloader in an "idle" state. From there we were able to debug and load through the JTAG as usual, overwriting the bad code with a known good image.

The root cause in our issue wasn't the stack, but an error in how we implemented the FFT and how it interacts with interrupts. Same effect though: the Core crashes immediately.