• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 1517 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.

AM571x MMC1 bad access interrupts

Christian Fisahn
Intellectual 330 points
Other Parts Discussed in Thread: AM5716

Hello,

we have our vxWorks SD card driver using MMC1 host controller of the TI AM5716 CPU now running to operate with master DMA access, means we are using CMD17/CMD24 for read/write blocks of 512 Bytes from/to the SD card using the master DMA of the host controller and interrupts to get the end of DMA signaled. We still got bad access interrupts sporadically.

We have set using Lauterbach a read/write breakpoint on the data register of the host controller MMC1 (b.s 0x4809C220 /READWRITE /ONCHIP) to ensure that the CPU does not occasionally access the register when using DMA. The debugger does not break.

We also got bad access interrupts before where we have not used DMA but reading the data register from the CPU (where we also got too less data at the beginning of the block, 4 or 8 Bytes (1 or 2 words) too less).

 We wait in the driver after doing a block transfer for the end of DMA (interrupt status Bit 3 end of DMA 0x00000008)  and after that for the end of data transfer (Bit 1 0x00000002), which could be set before or after the DMA complete bit in our code.

We have no overlapping commands or accesses (only one task which does the access to the SD card block after block).

 Do you know any reason or cause why we could get a bad access interrupt signaled (and may be also corrupt data)?

Thank you,

Best regards,

Christian Fisahn

  • 0
    TI__Guru**** 393215 points
    Hi Christian,

    I'm afraid this forum supports only the TI provided Linux and RTOS SDK's. VxWorks is a third-party product and we don't have support for it.
  • 0
    TI__Guru* 83985 points

    Hi 

    From the documentation i see the following on bad access data interrupt

    -----

    29 BADA Bad access to data space
    This bit is set automatically to indicate a bad access to buffer when not allowed:
    -This bit is set during a read access to the data register (MMCHS_DATA) while buffer reads are not
    allowed (MMCHS_PSTATE[BRE] =0)
    -This bit is set during a write access to the data register (MMCHS_DATA) while buffer writes are
    not allowed (MMCHS_STATE[BWE] =0)
    Write 0x0: Status bit unchanged Write 0x1: Status is cleared Read 0x1: Bad Access
    Read 0x0: No Interrupt.
    RW 0

    ----

    Is your driver honoring the status of these bits in PSTATE register and ensuring no accesses via the CPU and DMA are being made when  bits are set to 0?

    Regards

    Mukul 

  • 0 in reply to Mukul Bhatnagar
    TI__Genius 10180 points
    Hello!

    I am in agreement with Mukul BADA only happens when there is a prohibited access to the MMCHS_DATA register. This either happens when read occurred while the buffer is not yet filled with data with length specified by MMCHS_BLK[BLEN], or when a write occurred when not enough space is available.

    Although BRE and BWR are two status bits only applicable to the CPU, DMA should also follow the same accessing scheme and only access MMCHS_DATA when proper data/spaces are available. If it doesn't, BADA will still occur. Given the customer is using master EDMA mode, would be great if they can double check to see if PSTATE[25] ADMAE was also set when BADA occurred. Knowing this may help further isolate whether issue happened during ADMA access or CPU access.


    Thanks & Regards,
    Shiou Mei