PIC18F47J53 MicroSD issue (all blocks erased to 0xFF)

[Marco27293]

Hi,

I'm using pic18f47j53 in order to collect data in an outdoor application and store them on microsd.

All worked fine in my field test 1 month long.

When I tried 150 devices for 4 month test, in 50% cases I got that microsd had been fully erased (all internal microsd bytes to 0xFF).

I used standard SPI interface with mmcsd library, I do not use filesystem but I use sd block (512 bytes) write/read.

- Microsd power-supply is controlled by the pic via 3.3V switch.
- DAT0 (MISO), DAT3 (CS) and MOSI al pulled-up to 3.3V by 51K resistors.
- SCK is not pulled up.
- DAT1 (NC) and DAT2 (NC) are connected to ground (GND).

Could you help to understand this weird issue ?

Regards,

Marco

[temtronic]

While I don't use that PIC or SD modules...
...my 'gut' is telling me that 51K is too high, aka 'weak' pullup
I'd think 10k would be better but...aka a 'hard' pullup

While 51K seems to work and may give better battery life, 10K should allow faster ,cleaner edges on the bits ?

I'm sure those that use SD modules will reply pretty soon...

Jay

[Marco27293]

OK,

Can absence of pull-ups on DAT1 and DAT2 create long term problems ?

I have a lot of microsd corrupted (all bytes 0xFF)... Why is it possible ?

[Ttelmah]

The pull ups should be 10K.
Dat1, and Da2 should also be pulled up.
They do have a function in SPI mode, They are optionally used as
IRQ's. Pulling them low could result in a problem, triggering the IRQ?.
It is somewhere in the SDIO specs. Not at my computer at present, but
sure they do say they should be pulled up not down.
Knowing the effect is very hard, since different makes of card may well
function differently.
Other critical thing is the supply smoothing at the chip, Rather worried
by your reference to using a supply switch. The pulse curents on
the SD card supply can be very high. They can draw a maximum of
200mA when doing certain cycles (actually more on some newer cards,
but only after asking the host). Having the supply droop during a write
can lead to data corruption.

[Ttelmah]

Just to confirm.
The SDIO specs do say that pull ups on all the DAT lines are mandatory.
The DAT1 line is the interrupt line. There is no reference to what pulling
this low might do. However DAT2, is also the read wait line if this is
programmed, which suspends data transfer from the card!...
So you need these lines pulled up, and also to look very carefully at the
supply. Wonder why you are bothering to switch this?. The card won't draw
any measurable power unless it is selected.

[temtronic]

hmmm...
Microsd power-supply is controlled by the pic via 3.3V switch.

As Mr T asks , why ?

Also 'switched' how ? If say a MOSFET does it allow 3.3 volts to the card or is there a small voltage drop ?
When you turn on the switch, do you wait the required 'power up / settling' time for the SD card to be 'ready'?
Have you a good cap on VDD of the SD card ? Say 100mfd ?
Are the VDD and GND traces to the SDcard wide or thin ?
Have you a 'bypass' cap there, say .1 or .01 mfd ?

Putting a scope on the SD VDD should be done to ensure power IS proper level,glitch free.

re: 'failures'
Are they all the same brand/type/batch of SD cards or a random mix ?

[Ttelmah]

Power drooping during a write operation, is documented as a known cause
of SD cards erasing their contents. I suspect his supply to the card does not
have enough capacitance immediately adjacent to the card to ensure a
reliable write. Even when directly connected to a fairly high power supply
the SD needs a good low ESR decoupling capacitor immediately adjacent
to the card, with reasonably thick connections (Jay was querying this).

Another thought occurs to me.
Assume he is writing to the card. Waits for the SPI transaction to complete,
and then turns off this supply connection. Result will be to corrupt the card.
Reason is the write will/may not have actually completed. The SD spec
allows the actual write to take up to 200mSec to complete after the data
is transferred. The supply must be maintained till this completes. In reality
most cards will complete in only a couple of mSec, but depending on the
card, a simple 'write', may involve moving blocks from one location to
another (if the card has some form of wear leveling), and take a lot
longer than a simple flash write cycle. You have to ensure the supply is
maintained for this specified time.

[temtronic]

hmm, he's doing an 'outdoor application'.. makes me now think he's using battery for power so turns off power to SD card to save energy ??? After all WHY control power if it's line/mains fed PSU ?
That may be a 'penny wise,pound foolish' move.
He has to allow for both 'power up' AND a 'power down' times. PD is 200ms, PU could be 50-100ms ? That's a lot of time for the PIC to be doing nothing. If you could have the card send a flag to say 'I'm finished', you could reduce the 200ms to say 2-5ms ?
I wouldn't think a SD card draws much power when idle.
Also if battery powered, temperature has a tremendous effect on battery capacity.Like us humans, batteries HATE the cold !
It'd be nice to know more this project,there may be 'tweaks' we could offer.

[Ttelmah]

That was exactly my point on 'why'.
An SD 'idle', is a low power device. You can apply 3.3v to it, and basically
it draws nothing. If however he turns off it's power before the write completes,
result disaster....
Leave the power on, and just put the PIC to sleep, and you have a low
power setup.
Better to have the power retained, and a good large reservoir capacitor
adjacent to the SD. This is how it is inside devices that draw low power.
You put the SD into it's idle state.

Some comments apply if you are removing power.
1) Means you will have to repeat the card initialisation. Includes switching
the bus back down to below 400KHz.
2) Means you will have to wait after power is applied. A lot of the newer
SD cards take longer to wake than the specs actually say (!!!). The worst
seem to be some of the SanDisk cards that can take 300mSec to be ready
to go after the supply reaches 2v.
3) You need to be making sure the card has gone back to the idle state
before removing the power.

[asmallri]