Fat16 won't initialise

[MJU]

I have got a MM multiprogrammer board with a 18F4550.
On PortA I have got the SD card reader board, PortB has a LCD and PortD has the LED board.

I put a program into the PIC to flash the LED's every second, just to test the timing settings for the PIC.
In the SD card reader I have put a SD card 2Gb, this is formatted with 32kb per sector.
I have downloaded the last version of the FAT16 component en changed the line

#define MX_FAT_TYPE 0//%l //0-FAT16(FAT) / 1-FAT32 / 2-FAT16&32
Into
#define MX_FAT_TYPE 1//%l //0-FAT16(FAT) / 1-FAT32 / 2-FAT16&32

But this flow never gets beyond the point where the card gets initialised.
On the SD card board I left the patch system on the same settings for the 16f887A, the port is selected in the connections on the FAT16 component, so it seems to me that using the same settings will work.
My guess is that the SPI will get bit banged on portA?

What is wrong with this one?
I send my very ugly Flow with this post so people can see it.
Is there a problem with the SD card?
Are there other problems?

Any help is welcome..

[Benj]

Hello MJU,

I notice in your program after the initialization has been completed that you are overwriting the ack value with 127 just before you are testing if the file was created and opened ok and this is causing the program to get stuck there. I have modified your program slightly and hopefully it will get past initialization for you now.

Let me know how you get on.

[Benj]

If the program is still hanging in the initialize stage then you can use this file to determine the cause of the failure based on the number that is printed back to the LCD.

[MJU]

Thank you BenJ.

I'm going to try these files and will be back with the results.

[MJU]

I had several replies.

Most were 252, 254, 255.
Sometimes, after a while the board went to "Fat init = OK".
After that it stopped.
Nothing on the card.

[Benj]

Here are the error return codes.

#define MX_ERR_NOCARD 0xFF
#define MX_ERR_NORESP 0xFE
#define MX_ERR_NOACK 0xFD
#define MX_ERR_TOUT 0xFC
#define MX_ERR_RESERVED 0xFB
#define MX_ERR_BAD 0xFA
#define MX_ERR_FREE 0xF0
#define MX_ERR_FILENOTFOUND 0xEF
#define MX_ERR_ROOTFULL 0xEE
#define MX_ERR_SECTBYTES 0xED

It looks like you are getting a no card, a no response and timeout error codes. Are you sure your connections are correct in Flowcode and on the hardware. Are you also sure that your card is supported. Eg it fully supports the SPI bus and has a sector size of 512 bytes. Do you have any other cards you can try with the hardware? Also did the card work when in FAT16 mode eg is it just FAT32 that is having the problems?

[Benj]

May be worth trying another port too. Eg the LCD seems to have problems working on port A on these devices even though the I/O should be ok. Something to do with what the ADC peripheral is using for its ADC source.

[MJU]

I've tried everything.

Checked the patch system for selection patch A.
Changed the patch system to B and changed the settings in the FAT16 component.
Changed the ports, had port B, C, D.

The card has a clustersize of 512mb (formatted with: "format h: /FS:FAT32 /A:512")

Sometimes it goes beyond FAT INIT = OK
Sometimes it tells me that the file is created.
I ones had that it added the text to the file, but after that the file wasn't accessible from the PC.

Strange thing is that when I put the card into the cardslot, the whole programmer is being reset.
The programming isn't that easy, I have to disconnect all boards before I can erase the PIC with PPP.
I always had problems with the XTAL/RC switch on the programmer board since I bought it.
Could this be a problem? Most of the time it works, but this is a problem with the design and the choice of the switch?

I don't know what to test next.
I have another card underway, but that could take days.

Any more suggestions??

[Benj]

Hello,

Hm sounds like there is something that is not quite working correctly.

Strange thing is that when I put the card into the cardslot, the whole programmer is being reset.

This is normal operation for the board.

I always had problems with the XTAL/RC switch on the programmer board since I bought it.
Could this be a problem? Most of the time it works, but this is a problem with the design and the choice of the switch?

If the program is running at all then the switch position is ok. We do use a fairly low cost switch on the EB006 but they are quite reliable and there are few comments or complaints about them related to the amount of EB006 programmers we sell. At the end of the day they are low cost to help save you money on the sale price.

I would assume that thuis is a card problem. One thing you could try is to adjust the timings of the SPI transactions just incase they are slightly out of tolerance for your card. Using the custom code feature edit the SPI_BYTE function.

Maybe try editing the code so that the following delays are added.

Code: Select all

	#if (MX_HW_SPI == 0)								//Software Mode

		char idx;
		for (idx = 0; idx < 8; idx++)
		{
			if (test_bit(shift, 7))
				set_bit(MX_CARD_PORT, MX_CARD_SDO);		// Set SDO bit
			else
				clear_bit(MX_CARD_PORT, MX_CARD_SDO);	// Clear SDO bit

			shift = shift << 1;

			set_bit(MX_CARD_PORT, MX_CARD_SCK);			// SCK Output 1

			delay_us(10);	//Added Delay ************************************

			if(test_bit(MX_CARD_PORT, MX_CARD_SDI))
				shift = shift | 0x01;
			else
				shift = shift & 0xFE;

 			delay_us(10);	//Added Delay ************************************

			clear_bit(MX_CARD_PORT, MX_CARD_SCK);		// SCK Output 0

			delay_us(10);	//Added Delay ************************************

		}
		return shift;

	#endif
	#if (MX_HW_SPI == 1)								//Hardware Mode

		#ifndef MX_SPI
			#ifdef _BOOSTC
				#pragma error "Chip does not have SPI capability"
			#endif
			#ifdef HI_TECH_C
				#error Chip does not have SPI capability
			#endif
		#endif

		sspbuf = shift;									//write the Char
		while ((sspstat & 0x01) == 0);					//wait until sspbuf is empty
		shift = sspbuf;									//receive the Char
		return shift;

	#endif

If this works more reliably then you can start to reduce the delays until you have an optimal setup for your card.

Hopefully when you receive your new card it will work with the code as is.

Let me know how you get on.

[MJU]

Hello,

Hm sounds like there is something that is not quite working correctly.

Strange thing is that when I put the card into the cardslot, the whole programmer is being reset.

This is normal operation for the board.

I always had problems with the XTAL/RC switch on the programmer board since I bought it.
Could this be a problem? Most of the time it works, but this is a problem with the design and the choice of the switch?

If the program is running at all then the switch position is ok. We do use a fairly low cost switch on the EB006 but they are quite reliable and there are few comments or complaints about them related to the amount of EB006 programmers we sell. At the end of the day they are low cost to help save you money on the sale price.

I would assume that thuis is a card problem. One thing you could try is to adjust the timings of the SPI transactions just incase they are slightly out of tolerance for your card. Using the custom code feature edit the SPI_BYTE function.

Maybe try editing the code so that the following delays are added.

Code: Select all

	#if (MX_HW_SPI == 0)								//Software Mode

		char idx;
		for (idx = 0; idx < 8; idx++)
		{
			if (test_bit(shift, 7))
				set_bit(MX_CARD_PORT, MX_CARD_SDO);		// Set SDO bit
			else
				clear_bit(MX_CARD_PORT, MX_CARD_SDO);	// Clear SDO bit

			shift = shift << 1;

			set_bit(MX_CARD_PORT, MX_CARD_SCK);			// SCK Output 1

			delay_us(10);	//Added Delay ************************************

			if(test_bit(MX_CARD_PORT, MX_CARD_SDI))
				shift = shift | 0x01;
			else
				shift = shift & 0xFE;

 			delay_us(10);	//Added Delay ************************************

			clear_bit(MX_CARD_PORT, MX_CARD_SCK);		// SCK Output 0

			delay_us(10);	//Added Delay ************************************

		}
		return shift;

	#endif
	#if (MX_HW_SPI == 1)								//Hardware Mode

		#ifndef MX_SPI
			#ifdef _BOOSTC
				#pragma error "Chip does not have SPI capability"
			#endif
			#ifdef HI_TECH_C
				#error Chip does not have SPI capability
			#endif
		#endif

		sspbuf = shift;									//write the Char
		while ((sspstat & 0x01) == 0);					//wait until sspbuf is empty
		shift = sspbuf;									//receive the Char
		return shift;

	#endif

If this works more reliably then you can start to reduce the delays until you have an optimal setup for your card.

Hopefully when you receive your new card it will work with the code as is.

Let me know how you get on.

Thanks again BenJ

I've changed the PIC_FAT16.c and flashed the same program into the 18F4550 again.
It doesn't change a thing.
But the strangest thing about this whole program is that when it's executed it gets very slow.

I setup the program to flash the LED's a few times to check whether the timing is correct (something people at MM told me to do), after that the FAT_init is executed and checked.
If this is successful a file (start.txt) is created and again checked if this was successful.
Then a short loop is created to generate a string and this is appended to the start.txt.

BUT...
Between the flashing of the LED's there is (sometimes) a pause of 10 seconds before the status is shown (FAT INIT OK, or NOK). 10 seconds???
If the message is that file init was ok, then a new period of several seconds follows.
Sometimes it takes half a minute before the "file created" message is shown.

Where does all this time come from?
How can the program needs 10 seconds time to check if the INIT was ok or not ok?
Is this, again, a timing setting on the 18F4550?

I hope my new card arrives soon.

[Benj]

Hello,

Adding additional delays will cause an exponential rise in the amount of time it takes to initialise the card or to create files etc. The original delay was only added because I had one card which was not behaiving quite like all the other cards I was testing. Adding the delay brought it in line with all the others. Just thought maybe it was worth trying adding more incase the card had a slower then average interface requirement.

Hopefully the new card will work fine. I know that there are teachers out there who are using the up to date version of the FAT component to teach FAT and file system technology and I know there are also a lot of users using the FAT component so my only guess at the moment is that there is something odd about the card you are using.

Let me know how you get on with your new card when it arrives.