Does anyone has succeeded in operate SDCARD and 18F family ?

[Mathy]

Hello,

I have a problem with the FAT component and the 18f family with flowcode 5.5.
All works very well ( init, create file, delete, open and append_string_to_file macro ). But the write_byte_to_buffer macro don't work.
My SDCARD isn't well recognized by Windows and the file is empty ( no character inside ).

I think I tried all I can but nothing to do.

I test with 2 different SDCARD with the same result.

I tried with the DsPIC family and it works !
So my program is good and my SDCARD too.

I need to know if it's a problem from flowcode for pic 8bit or from my board.

Thank you for your time.

[Benj]

Hello,

Hmm it seems there is a bug for 18F devices, however for v5.5 the C code is identical for 8-bit and 16-bit PICs so there must either be a bug in the PIC-8 compiler or I need to do more typecasting to ensure that everything is ok when working on 8-bit.

This did used to work so I'm surprised it's become broken again.

I will investigate this for you, hopefully not too hard to track it down.

[Mathy]

Hello Benj,

Do you remember under which version of Flowcode this function working ?
I think I have the very first one on CD ( 5.0 ) and the others on my hard drive 5.2, 5.4 and now 5.5.

I tried with hitech instead of boost C but it's does not compile with 18f26k22.

If you have any idea or if I can help you with some test...

Thank you.

[Benj]

Hello,

The program I am using "Data_Logger_Sector_Fast" works fine in v4 but causes disk corruption in v5.

I will continue to investigate.

[Benj]

Right I have got my fine tooth comb out and my logic analyser and have been comparing the SPI packets for the v4 and v5 transactions.

So far after several thousand SPI packets there are little differences but nothing that I can see is a show stopper!

Now I will investigate the actual data on the card to see if there is a clue there about what is causing the issue.

[Benj]

Hello,

Right I may be wrong but I think this might be the problem for the 18F devices.

Write file sector function...

if ((%a_mx_file_size[%a_mx_file_idx] >> 9) == (%a_mx_file_sector[%a_mx_file_idx] - 1)) //Is this the last sector of the file
%a_mx_file_size[%a_mx_file_idx] = (%a_mx_file_size[%a_mx_file_idx] + (512 - Read_File_Length()));

I have tried this but it doesn't seem to make any difference.

if ((%a_mx_file_size[%a_mx_file_idx] >> 9) == (%a_mx_file_sector[%a_mx_file_idx] - 1)) //Is this the last sector of the file
%a_mx_file_size[%a_mx_file_idx] = (unsigned long) (%a_mx_file_size[%a_mx_file_idx] + (512 - Read_File_Length()));

As I say the code must be right or it wouldn't be working on the 16-bit PICs so just looking for a little issue that might cause a problem on a 8-bit device eg manipulation of long 32-bit type vars.

I will continue to have a play around and see if I can fix this but it probably won't be today.

Looks like the only issue is the "file size" is being calculated incorrectly somewhere and this is causing issues for the Windows system being able to find the data. Using a program such as Winhex you can view the raw contents of the disk.

[Mathy]

Hi Benj,

Thank you for your time.

Indeed, I could compare the FAT16 component c code between the Dspic and the pic 8 bit and it is exactly the same.
And I can confirm again that it works very well on the dsPIC.

I really hope that you will succeed.
I don't know how I can help you.

[Mathy]

Benj,

My idea is probably stupid, but if you cut the calculation in several parts rather than a single line of code ?

It may be an error that came from me, but I remember doing calculations in Flowcode that did not work in only one line.
Separating each calculation and works perfect !

Maybe a BoostC issue ?

[Mathy]

Hi Benj,

Did you find something interesting?

Thank you,

Mathy

[Benj]

Hi Mathy,

Sorry it's been very hectic so far today and I haven't had any time to re-look into this issue.

I'm off work tomorrow so I will have a bit of a investigate at home. As you say simplifying the calculation by adding more lines may do the job.

I don't know how I can help you.

Using the customized code feature you should be able to try and break up the calculation yourself to see if this helps anything. Either way I will be in touch hopefully with a solution for you.

[Mathy]

Hi Benj,

Did you find something ?

Thank you,

Mathy

[Benj]

Hello,

Right I think I have managed to fix the bug.

Here is the code I used using custom code on the write file sector macro.

Code: Select all

	short Idx;

    unsigned long test;
    unsigned long test2;

	MX_Union32 Temp32;

    test = %a_mx_file_size[%a_mx_file_idx] >> 9;
    test2 = %a_mx_file_sector[%a_mx_file_idx] - 1;

	if (test == test2)	//Is this the last sector of the file
	{
	    test = 512 - Read_File_Length();
        %a_mx_file_size[%a_mx_file_idx] = %a_mx_file_size[%a_mx_file_idx] + test;
    }

	MX_Send_Buffer(%a_mx_file_pointer[%a_mx_file_idx]);								//Write string data in current sector to card
	MX_Get_Buffer(%a_mx_file_address[%a_mx_file_idx]);									//Read file address
......

The only real changes are the additional variables and the if statement. The code below the closing bracket of the if should already exist as is.

I will get this packaged up into better, more efficient code and release it as a component update.

Looks like the mod to allow concurrent files may have caused this bug to surface on 8-bit PICs.

[Mathy]

Hello Benj,

Thank you for your time,

I will test this on my hardware tonight and I will come back to you.

Thank you again and have a nice day.

[Mathy]

Hello Benj,

IT WORKS ! Great job.

I will mesure how long this macro take to write on the sdcard and compare to the append string to file macro.

Thank you for your time.

[Benj]

Great thanks for confirming the fix,

Let me know how you get on with your benchmarking.

[Enamul]

So Ben that's going to be in the Fix list...

[mb101]

Hi Ben,

I've been having the above issue on v5.5.2.1 fc (pic) and the above mod wasn't present, I tried it out and as suggested it works perfectly

Out of interest do you know what the turnaround for this going into the next release/patch will be?

Many thanks

Mark