• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 121 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSPM0G3507: How to determine DMA channel causing the data/address error

Norbert Daser
Prodigy 20 points
Part Number: MSPM0G3507

Tool/software:

Hello,

while porting the device to our internal library we faced the problem, that we can not determine which channel triggered the data / address error. This would be needed to map into our generic implementation where the user have the possibility to subscribe for each channel callbacks in case of transmition complete / half complete and also in case of a error.

Did we miss some information from the datasheet?

BR and thank you for your input

Norbert

  • +1
    TI__Genius 15690 points

    Hi Norbert,

    Since the interrupt register only tells you whether an error occurred or not, and there is no additional register indicating which channel caused the error, you'd need to do some checking on your end. In your DMA address error interrupt handler you could check that the address in each DMASA[y] exists within the device's valid range (as well as your application's). Using this you could find which channel triggered the interrupt.

    For the data error, you can check the ECC error information to find which address has the bad ECC, then you can see which DMASA or DMADA matches. The FLASHDEDADDR register will contain the address with the ECC error.

  • 0 in reply to Dylan OBrien
    Prodigy 20 points

    Hello Dylan,

    thank you for this input. Basically you are saying that we haven't missed something from the datasheet. We were also thinking about your suggestion but I couldn't believe as usually such errors are available per unit/channel. From my perspektive this is something what would be well suited for the driver lib to make the users life more easy. What do you think?

    BR

    Norbert

  • 0 in reply to Norbert Daser
    TI__Genius 15690 points

    I agree that this would be a convenient thing to have inherently in the hardware. Something like what I describe above to identify the error channel would be a good item to include in the SDK, definitely agree there. I'll ping our software team to see if this is something we can add in future releases.