This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VM: System bus response priority configuration

Part Number: TDA4VM

Hi,

Recently, we found that the debugger could not stop the CPU while it was waiting for the pcie bus to respond. Is there a way to configure the bus response priority to ensure that debug commands are correctly responded to by the CPU whenever possible.

What is described in Chapter 3 of the chip manual(System Interconnect) seems relevant to what we need. If the configuration described here can meet our needs, can you provide an example of the configuration for our reference?

Thanks.

  • Hello,

    For an ARM CPU to enter debug halt mode which allows the debugger to take control of the CPU, the CPU pipeline must first complete its in flight transactions. If that CPU has a stalled transaction to a PCI window then the debugger will not be able to halt that CPU.  There is not a bus timeout which can be enabled at the interconnect level to break this condition for the main interconnects.   However, you should be able to halt another other CPUs which are not blocked or connect to the debugger's DAP port.  At times I find the debugger cannot halt a ARM CPU (say A72), I do usually attach to the DAP port, then I try and read that CPUs DBGPCSR which is exported per that CPUs APB. The APB network is independent of the of the system interconnect so it should not be hung.

    For previous TDA (A15 based) devices I have seen hangs associated with a PCI space. In most of those cases the external PCI device stopped suppling a required hardware clock and this resulted in a path hang. In some cases if the clock could be forced to resume, the system would become unstuck.

    Regards,

    Richard W.

  • Hi Richard,

    If I understand this correctly, you mean that if for any reason the PCIe interface "hangs" there are no mechanism to unstuck the ARM cores with a data abort or other ?

    Best regards

  • Hello John,
    If the PCIe block for some reason does not complete (violates) the infrastructure bus protocol then the only way to clean it up would be through something like a watchdog.  It would depend on your system architecture as to if this failure were factored into the restart.  There will not be a way to set any kind of 'granular' fault recovery point at the bus level as it would require a lot of expensive state tracking.  Very complex multi-phase high performance buses will have many transactions in flight in parallel, as such 'simple' resets just don't work unless a ton of state is tracked.
    I won't try and speculate about other PCIe IP failure modes and how to recover from them. I can say if the bus protocol is violated the system will likely need to go through some sort of reset to clear it.  For higher safety compliance related IPs (I do not think PCIe is one of them) there will be some documented sequence which needs to be followed. 
    Failures like you are taking about here tend to happen if external clock hardware fails due to some reason (like power plane glitches and such) or system level programming violations.  These are generally fatal.
    Regards,
    Richard W.
  • Hi,

    So since there is no "watchdog" integrated withing the PCIe IP, there is no way to report a bus error to the transfer initiator to complete the transaction ?

    Would a reset of the initiator core be sufficient or would it also require a complete PCIe reset ?

    Best regards

  • Hello John,
    I suspect a large reset (whole chip or at least a main domain reset) would be needed to clear it.  Depending on the endpoints involved you might experiment to see the effects of resetting each endpoint to see if it cancels the transaction cleanly.   Async resets of large and complex IP in the middle of activity can unwind in nonintuitive ways (both in big HW and big SW).  Maybe for your the most common usage you can find a reset which cleanly terminates the transaction but I doubt all corner cases would be covered. Large scope watchdogs have to be there, however, hopefully they only happen sparsely.
    Regards,
    Richard W.