The pic18f4431 is not specified to work below 4.2V
If you are powering it from a 3.3V regulator any number of things may intermittently not work.

Ttelmah

Joined: 11 Mar 2010Posts: 12738

Posted: Fri Feb 23, 2018 8:56 am

SD draws a _lot_. Momentarily. The average consumption is not that high, but pulses can be up to 200mA. Most cards less (SanDisk for example specify their cards won't draw more than 100mA). The big problem is the rate of change of consumption. Regulators take time to catch up, and if the consumption changes in a few nSec from almost nothing to perhaps 70mA, this can lead to nasty spikes on the rail. Hence the need to have really good high speed decoupling close to the card.

We are 'harking on this', because the 'no file' error will happen if there is anything less than perfect in the I/O. Given the CCS drivers do work, and are know to work, with the problems you are seeing, it starts to 'smell' that you may well have a hardware issue.

salih260

Joined: 19 Feb 2018Posts: 22

Posted: Sat Feb 24, 2018 1:46 am

Ttelmah i am used a lot of library for sd card. I read and wrote sd kart sectors. But FAT did not work.
Now I will design a circuit with pic18f. I'll do it by checking step by step. Sleep is forbidden to me without programming the SD card.

* CCS C library, mmcsd.c has run all the functions. But fat.c, fat_init () worked but fatopen () did not work.
* Petit Chan library, diskio.c has worked on all functions. But pff.c, pf_mount () worked but pf_open did not work.

This shows that I have a hardware problem.

What are you thinking?

good work.

Last edited by salih260 on Sat Feb 24, 2018 1:57 am; edited 2 times in total

salih260

Joined: 19 Feb 2018Posts: 22

Posted: Sat Feb 24, 2018 1:47 am

gaugeguy wrote:

The pic18f4431 is not specified to work below 4.2V
If you are powering it from a 3.3V regulator any number of things may intermittently not work.

Thanks, I know.

Ttelmah

Joined: 11 Mar 2010Posts: 12738

Posted: Sat Feb 24, 2018 2:14 am

The point I'm repeatedly asking, is the say you have read and written sectors, but have you actually _verified_ the read is returning exactly the right data?. Every single bit/byte?. At several locations, and the right data for the location?. This needs to be the step of debugging _before_ you make any attempt to use a FAT library.
Use a hex editor. Dump sector 0, 2, and then a couple higher up the disk. Then read these with your code, and verify the data matches what this shows. Easiest way is to simply output the sectors in hex to serial and you can read this to the PC for comparison.

Debugging needs always to be 'take one step at a time'.

salih260

Joined: 19 Feb 2018Posts: 22

Posted: Sat Feb 24, 2018 2:47 am

Yeah. I did what you said. For example, in the 5th sector 0x21, 0x54, etc. I've written. Then I read them correctly. If I had not read the sectors and had not written it, pf_mount () would give an error.

What is the name of the hex program for sd card?

Ttelmah

Joined: 11 Mar 2010Posts: 12738

Posted: Sat Feb 24, 2018 3:05 am

Almost any standard hex editor. HxD or WinHex for example.

What are the first three bytes of sector 0?.

These distinguish whether the card has been formatted using a BFB or an MBR.

What does check_fs return?.

I'm thinking of problems, first with handling an MBR, but second with something silly like the raw driver not correctly handling addresses as they get larger. That's why I'd want to check a sector with a much higher address.

salih260

Joined: 19 Feb 2018Posts: 22

Posted: Sat Feb 24, 2018 3:24 am

Thanks for helping Ttelmah.

check_fs() --> return 0

there is all the data here. Sorry I could not assign a picture here. I gave you a link.

thank you very much Ttelmah and temtronic..
Does the SD card draw much current? If so, it means 100% hardware problem. Because SD card + Pic + etc. It is fed from 3v3 regulator.
(Regulator max. output current is 1A.)

I have read through the thread and have some comments

1. My drivers (Brush Electronics) come in two versions, one for the PCH compiler (PIC18 - 8 bit) and one for PCD (PIC24/dsPIC33 - 16 bit). The reason I have two different drivers is because when using 16 bit processors the data structures are WORD aligned as opposed to BYTE aligned. In theory, you could use the 16 bit driver with an 8 bit processor (I don't recommend it) however it would be wasteful of resources and performance on the 8 bit processor.

2. SD cards contain an embedded processor. A glitch on the card's power line can reset the card's processor. Power supply filtering and decoupling as close as practical to the SD card will prevent the high current transients required during write operations to the card being the cause of card related transients resetting the card. You need to use low ESR capacitors, I use 10uF and 0.1uF ceramic capacitors for new designs. Previously I used 22uF tantalum and 0.1uF ceramic capacitors for this role.

3. If you accidentally power the SD card from 5 volts or apply +5V to any of its pins, even momentarily, throw the card away. You are wasting you time working further with the card even when it appears to be still working ok.

4. Watch out for fake or low quality copy cards out of Asia. They may or may not work depending on the day of the week, whether there are clouds in the sky, if they are facing north etc.

5. During the development process ALWAYS format the card initially with a reliable SD formatter application. Do NOT rely on the windows format utility. Go to www.sdcard.org and download their free format utility.

6. The pull-up resistor on DO from the card (aka MISO) is very important. Lots of people make the mistake of "optimizing" the design by leaving it off and then you end up with the situation it works with some cards out of a batch and not others or it works on humid days but not dry days.

7. The cards should work well for SPI speeds of 10MHz and below without issue. For higher speeds, care must be taken with the layout of the tracks on the PCB as excessive capacitance can cause signal degradation._________________Regards, Andrew