topic uSDHC FIFO in i.MX Processors

uSDHC FIFO

mrlantz — Tue, 25 Feb 2014 13:48:40 GMT

I use a polled system without DMA. When filling the 128 worlds FIFO with a write water mark of 128 words and 8 word burst I get sporadic problem that BWEN are set to 0 and do not change. The water mark should set when BWEN should be activated. But independent BWEN should be set to 1 when the FIFO is empty and it should be empty when all the bytes are transferred. The water mark should only protect the FIFO from bursting to many bytes when the FIFO are almost full. So why could this happened and what should be considered when this problem occur.

There is an remark that water mark is only for DMA but it seems to be working for non DMA modes anyway. Should I use another check for FIFO ready bit or it is okay to use the water mark.

When the stuck state happens I also get the following state:

Data line 0 are low, data timeout (DTOE) and transfer complete (TC).

Full memory dump:

________address|________0________4________8________C

AZSD:0219C000|>00000000 00FF0200 006E0100 193A0000

AZSD:0219C010| 00000900 FFFFFFFF 320F5913 00D04F01

AZSD:0219C020| FE8D8188 08800024 000A0207

AZSD:0219C030| 00100002 157F51FF 157F51FF 00000000

AZSD:0219C040| 07F30000 08800880 80000022 00000000

Re: uSDHC FIFO

Yuri — Thu, 13 Mar 2014 10:32:04 GMT

According to section 67.4.1 (Data Buffer) of the i.MX6 DQ Reference Manual :
“CPU polling mode:

* For a host read operation, when the number of words received in the buffer

meets or exceeds the RD_WML watermark value, by polling the BRR bit, the

Host Driver can read the Buffer Data Port register to fetch the amount of words

set in the RD_WML register from the buffer. The write operation is similar.”

This means, as stated in section 67.4.1.1 (Write Operation Sequence) :
“When the internal DMA is not used, (the DMAEN bit in the Transfer Type register is not

set when the command is sent), the uSDHC asserts a DMA request when the amount of

buffer space exceeds the value set in the WR_WML register, and is ready for receiving

new data. At the same time, the uSDHC sets the BWR bit. The buffer write ready

interrupt will be generated if it is enabled by software.”

So, please use the BWR bit before FIFO filling.

Next, as for the DTOE event -”the uSDHC will not start data transmission until the number
of words set in the WR_WML register can be held in the buffer. If the buffer is empty and the
Host System does not write data in time, the uSDHC will stop the CLK to avoid the data buffer
underrun situation.”

Re: uSDHC FIFO

mrlantz — Tue, 25 Mar 2014 06:34:08 GMT

Hi,

When using only the BWR instead of BWEN I get the same problem but if I change the WR_WML from default 128 to 32 the problem do not trigger. But as stated in the spec the WR_WML should only be used in DMA mode that I do not use so why does this affect the behavior in polled mode?

I also want to highlight that even if problem with BWR and BWEN was removed I now get error higher up in the software stack and it feels that I have the same issue but now in a different area of the software stack. I was planning to get back with a more detailed description of the new problem but I will not be able to finish in time before my business trip. I will read mail but will not be able to run any test without may lab so it could be that I cannot respond during the coming week.

One more thing that are important is that I cannot see this problem when running the same code and setup on a SoloLite device. Only problem with Solo.