AM5716: A15 is stalled by DSB instruction

Hello Kuerbis,

The DSB instruction ensures all direct and indirect data fetches the A15 has outstanding have completed (with respect in time to the DSB instruction).  A hang on a DSB happens when one of the outstanding data accesses does not complete at some level in the memory system.

The most common reason for a hang is some target's state machine stuck or crashed after accepting the A15's data request. It might be the A15 directly asked for data (say accessing a register) which didn't respond or it might be some other master-slave access which shares the access path with the A15 didn't progress.

One of the more common hangs scenarios I've seen is in relation to a PCI connected slave. If that external slave crashes while an access it is party to is outstanding, a master like the A15 can be impacted.  EG: the a15 was reading some exported register of the PCI device, EG, the PCI device was moving data into DDR and the A15 needs to fetch from a similar address range (~2K window) in DDR.

That external crash could be due to bad system-level programming, voltage instability, or others.  In these cases, the system hardware or software needs to be fixed and well validate to ensure the system works properly.

When the failure happens and the rate of failure are critical clues.  If it hangs every time some device is in use and no other time then that is useful information.  When it hangs very sparsely (say once a week) its harder to track down.  Main bus protocol violations generally need to use a watchdog to recover from.

Debugging often requires checking the DBGPCR in the A15 to see what instruction it's hung at, then looking at the instruction flow path into that point in the code.  Often hardware ETM processor trace is helpful here.  Other forms of more course-grained logging can help, but if the processor is running at 1.5GHz many instructions and paths can be followed between printf system logging point.   For one issue in my mind, I was able to use a high speed current probe to find a current signature going into the hang which I could map back to a section of code.   Along with the DBGPCSR, using JTAG or other logging means to capture the interconnect FLAGMUX registers.  They will show if a path has timed out.    In general, fast reproducing issues, can be resolved with some system debugging, sparse issues are much harder to find.   Sometimes a rack of units is needed to speed up the debug.

This kind of hang event tends to be seen during new code development and then drops off as the system matures.  It is again seen during final stress testing.  Really a lot more context is needed to solve these issues.   Following good practices during initial design tends to result in few or no hangs at the end of the process.

Regards,

Richard W.