v5 Beta FAT16 component SDHC

[Benj]

Hello,

Internet back online hurray

Right I have repeated the tests using the current code I posted and the updated ARM CAL file. Out of my 6 cards that work with the PIC I have 4 that work straight off and this includes the two SDHC type cards

Interestingly the 2GB SDHC card worked before I updated the FAT component so it looks like it is not a true SDHC i.e. with the sector address running 0,1,2... instead of 0,512,1024... on the standard cards.

Now onto the two cards that are not working, they both initialise but on one the file is found but the contents is missing and the other the file is not found. Checking the signals with my USBee E-block I can see that some times the cards do not seem ready when they say they are, they give valid data but the data signal uC -> card is really noisy which means that the card has the possibility of receiving incorrect data. I got the same thing on the PIC but I think it was slightly more reliable as there was generally more processing time and slower SPI rates.

StrangeNoiseOnMosiPin.jpg (167.63 KiB) Viewed 13793 times

On the left hand side is the first command to the card the data here should be 0x40, 0x00, 0x00, 0x00, 0x00, 0x95 so you can see the USBee picking up the corruption. On the right is the second command which is suddenly much cleaner. The noise seems to happen more on certain commands then others which is odd, its generally always the first command that causes it but then some commands near the end of the init function also exhibit the same problem. The problem is also very card dependent, I wonder if I have some cheap branded replicas in my collection as I know the over priced shop bought cards I have seem to be ok. I know this is a big issue when trying to get the Sony Magic Gate compatible type cards. If anyone has any suggestions here then I am all ears

To make matters worse on one card I have another issue where if I don't wait long enough after the init then the card returns invalid MBR data. This means that by the time the data is ready the MBR address is incorrect and the init will fail. The card says it is ready so not really sure what to do here, maybe a permanent long delay here will fix everything (thats what I have done so far to get all 6 cards working for PIC).

Looking into the file write process now to see if this has similar problems i.e. if it works straight off on my 4 out of 6 cards then we can assume it is linked to the same issue.

Why is nothing never easy

[Benj]

There does seem to be a problem with the write functionality, I will investigate.

[Nico595]

Why is nothing never easy

Thank Ben for this informations

Indeed, init_Fat with SDHC Card is ok, but reading speed is very low. You have found reason of problem, it remains to find the solution.
Thus, Create_File macro have even problem ...

May be, link with IO SDHC Card Specification

https://www.google.fr/url?sa=t&rct=j&q= ... KZt2csgrcw

http://www.google.fr/url?sa=t&rct=j&q=& ... PB8s25sK1Q

I feel you will find

I will investigate

Courage.

[Nico595]

Hi Ben,

I've not Logic Analyser, I don't see my signal.
I've tried with pull up resistor on MOSI, MISO and CS pin.
But the problem with create_file macro and speed of SPI is the even.

[DavidA]

Hello,

Just an FYI for you Ben is away on holiday for 2weeks.

[Nico595]

Ok, thank you David

[Nico595]

Hi,

For your back Ben

I've tested my signal with LLC probe. I have even problem but may be less marked.

It's Init_Fat sequence:

First pulse group test SCK = 727KHz
Second pulse group test SCK = 585KHz
3rd pulse groupe test SCK = 311KHz

On transmit data sequence DI => SCK = 12MHz signal is perfect and without bad pulse on MISO or MOSI. SCK is perfect with duty cycle = 50 %
On receive data sequence DO => SCK = 311KHz signal is strange with pulse on MOSI. SCK is bad, small pulse with duty cycle = 90 %







We see a bad "bit" on MOSI (Data Out) with strange pulse and this pulse is between two level of clock, exactly in the middle.
(MOSI is inverted with MISO on my print screen)

After zoom on MOSI signal, pulse is data in 12MHz but SCK is not in 12MHz but 311KHz
Even problem with read_buffer sequence, data is in 12MHz with SCK at 311KHz

You can download file Init_Fat and Read_Buffer and see with more detail. You must installed LLC Software and copied this file in Setting directory.

http://prefaceweb.com/Matrix_Benj/init_ ... .logicdata
http://prefaceweb.com/Matrix_Benj/read_ ... .logicdata

Thank for your reply.
Nicolas.

[Nico595]

Hi,

What news Ben ?

[Benj]

Hi Nicolas,

Sorry for the delay, I had a well overdue holiday and then got a bit distracted with the prop clock project. Many apologies.

RIght i'm back on with this now trying to solve the write issues. Thanks for the links, I might have to give them a good read if I can't get it working with my usual blunt force approach

In the wave forms above are you using hardware or software SPI. Just wondering because the data baud for hardware SPI should be fixed and shouldn't alter after the initial slow initialise period. Saying that the new software SPI layer should also be a fixed rate. Seems strange are you using the latest component as posted here or an older version?

I beleive I have made some progress on reliability but I will carry on with testing and let you know.

[Benj]

This seems a lot more stable now and is working well on my ECIO test platform.

[Benj]

We have just tested the updated firmware with the MIAC addons and it is working well here too

Looks like we may have about cracked it.

[Benj]

Posted a further update modification of the SD FAT component here with additional code to handle more then one file at a time. Seems to work well

http://www.matrixmultimedia.com/mmforum ... 260#p39260

[Nico595]

Hi Ben,

Thank you very much for your research.

I test this code today ;p

[Nico595]

I have Gcc Error 1 but it s my Personnal Macro in FAT16

Code: Select all

FCV_FILE_LENGTH = %a_mx_file_size / 512;    // file lenght in sector

Gcc Error ->

Code: Select all

test.c: In function 'FCD_FAT160_File_Length':
test.c:3186: error: invalid operands to binary /

It's my operands / but what is the good operand for divided by ...

Thank you Ben for your answer.

[Benj]

Hello,

I think it should now look like this.

Code: Select all

FCV_FILE_LENGTH = %a_mx_file_size[%a_mx_file_idx] / 512;    // file length in sector

[Nico595]

Thank you Ben, Macro is OK with this code.

But with new FAT16 code I must add this code in Init_Fat for a good init, if no I have 254 return

Code: Select all

retval = MX_Init_Card(); //Startup Card

 if (retval)
 {
 %a_SPI_Set_Prescaler(1); //Try again

 retval = MX_Init_Card(); //Read Master Boot Record if available

 if (retval)
 {
 %a_SPI_Set_Prescaler(2); //Try again at a lower speed

 retval = MX_Init_Card(); //Read Master Boot Record if available

 if (retval)
 {
 %a_SPI_Set_Prescaler(4); //Try again at a lower speed

 retval = MX_Init_Card(); //Read Master Boot Record if available

 if (retval)
 {
 %a_SPI_Set_Prescaler(64); //Try again at a lower speed

 retval = MX_Init_Card(); //Read Master Boot Record if available

 if (retval)
 return(retval); //Startup error or no card
 }
 } 
 }
 }


 delay_ms(50);

 retval = MX_Get_Buffer(0); //Read Master Boot Record if available

 if (retval)
 {
 %a_SPI_Set_Prescaler(1); //Try again

 retval = MX_Get_Buffer(0); //Read Master Boot Record if available

 if (retval)
 {
 %a_SPI_Set_Prescaler(2); //Try again at a lower speed

 retval = MX_Get_Buffer(0); //Read Master Boot Record if available

 if (retval)
 {
 %a_SPI_Set_Prescaler(4); //Try again at a lower speed

 retval = MX_Get_Buffer(0); //Read Master Boot Record if available

 if (retval)
 {
 %a_SPI_Set_Prescaler(64); //Try again at a lower speed

 retval = MX_Get_Buffer(0); //Read Master Boot Record if available 

 if (retval)
 return MX_ERR_SECTBYTES;
 }
 }
 }
 }

Init is OK, but when I want read file, ARM CPU init and reset
Even problem with no SDHC Card
Strange ...

[Nico595]

I ve tested Create_File on SDHC Card, It's OK

But "Filename" variable is no read for display on LCD

-> Problem with read file, so is not Open_File, why CPU reset ?

[Benj]

Hello Nico,

Please can you put together a simple as possible program that demonstrates the resetting error and post it up here, I will then have a play here and see if I can fix the problem.

I was having resetting issues at one point which was related to a large calculation which must have been overflowing or dividing by 0. I did manage to sort this out though so it's strange.

[Nico595]

Thank you Ben

I doing that this night

[Nico595]

Hi Ben

I've sent file by mp

Init_prog, scan_Folder, scan_File and Open_File are OK.

There is a Reset after prog_stream_dac boot

[Nico595]

Hi Ben,

Excuse me, after more investigation, problem is in open_file prog macro. I ve debuged with a clear lcd and delay.

I think is even problem with my LCD in write_file prog, (filename) variable disappears.

Idea ?

I check immediately with name of file fixed in Open_File component macro.



EDIT: Yes !!!
Problem is (filename) variable, strange, Open_File macro component delete this variable may be.

[Nico595]

Hi Ben,

Ok, it s a problem with variable length in Open_File component macro. If the variable length is [20] there is a reset cpu.
I ve tried with a variable filename[15] even problem, with filename[10] it's ok.

[Benj]

Hi Nico,

Are there any specific compiler warnings generated when you have the filename variable over 10 characters? Really the filename should only be allowed to be a maximum of 12 characters anyway as it is based on the old 8.3 DOS file system for simplicity.

What about if you pass fixed strings to the functions rather then variables?

eg instead of filname pass "test.txt"

The reset sounds like something is going outside the bounds of normal memory and causing a pointer overflow. This maybe due to lack of space for all the concurrent variables or could be due to something else.

[Nico595]

Thank Ben,

Ok for DOS file system

I've changed my filename variabe in filename[12] it's ok.

I can checked SDHC FAT Component with write and read

[Benj]

Updated component available from here: http://www.matrixmultimedia.com/mmforum ... 651#p39651