# SD Comms Resetting Processor

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.

-
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. –  Camil Staps May 16 '13 at 13:26
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? –  Chris Stratton May 16 '13 at 14:49
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. –  Ed King May 16 '13 at 15:02
@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? –  Ed King May 17 '13 at 14:28
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? –  Chris Stratton May 17 '13 at 14:44
show 1 more comment

## 1 Answer

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.

-
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? –  Ed King May 16 '13 at 14:45
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? –  Ed King May 16 '13 at 14:49
Version 3.01 of the Spec states 2.7 to 3.6 Volts as operating voltage range. –  Turbo J May 16 '13 at 19:31
add comment