4
\$\begingroup\$

I have implemented an SD/FAT combination on a Renesas RL78/G13 processor. The SD card is being driven using SPI.

The code has been proven to work on two custom target boards using a 2GB card - the SD can initialise properly via the FAT middleware and a file can be created on the card and written to. The result can be confirmed by plugging the card into a Windows machine and reading the file.

Suddenly, as if by magic, the SD card stopped working recently. Using a debugger, I tracked the problem down to the first time the FAT initialisation sequence tries to do a data read operation.

The sending of CMD17 (Read Single Block) and its response are handled correctly, but when the data packet is clocked-in (dummy 0xFF clocked-out on SO), the processor seems to reset (I get pre-main code being run, which I can confirm through my debug log).

I am wondering whether SD power is an issue. Due to other aspects of the board design, we're seeing ~2.9V for SD power and SPI comms. I can only ever see references to 3.3V for SD SPI, but does it really need to be exactly that? Could this be causing the issue, or is this a red herring and there's another reasoning?

Any help would be greatly appreciated.

\$\endgroup\$
6
  • \$\begingroup\$ Sure you don't have a watchdog running? 2.9V isn't a reliable input voltage; 3.3V is the spec. Try using 3.3V, see if it works fine then. \$\endgroup\$
    – user17592
    Commented May 16, 2013 at 13:26
  • 1
    \$\begingroup\$ If it's not a power issue, look for a bug causing your read operation to overwrite the stack or critical data structures, and thus result in runaway code execution? \$\endgroup\$
    – Chris Stratton
    Commented May 16, 2013 at 14:49
  • \$\begingroup\$ I have an 8192kB stack at the moment and I'm hardly using it when I drop into the transfer_data method, so I can't imagine that would be any issue. I tried setting a breakpoint in the interrupt after the command to transfer the data is called and I can't even get there - the processor resets before this point. \$\endgroup\$
    – Ed King
    Commented May 16, 2013 at 15:02
  • \$\begingroup\$ @ChrisStratton - I've traced down the reset to a RAM parity error, so nothing (it seems) to do with power. There is no dynamic memory in my application and I have a very large stack and heap compared to the requirements of the transaction and how deep the stack is at the point of performing the transfer, yet I cannot work out why this longer transaction is causing the issue, and only now. Do you have any ideas? \$\endgroup\$
    – Ed King
    Commented May 17, 2013 at 14:28
  • \$\begingroup\$ Memory parity error would seem to say either a power issue (sufficient decoupling caps? SD card suddnely drawing a lot?) or misconfigured timing (though I'd expect that more with DRAM-type technologies, and it sounds like you are more likely dealing with on chip SRAM). Can you trap the handler and get the address of the error? How repeatable is it? Do you have another board you can try? \$\endgroup\$
    – Chris Stratton
    Commented May 17, 2013 at 14:44

1 Answer 1

Reset to default
5
\$\begingroup\$

The SD memory specification version 1.01 states an operational voltage of 3.1 to 3.5V so you're outside that range. Also the specification allows up to 50mA to be drawn over a 400uS period and peaks can be higher, so unless you have a sufficently sized capacitor to act as a reservoir during those peaks you may have small dips on the power supply causing a processor reset.

It could also be a software issue causing a watchdog reset or other undefined condition if the SD card isn't responding as expected due to being operated outside the specified range. Either way it would certainly be worth getting to the bottom of your power supply issues.

\$\endgroup\$
3
  • \$\begingroup\$ I've made a mod to the board so that everything is 3.3V and we're still seeing the issue. There is no watchdog active, so it can't be that. If I provide this reservoir capacitor and this fixes the problem, why would everything have been working merrily beforehand, and at the lower voltage? \$\endgroup\$
    – Ed King
    Commented May 16, 2013 at 14:45
  • \$\begingroup\$ Also, I'm running at 4MHz during data transfer (maximum available for me), which if my maths is correct gives 1.0234ms for a 512 byte transfer. Could this be a contributor? \$\endgroup\$
    – Ed King
    Commented May 16, 2013 at 14:49
  • \$\begingroup\$ Version 3.01 of the Spec states 2.7 to 3.6 Volts as operating voltage range. \$\endgroup\$
    – Turbo J
    Commented May 16, 2013 at 19:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.