• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 99 subscribers
  • Views 511 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.

dm365 SDIO byte-mode transfer problem

Craig Smith
Intellectual 810 points

Hello all, I am having a problem with odd size byte transfers (CMD53 writes) over SDIO with the dm365 to a WIFI device (by "odd" I mean not evenly divisible by 4). However, it's not ALL odd sizes, only certain odd sizes.

For example, a 121 byte write succeeds no problem, but a 125 byte write does not. By "does not succeed" I mean that I do not see the DATDNE status bit set in the MMCST0 register after submitting the transfer. For a successful write, the interrupt status MMCST0 is 0x1005 (TRNDNE, RSPDNE, DATDNE), for an unsuccessful write the status is 0x1004 (TRNDNE and RSPDNE only).

There are no errors reported and the DMA transfer completes with no errors. Also, I believe the write actually works (because for example, I see the resulting UDP wireless transfer succeed) but for some reason the completion is not reported by the MMC/SD controller and subsequent attempts at transfers fail intermittently.

Like I said, not all odd value transfers fail. The failures sizes start at 125 and are grouped like this (byte counts):

125, 126, 127

189, 190, 191

253, 254, 255

317, 318, 319

381, 382, 383

etc.

I can provide more details if anyone is interested. Please let me know if you have any ideas or clues about what is going on here. Thanks.

 

Regards,

-Craig

  • 0
    Intellectual 810 points

    I figured out what my problem was, so I thought I'd post it in case someone else runs across this issue.

    The problem was the "FIFO empty" condition was not being triggered by always transferring blocks of 32 bytes (which is still needed to trigger the DMA events). This caused the FIFO write pointer to get too far ahead of the read pointer for certain boundary conditions. Thus, the DATDNE bit not being set. The solution was to create an extra DMA transfer for the odd bytes (in byte mode) so this condition is avoided. 

    I figured this out by simply checking MMCST1 (which I wasn't before mistakenly thinking it was for the 2nd MMC controller). 

    Regards,

    -Craig