• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 31 subscribers
  • Views 933 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.

Question about DMA write size

Westin Sykes
Expert 1315 points

If my DMA write size is set to 64 bytes, is it actually implemented as a single atomic write? I know from the Hercules technical reference that an element cannot be interrupted, but could code running on the CPU reading from the DMA destination ever see a partial write?

  • 0
    TI__Mastermind 22715 points
    It will be a single write.

    Thanks and regards,

    Zhaohong
  • 0 in reply to Zhaohong Zhang
    Expert 1315 points
    Is there any documentation discussing this and other things like DMA performance for this? I found one for the TMS320C620x, but not this.
  • 0 in reply to Westin Sykes
    TI__Mastermind 22715 points
    I am not aware of any documents about DMA performance. Do you have any specific concerns?

    Thanks and regards,

    Zhaohong
  • 0 in reply to Zhaohong Zhang
    Expert 1315 points
    The only concern is that we may be relying on the 64 bits being atomic in transmission of CAN messages in our safety critical application. Is there any documentation to back up your claims? We would feel more comfortable having a document of some sort to look back at in the future we suspect something may be going wrong.

    Thanks,

    Westin
  • 0 in reply to Westin Sykes
    TI__Mastermind 22715 points
    Westin,

    In this case, the data coming out of DMA is a single 64 bit data. Since the interface to CAN and other peripherals are 32 bit wide, it will be broken into two 32 bit writes to CAN in the bridges.

    I feel a little uneasy about "we may be relying on the 64 bits being atomic in transmission of CAN messages in our safety critical application" and would suggest more system analysis about what you want to achieve at system level.

    Thanks and regards,

    Zhaohong
  • 0 in reply to Westin Sykes
    TI__Expert 6985 points

    Hi Westin,

    Can you please explain us, why do you think that you rely on the 64 bits to be atomic for a CAN transmission?

    Receive mailboxes and DMA transfers can be handled via the special (DMA dedicated) interface register set IF3. The observation flags do act on 32 bit registers, not 64 bits, but also ensure that all bytes are read before enabling the IF update again.
    For transmit mailboxes you have to set the Message Number in the IFxCMD register after you updated the data in the IFxDATA / IFxDATB registers to transmit the message.
    So I don't see why there should be any issues with any write or read size of the DMA combined with the DCAN.

    Best Regards,
    Christian

  • 0 in reply to Christian Herget
    Expert 1315 points

    The heart of our issue is that we want to have our CAN device set up such that it is not limited to receiving in only 64 CAN mailboxes. Our solution to this is to use 63 of the mailboxes for normal use, and use the last one as a catch-all which takes all identifiers that aren't associated with one of the other mailboxes. This mailbox will be used to make software mailboxes for the rest of the CAN identifiers. To do this, We have DMA set up with the 64th mailbox such that it sends all messages in it into a buffer which is periodically scanned through to process new messages and move them to the correct software mailbox. In order to do this scanning, we need to know where DMA is writing to next. I have found no consistent way of doing this from the DMA registers. My alternate solution was to have some 64 bit "DataInvalid" number I would write to the copied CAN data bytes in addition to clearing the IF3 update flag in the copied CAN message to mark it as invalid after processing a message. This way, I can just read messages in the DMA buffer until I get to one that is marked as invalid then stop. Note that we are not saying the DataInvalid is actually an invalid message. If we see this message with the IF3 update flag set, we assume it is a message coming in, but we cannot say that for sure because it could just be the data that was sent in. This is extremely unlikely the case, but it is possible. At this point, we stop processing the DMA buffer, wait a while, and come back to it assuming the DMA transmission is complete. The only thing I see that could be wrong with this approach is that if the 64 bit write is not atomic, it would be possible for me to see a message that looked like a valid message, but was really a message that was being copied in. With 64 bit atomic writes, the data bytes in the message, the last 64 bits, would be either totally the DataInvalid number or the new number. If we checked to see if the CAN data was equal to DataInvalid after seeing that the IF3 update flag was set for a message not equal to DataInvalid, and we caught it part way through the DMA write to the data bytes, we would very likely see that it was different than the DataInvalid bytes if the 64 bit write was not atomic. If you have a better solution for checking where the next place DMA will be writing to, I would be happy to hear it. Hope that clears it up.

    Thanks,

    Westin

  • 0 in reply to Westin Sykes
    TI__Expert 6985 points

    2656.RM48HDK CAN DMA FIFO.zipHi Westin,

    I guess I got your point. As Zhaohong wrote, the write or read will be atomic unless a bridge split it. If you write to the SRAM the whole busses between the DMA and the SRAM are 64 bit wide and thus the 64 bit write will be atomic. However the issue would be, that you need to copy more than just 64 bit from the CAN to the SRAM, assuming you also want to copy the ID field (IF3ARB).

    I wrote a circular DMA buffer example for the DCAN some years ago, you can find the example attached. There I also used a magic number (all zero in ARB) to indicate invalid messages. To prevent the DMA to overwrite messages in the circular buffer I utilized the MPU inside of the DMA. In that way you can block the access to the buffer you want to read next and ensure that the DMA has finished its write access to the buffer, otherwise the MPU would indicate an region violation.

    I hope this helps you with your implementation. But please note that this is just an example and you should carefully think through it as it might not be bulletproof.

    Best Regards,
    Christian

  • 0 in reply to Christian Herget
    Expert 1315 points
    That is good enough for me. Thanks for the information.