CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

PIC18F47J53 MicroSD issue (all blocks erased to 0xFF)

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Marco27293



Joined: 09 May 2020
Posts: 107

View user's profile Send private message

PIC18F47J53 MicroSD issue (all blocks erased to 0xFF)
PostPosted: Fri Nov 24, 2023 5:46 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9050
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Nov 24, 2023 5:54 am     Reply with quote

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



Joined: 09 May 2020
Posts: 107

View user's profile Send private message

PostPosted: Fri Nov 24, 2023 10:20 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19145

View user's profile Send private message

PostPosted: Fri Nov 24, 2023 11:28 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19145

View user's profile Send private message

PostPosted: Sat Nov 25, 2023 4:27 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9050
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Nov 25, 2023 6:17 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19145

View user's profile Send private message

PostPosted: Sun Nov 26, 2023 2:50 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9050
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sun Nov 26, 2023 6:14 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19145

View user's profile Send private message

PostPosted: Sun Nov 26, 2023 11:26 am     Reply with quote

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



Joined: 12 Aug 2004
Posts: 1628
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Sat Dec 02, 2023 6:51 pm     Reply with quote

Marco27293 wrote:
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


You are not describing a weird issue but rather a common implementation issue.

There are lots hardware and software of reasons why an SD card may appear fully erased, or why some blocks are erased and others appears to contain valid data. For example, if the initialization of the card is unsuccessful. Some low level software driver implementations, especially in the initialization phase, send commands to the card but don't actually check for a valid response, and assume the command was successful. When you have a poor hardware implementation then intermitted operation is a fact of life.

Hardware: The pullup resistor on the SDI line (SOMI) is the most important line to have the pullup the correct pullup resistor on. Without it the card may or may not initialize as the driver cannot correctly determine a card is present and it would not be able to put the card into SPI mode. A 51K pullup is too high, especially on the SDI line.

You can find hardware reference designs on my web site that I created years ago but are valid today.

Here is an guide to the HW implementation of the SD card on a 5V PIC (see page 3): https://brushelectronics.com/wp-content/uploads/2018/09/BE_Reference_Design_PIC18F4620_ENC28J60.pdf
For a 3.3V PIC you do not need the voltage dividers R23, R24, R30, R31

What is not obvious from the schematic is the need for a 10uF ceramic or tantalum capacitor as close to the power pins of the uSD card. SD cards draw a very low current during a read but draw a large instantaneous current during writes. Insufficient filtering and bypass capacitors close in the immediate vicinity of the card socket can cause a very short sharp voltage drop at the card which is sufficient to reset the card's own embedded processor. Naturally when this happens, the card is no longer in SPI mode. For my own products, I monitor errors from the card and if the card is unresponsive (as would be the case when the card is no longer in SPI mode) I reinitialize the card.

The SPI clock speed is another important consideration. According to the SD Card standard, cards should be initialized at 400KHz or lower and after initialize can be operated at "full speed". In my experience running the SPI clock at 10MHz and below on a PIC in normal operation is reliable however once you get above 10MHz you start hitting the wall due the the transmission line characteristics of the board's SPI bus layout.

Forget about controlling power to the card. An idle SD card draws negligible current. By powering on and off the card you are making the circuit more complex and therefor less reliable than it would otherwise be for no viable gain.

You are not using a filesystem, which is fine, but this means you are responsible to pointing to the correct blocks (page) in the SD card. You could easily be writing to one location but reading back from another. When you are dealing with PICs with limited amounts of program memory, then I can understand the tradeoff (been there done that) however for the last 15 plus years I have only ever used SD cards via a file system. The time to develop, debug and troubleshoot is significantly quicker and therefore the development cost is lower.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group