stm32f4 discovery fatfs problem

[JamesS]

Nope. Nothing has worked.

I tried the testhal sdiotest and the output hangs..

ChibiOS/RT Shell
ch> sdiotest
Trying to connect SDIO... OK
*** Card CSD content is: 400E0032 5B590000 1D8A7F80 A4040B8
Single aligned read... [board is well hung at this point.]

James.

[JamesS]

The test does an sdcRead(...) and gets to;

Breakpoint 1, sdc_lld_wait_transaction_end (sdcp=0x20003680, n=1, resp=0x20007074)
at ../os/hal/platforms/STM32/sdc_lld.c:170
170 if ((SDIO->STA & SDIO_STA_DATAEND) == 0) {
(gdb) p *(0x40012c34)
$1 = 8

8 == SDIO_STA_DTIMEOUT

So, in the sdiotest I put the single aligned read into loop...

Code: Select all

do {
        chprintf(chp, "Single aligned read...");
        chThdSleepMilliseconds(1000);
} while (sdcRead(&SDCD1, 0, inbuf, 1));

And the result... 2 tries to get it to work.

ChibiOS/RT Shell
ch> sdiotest
Trying to connect SDIO... OK
*** Card CSD content is: 400E0032 5B590000 1D8A7F80 A4040B8
Single aligned read...Single aligned read... OK
Single unaligned read... OK
Multiple aligned reads... OK
Multiple unaligned reads... OK
Register working area for filesystem... OK
Mount filesystem... OK
FS: 965346 free clusters, 8 sectors per cluster, 3954057216 bytes free
Create file "chtest.txt"... [Now it is well hung here]

f_open returned FR_DISK_ERR.

After a soft reset and run the test command again, it completes with only 1 try of the single aligned read test.

Again from a cold start, I traced through the f_open code and the familiar occured;

(gdb)
170 if ((SDIO->STA & SDIO_STA_DATAEND) == 0) {
(gdb)
171 chSysUnlock();
(gdb)
172 return CH_FAILED;
(gdb) p *(0x40012c34)
$1 = 8
(gdb)

and we return to the cmd_sdiotest routine and call chSysHalt();

Q: Should the low level system retry a few times before giving up?

James.

[JamesS]

I changed sdc_lld_read to look like

Code: Select all

  
int retries = 10;
  bool_t rv;
  do {
   rv = sdc_lld_read_aligned(sdcp, startblk, buf, n);
  } while (rv != CH_SUCCESS && --retries);

  retries = 10 - retries;
  if (max_retries < retries) max_retries = retries;

  return rv;

And made max_retries a global and checked it in main. Most retries was 1, and the system completed the sdiotest flawlessly a dozen times at least.

This is on an Olimex-E407 board, and there are 33k pullups on the data lines 0..2 and CMD, but a 1M pull down on D3. Hmm.

James.

[Giovanni]

Hi,

There is a pending change/fix to be done on the SDIO driver, it is possible it is related to this problem, you may give it a try: viewtopic.php?f=16&t=1567

Giovanni

[JamesS]

Thanks, Giovanni, but it didn't help.

I reverted sdc_lld.c and moved the SDIO->DCTRL = ... code to before sdc_lld_prepare_read(...). From the sdiotest code I got;

ChibiOS/RT Shell
ch> sdiotest
Trying to connect SDIO... OK
*** Card CSD content is: 400E0032 5B590000 1D8A7F80 A4040B8
Single aligned read...Single aligned read... OK
Single unaligned read... OK
Multiple aligned reads... OK
Multiple unaligned reads... OK
Register working area for filesystem... OK
Mount filesystem... OK
FS: 965346 free clusters, 8 sectors per cluster, 3954057216 bytes free
Create file "chtest.txt"...

At which point the board was well hung.

I grabbed a copy of ChibiOS from SVN trunk a day or two ago and built my app with that. It built clean except for a redef of STM32_VOS in mcuconf.h. After commenting that line it built and runs just the same. I note that the above mentioned "fix" is not in the SVN version.

The condition I often see is that the SDIO->STA register has the DTIMEOUT flag set in sdc_lld_wait_transaction_end().

So, I've now made the above mentioned fix, and I've changed SDC_READ_TIMEOUT_MS from 5 to 50. Three runs of sdiotest have worked fine. Also, my additions to main() that read a file and display the contents on the terminal when fs_ready becomes true appears to now be working also. Great news!

Perhaps the 5ms timeout was just too short for my SD card? It's a 4GB Sandisk Micro SD HC (4) speed rating.

Regards,
James.

[JamesS]

The 5ms timeout change to 50ms has certainly improved matters, but I'm not quite out of the woods.

I can run the sdiotest command from the shell as many times as you like, and it succeeds every time without needing to retry.

I have a function that opens a file on the SD card, reads and parses the contents. If I add this function as a callable shell command, and run it from the prompt, it works every time.

I'd like the system to run the command automatically, so in the main loop I added;

Code: Select all

      if (!lwip_th_p && fs_ready) {
         if (read_opts((BaseSequentialStream *)&SDU1) == 0) {
            lwip_th_p = chThdCreateStatic(wa_lwip_thread, 
                  LWIP_THREAD_STACK_SIZE,
                  NORMALPRIO + 2, 
                  lwip_thread, &opts);
            start_server();
         }
      }

Here read_opts is my function that works when called from the shell prompt.

Called from the main loop, however, it hangs the processor reliably on f_open. Even calling it from the Blinker thread, it hangs the processor, though at least after opening the file, but before reading it.

Trying to run from the blinker thread, the processor isn't sitting in the ResetHandler(), it's caught in an OS loop doing;

87 do {
88 cp = cp->p_next;
89 } while (cp->p_prio >= tp->p_prio);

(gdb) p cp
$5 = (Thread *) 0x20000a80
(gdb) p *cp
$6 = {p_next = 0x20000a80, p_prev = 0x20000a80, p_prio = 0, p_ctx = {r13 = 0x0}, p_newer = 0x20000a28,
p_older = 0x2000bbf0, p_name = 0x20000968 "\200\n", p_state = 48 '0', p_flags = 191 '\277',
p_refs = 0 '\000', p_preempt = 32 ' ', p_time = 536985600, p_u = {rdymsg = 0, exitcode = 0,
wtobjp = 0x0, ewmask = 0}, p_waiting = {p_next = 0x8003581}, p_msgqueue = {p_next = 0x0,
p_prev = 0x2000bd28}, p_msg = 0, p_epending = 536873656, p_mtxlist = 0x20000ab8, p_realprio = 0,
p_mpool = 0x0}

Pointing to itself?

Regards,
James.

[JamesS]

Seems there was a stack overflow or similar. Running my function from the blinker thread works once I've increased the working area substantially. Currently;

Code: Select all

static WORKING_AREA(waThread1, 4096);

Could this be the same reason that my function fails to run from the main() loop?

Regards,
James.

[JamesS]

Nope it was a fluke. The function won't run reliably even from the blinker thread.

Regards,
James.

[Giovanni]

Hi,

If you experience list corruption then it is possible there is a stack overflow. Are you running with debug options in chconf.h enabled?

Giovanni

[JamesS]

Hi Giovanni,

I was reading about stack space and enabled CH_DBG_ENABLE_STACK_CHECK and CH_DBG_FILL_THREADS, and increased the blinker thread WA size to 1024 bytes, but haven't yet looked at the stacks to see how much room there is.

Regards,
James.