• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 97 subscribers
  • Views 554 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

How do you reset an EDMA3 transfer controller/recover from a TC 'bus error'?

Tim James
Prodigy 160 points

Hi

I am using QDMA to perform memory copies in a C6455 (and eventually a C6457).  This memory copy function is used, amongst other things, to help implement a memory read request supported by the application's debugging interface.  I have found that if I 'accidentally' read unmapped memory, eg, the memory directly below chip-select 2, the transfer controller detects a bus error and essentially kills the EDMA3 peripheral and requires a power-on/system reset to recover. 

I have implemented an interrupt handler to catch and clear this error condition but cannot work out how to abort/reset the affected transfer controller; even when I have cleared the error flag the transfer controller remains in the active state, effectively preventing any further transfers on that controller.  Whilst such an error should not normally occur I would like to make my code robust enough to be able to recover from this error condition.  Unfortunately the documentation does not appear to cover what steps should be taken to recover from transfer controller errors beyond explaining how to clear the error event flag.  There appear to be a lot of status registers associated with the transfer controller, so I can see that a transfer is (not) in progress, but no obvious controller reset/transfer abort mechanism.  Can you help?

Regards

Tim

  • 0
    TI__Genius 14545 points

    Tim,

      The source/destination are controlled within the Parameter Set Entries (PaRAM Set Entries). Are these being dynamically set before you trigger off a QDMA transfer?

    Is there anyway you can perform a bounding check on the PaRAM Set Entries before you trigger the QDMA channel to make sure it falls within the memory mapped registers or is this approach not an option?

     

  • 0 in reply to dabuan
    Prodigy 160 points

    Hi Drew

    Thank you for your response.  The destination address is passed in by the user.  Whilst we could perhaps apply a number of range checks I was rather hoping we could avoid this because in the main these represent unecessary code/processor time.  Rather, I was hoping to make the code more robust so that it could recover and continue in the event that something goes wrong.  I seem to be able to detect the event occurring, ie, the bus error event, so presumably if you can tell me how to purge/reset/abort the current transfer being performed by the transfer controller I should be able to put the necessary steps in my ISR and thereby allow the system to recover.

    Cheers

    Tim 

  • 0 in reply to Tim James
    TI__Genius 14545 points

    Tim,

    From a specification point of view, when a EDMA3 TC sees an error, it will simply report the error and continue on. There are two scenarios that are likely in play here.

    [1] The TC remains 'active' because it is processing additional transfer requests.

    [2] Writing to an undefined region of memory has undefined results. (Most likely the scenario based upon your results).

    On a lot of the older devices, accessing a undefined region in the memory map was considered outside the use case, and would sometimes result in a hung bus depending on the memory address you were trying to access. With a hung bus, there is no way to correct for this other than to reset the device. On newer devices this has been corrected and therefore the bus will automatically recover even if you write to a memory location that is not defined. Unfortunately the C64x devices fall into the 'older devices' category and thus you will probably have to provide bound the source/destination addresses to fall within the defined regions of the memory map in order to prevent the device from hanging.

    Have you tried to perform a soft reset of the device to see if the TC recovers when the error interrupt is generated?