DM3725: DSP hangs and ARM is not able to read DSP internal memory

I attached to DSP using CCS before it crashes and when the Linux application exit with "bus error" I try to stop the DSP and I got the error "Trouble Halting Target CPU: Error 0x00000020/-1202 Error".

Linux on ARM is running correctly (but the Linux application has crashed with "Bus Error").

I also tried to attach to ARM, but I got an error. CCS is not configured properly to attach to the ARM since I never been able to do it.

Marco Moschetti said:

I try to stop the DSP and I got the error "Trouble Halting Target CPU: Error 0x00000020/-1202 Error".

See if the below e2e threads will help regarding that error:

Regards,
Pavel

Unfortunately none of this information is useful. I'm able to debug the DSP application before it hangs: ARM/Linux loads it in memory and starts it. Then I attach the debugger to the DSP and when I stop the execution or put some breakpoints it works as expected. I can see the source code, step through instructions, inspect memory. Being highly optimized I can't see local variables, but this is expected.

For what concern the DSPLink: The DSP application is not compiling or linking any code of DSPLink. The library is compiled with PROC component only so it's not necessary to include it on DSP side. On the ARM/Linux side is used exclusively to load the application into memory and start it.

The only communication between ARM and DSP is shared memory. No interrupt is used between the two.

The fact the internal DSP memory is not accesible from ARM sounds to me as an interesting hint. What can have caused this behaviour? An access to DSP internal memory that is still pending? From DSP core or from DMA?

I'm not able to take advantage of DSP/BIOS exception handling. I read on the manual that there is support on DSP/BIOS for exception handling and it is enabled by default. But hitting an invalid pointer leads to debugger unable to stop DSP while I expect this exception to be caught and to find the program counter is some dead end code (i.e. _SYS_abort, _SYS_error, _SYS_exit).

I can see EXC module of DSP/BIOS in the map file, so I'm assuming it's correctly configured.

880732d0   _EXC_clearLastStatus
88075020   _EXC_dispatch
88073154   _EXC_exceptionHandler
107ffb8c   _EXC_exceptionHook
88073120   _EXC_external
107ffb94   _EXC_externalHook
88073100   _EXC_getLastStatus
880730c0   _EXC_init
88072e14   _EXC_internal
107ffb90   _EXC_internalHook
88072de0   _EXC_nmi
107ffb98   _EXC_nmiHook
107ffb38   _EXC_returnPtr
880751e4   _EXC_setReturnPtr
8807276c   _EXC_status
107ffb30   _EXC_sysTrapTable

There's a guide for exceptions handling?

Marco Moschetti said:

The fact the internal DSP memory is not accesible from ARM sounds to me as an interesting hint. What can have caused this behaviour? An access to DSP internal memory that is still pending? From DSP core or from DMA?

Check if DM3725 silicon errata (SPRZ319F) will help, check advisory

Hello Pavel,

thanks for your support.

Advisory 1.35 talks about additional stall, not permanent, more than usually expected, so only a delay, not a crash... correct?

At page 51 of the errata (sprz319f.pdf) I read: "The only issue is that the SDMA/IDMA access potentially exhibits additional unexpected stalling during each of these scenarios"

Is it possible that this causes ARM not being able to access DSP internal memory?