Hi Giovanni,
I'm debugging the new SDIO code now. There seems to be some intermittent issue on the writes.
If I let my test read/write code run freely it gets stuck on the sdc_write loop:
do {
if (sdc_lld_send_cmd_short_crc(sdcp, SDC_CMD_SEND_STATUS,sdcp->rca, resp) || (resp[0] & SDC_R1_ERROR_MASK)) return TRUE;
sts = SDC_STS(resp[0]);
} while ((sts == SDC_STS_RCV) || (sts == SDC_STS_PRG));
It seems it never gets out of SDC_STS_PRG. However if I put a breakpoint and pause before the call to write() it has no problem.
I'll continue poking.
Ian
Debugging SDIO
Moderators: RoccoMarco, lbednarz, tfAteba
Re: Debugging SDIO
If I add a delay before the call to write() it works.
delay( 450 ); Doesn't work, write() hangs up
delay( 475 ); write() works fine
with void delay( volatile uint32_t steps ) { while (steps-->0); }
Some sort of wait for something to settle from the previous operation?
Ian
delay( 450 ); Doesn't work, write() hangs up
delay( 475 ); write() works fine
with void delay( volatile uint32_t steps ) { while (steps-->0); }
Some sort of wait for something to settle from the previous operation?
Ian
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Debugging SDIO
Hi Ian,
Could you try to put a chThdSleepMilliseconds(1) within the loop? also testing another brand of card could give us more info. The card should exit the PGM state after a while, may be the continuous polling interferes with its internal process. It would also be useful to try testing after disabling the 4bits bus mode.
I will try to reproduce the problem here in the weekend.
Giovanni
Could you try to put a chThdSleepMilliseconds(1) within the loop? also testing another brand of card could give us more info. The card should exit the PGM state after a while, may be the continuous polling interferes with its internal process. It would also be useful to try testing after disabling the 4bits bus mode.
I will try to reproduce the problem here in the weekend.
Giovanni
Re: Debugging SDIO
Hmm. More testing:
With 4 bit wide:
- Works with 128Mb original card, does not work (hangs on write) on 2 Gb fast card.
- But both work reliably on the equivalent example with STLib
With 1 bit wide:
- It fails with either card on reading the first byte? (I replaced the parameter to set_bus_wide() to be 1bit)
I'll continue debugging against the STLib example.
With 4 bit wide:
- Works with 128Mb original card, does not work (hangs on write) on 2 Gb fast card.
- But both work reliably on the equivalent example with STLib
With 1 bit wide:
- It fails with either card on reading the first byte? (I replaced the parameter to set_bus_wide() to be 1bit)
I'll continue debugging against the STLib example.
Re: Debugging SDIO
More testing. Now I went to your testhal code. I find that the *first* time a high address is written to (say, 0x200000) the dma transfers stops and STA has 0x408, which I am guessing is a timeout.
#define SDIO_STA_DTIMEOUT ((uint32_t)0x00000008) /*!<Data timeout */
#define SDIO_STA_DBCKEND ((uint32_t)0x00000400) /*!<Data block sent/received (CRC check passed) */
From then on writing to that address works fine. Other than that, the testhal code seems to work fine and not get stuck.
The other code I am testing is a fatfs example. Is it possible this is the same issue, just showing up in different parts? This code works using STLib calls, so maybe it's a difference on timeouts or other settings?
ian
#define SDIO_STA_DTIMEOUT ((uint32_t)0x00000008) /*!<Data timeout */
#define SDIO_STA_DBCKEND ((uint32_t)0x00000400) /*!<Data block sent/received (CRC check passed) */
From then on writing to that address works fine. Other than that, the testhal code seems to work fine and not get stuck.
The other code I am testing is a fatfs example. Is it possible this is the same issue, just showing up in different parts? This code works using STLib calls, so maybe it's a difference on timeouts or other settings?
ian
Re: Debugging SDIO
ianmga wrote:More testing. Now I went to your testhal code. I find that the *first* time a high address is written to (say, 0x200000) the dma transfers stops and STA has 0x408, which I am guessing is a timeout.
#define SDIO_STA_DTIMEOUT ((uint32_t)0x00000008) /*!<Data timeout */
#define SDIO_STA_DBCKEND ((uint32_t)0x00000400) /*!<Data block sent/received (CRC check passed) */
From then on writing to that address works fine. Other than that, the testhal code seems to work fine and not get stuck.
ian
Ok, I narrowed the testhal code down to start(),connect(), and write(), and got it to timeout with the STLib equivalent code as well. This particular problem happens with a multiblock write with 2 or more blocks, and it's a hardware issue with this particular card. It's not clear yet if this is related to why the fatfs example doesn't work, but I'll look at this next.
Ian
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Debugging SDIO
Actually, the reason I had to bend over backwards to find a fast 2 Gb card was because I wanted a fast card and I read somewhere in the forum or documentation that the fatfs example didn't support cards over 2Gb. It is very difficult to find a fast card (class 2+) that's less than 4Gb.
Ian
Ian
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Debugging SDIO
Hi Ian,
I found something interesting on the ST forum, I don't know if it is related to what you are experiencing but it is sure an integration problem with FatFs:
https://my.st.com/public/STe2ecommuniti ... tviews=517
I think I can fix this issue by programming the memory side DMA port to 8, 16 or 32 bytes depending on the passed pointer alignment, I will test this in the weekend and commit the changes. If you have news on the other issue please let me know.
Giovanni
I found something interesting on the ST forum, I don't know if it is related to what you are experiencing but it is sure an integration problem with FatFs:
https://my.st.com/public/STe2ecommuniti ... tviews=517
I think I can fix this issue by programming the memory side DMA port to 8, 16 or 32 bytes depending on the passed pointer alignment, I will test this in the weekend and commit the changes. If you have news on the other issue please let me know.
Giovanni