SD Card Fat16/Fat32

[Nickma]

Hello Wimax. Thanks for the answer. I will try this option

[Wimax]

Hello 

I wonder if there is a way to transmit via serial port the list of files stored on the sd not only with name and extension, but also with date and time of creation of the files ?

[Wimax]

Hello Wimax. Thanks for the answer. I will try this option

Hello, recently I discovered a problem that made it impossible to save the date correctly, whereas the time had no problem.
I think I found the bug within the FileSys24 library in procedure "FAT_SetFileTimeModified" where I used the auxiliary variable "PPA" to provide data to "FAT_InsertByteIntoBuffer":

Code Select Expand


Proc FAT_SetFileTimeModified(pSectorPos As Word)
 '************* ADDED*******************
 '**************************************
    Dim PPA As Byte


    FAT_InsertByteIntoBuffer(pSectorPos, (Global_bSeconds / 2) | (Global_bMinutes << 5))    ' Create time & date - Seconds/Minutes
    Inc pSectorPos
    FAT_InsertByteIntoBuffer(pSectorPos, (Global_bMinutes >> 3) | (Global_bHours << 3))     ' Create time & date - Minutes/Hours
    Inc pSectorPos
    PPA = Global_bDay | (Global_bMonth << 5)
    FAT_InsertByteIntoBuffer(pSectorPos, PPA )                                              ' Create time & date - Day/Month
   'FAT_InsertByteIntoBuffer(pSectorPos, Global_bDay | (Global_bMonth << 5))                ' Create time & date - Day/Month
    Inc pSectorPos
    PPA =(Global_bMonth >> 3) | ((Global_bYear + 20) << 1)
    FAT_InsertByteIntoBuffer(pSectorPos, PPA ) ' Create time & date - Month/Year
   'FAT_InsertByteIntoBuffer(pSectorPos, (Global_bMonth >> 3) | ((Global_bYear + 20) << 1)) ' Create time & date - Month/Year
EndProc


EndProc
Now it seems ok !

[Nickma]

Hello Wimax. Thanks

[Wimax]

Hello!

I have not yet been able to solve a problem that prevents me from displaying the list of files and directories on the uSD using a pic24hj128gp204 (44 pin TQFP), basically the same file is always displayed in an infinite loop. By the way, the only file displayed is the last one that appears if you connect the uSD to the PC. Reading, writing etc. of the files on uSD work, I tested the code on a pic24hj128gp202 (28 pin DIL) on evaluation board with an SD with no problems just before in order to minimize risks . I'm using HW SPI1 without DMA... I am going crazy, has anyone had similar problems ?

[trastikata]

Hi,

hope this helps:

Code Select Expand

Dim sFileName As String * 11
Dim bCounter1 As Byte
Dim bCounter2 As Byte


Main:
    Clear
    SetCrystal()
    SetPins()
   
    TftSetUp(0)
    TftResetScreen(BLACK)
    TftSetSndFont(0,0)
   
    For bCounter1 = 0 To 255
        If File_Init() = cErrOK Then
            Break
        EndIf
        DelayMS 1
    Next

    bCounter1 = 25 : bCounter2 = 1
   
    Disk_swFileSearchNumber = 1
    While FAT_FindRootDirEntry(sFileName, 2, FAT_cDirectory ) = True
        TftPrintSndString("." + sFileName,1, bCounter2,bCounter1,1, GREEN,BLACK,1)
        Inc Disk_swFileSearchNumber
        Dec bCounter1
    Wend
 
    Disk_swFileSearchNumber = 1
    While FAT_FindRootDirEntry(sFileName, 2, FAT_cFile) = True
        TftPrintSndString(".." + TrimString(sFileName),1, bCounter2,bCounter1,1, GREEN,BLACK,1)
        Inc Disk_swFileSearchNumber
        Dec bCounter1
        If bCounter1 = 0 Then
            bCounter1 = 25
            bCounter2 = 20
        EndIf
    Wend
End

Proc TrimString(sInString As String * 11), String * 11
    Dim bCounter1 As Byte
    Dim bCounter2 As Byte

    Clear Result
    sInString[7] = "."
    bCounter2 = 0
   
    For bCounter1 = 0 To 10
        If sInString[bCounter1] <> 32 Then
            Result[bCounter2] = sInString[bCounter1]
            Inc bCounter2
        EndIf
    Next
EndProc


[Wimax]

Hi Trastikata ! 

I will try your suggestion, thank you very much !

I am still thinking about what I experimented with yesterday because I used code that I have extensively tested on Pic24fj64 and also tried on 28-pin pic24hj128 in preparation for migrating to the 44-pin version.
Actually for the first time since using Positron16 I also experienced an editor crash with a memory violation error...I didn't miss a thing!

[trastikata]

I'm using HW SPI1 without DMA... I am going crazy, has anyone had similar problems ?

Hello Wimax,

try with the new Positron update.

I've just noticed you are using HW SPI. The original FileSys24.inc doesn't support HW SPI, so you have to take care of the slow initial communication. Another thing - what is the SPI clock speed you are using?

[Wimax]

Hello Trastikata,

I'm using the modified release of FileSys24 library where you can set one of the two variables SPI_Software or SPI_Hardware to use a bitbanged SPI or the hardware SPI. I use the hardware module just for speed reasons and I never had problems before with a 32 MHz PIC24FJ64GP202 with the SPI bus @ 8 MHz and also with a 28 pin PIC24HJ128 clocked @ 79.23 MHz and the SPI @ 9.9 MHz.
I experienced strange behavior of the dir procedure using the PIC24HJ128GP204 (44 pin TQFP) clocked @ 80 MHz and SPI @ 10 MHz, but what is "strange" is that I can correctly initialize the uSD, I can read files and write files, but using the script coming with the FilesSys24 library for displaying the files list (that I have always successfully used before) I only see the same file in an infinite loop (I don't know why, but the procedure always see the same file without finding the end of the directory).
I even thought about silicon hardware problem, I found an "errata" from Microchip that might be about the SPI module, but if I apply the proposed solution nothing works anymore !

I do not have access to the PC on which I work and have not yet had a chance to try your code and install the positron update, but I will as soon as I can.
In fact it could also be a compiler problem, I don't remember which version I used with the previous MCUs, certainly not counting the last one available I used one of the previous two.

[normnet]

Hello Trastikata,

...I use the hardware module just for speed reasons...

If I'm not mistaken bit banging is faster than the hardware module with the 16 bit PICs.

[trastikata]

If I'm not mistaken bit banging is faster than the hardware module with the 16 bit PICs.

Hello normnet, let's see the math.

With HW SPI- load value to SPI register - 2 clocks, clock out data, read SPI register - 2 clocks. Thus overhead is 4 clocks.

With SW SPI - you have to get every bit from the variable and set the SDO pin to that bit which is a lot of overhead cycles. Even clocking out the data is 2x the cycles because for each Low-High (or inverse) cycle you need to use SetPin and ClearPin commands, which are 4 cycles in total instead of 2 for the HW.

SPI modules on 16b devices can run maximum at 1/2 Fosc which is still faster than SW SPI if we count the overhead.

One thing with 16b modules - the datasheet says don't run the SPI module more than 1/2 Fosc, but I ran it with 1:1 prescaller at 140 Mhz and rise and fall times looked OK on a scope.
   

[Wimax]

Yes, some time ago I had to sustain a continuous transfer of blocks of 16 bytes to an external SPI RAM within 60 us (something less considering other additional operations to perform in between). Playing with a 32 MHz pic24 ( Tcy of 62.5 ns) it was impossible with a software SPI, but the HW module performed perfectly.

[Wimax]

One thing with 16b modules - the datasheet says don't run the SPI module more than 1/2 Fosc, but I ran it with 1:1 prescaller at 140 Mhz and rise and fall times looked OK on a scope.
 

I have to say that with the pic24fj @ 32 MHz I set the SPI @ 8 MHz that's equal to FCY/2 and to the higher allowed clock frequency for the full-duplex HW SPI. Now, using the 80 MHz Pic24hj I'm using a 10 MHz SPI clock that's lower than FCY/2 (20 MHz), but higher than 9 MHz that's the maximum allowable clock freq., according to the data-sheet.
Anyway... I tried a 5 MHz clock also and the "dir" problem was always there.

[trastikata]

I assume this is with the new update? What SPI settings do you use? CKE: SPIx Clock Edge Select bit and SMP: SPIx Data Input Sample Phase bit

Depending where you read the bit and capacitance, slower or faster PICs can read it differently.

I've had  mistakenly chosen the wrong place to read the bit and despite that everything worked, when I switched the MCU things stopped working.

Try changing the SMP: SPIx Data Input Sample Phase bit

[Wimax]

Unfortunately I cannot check the settings at the moment, but as soon as I can I will install the latest positron 16 update and try again both the old code and the one you suggested and check the SPI settings.
A shiver of dread went through me thinking how many surprises I might have by perhaps migrating to the dspic33ep or Ck series

[normnet]

If I'm not mistaken bit banging is faster than the hardware module with the 16 bit PICs.

Hello normnet, let's see the math.

I remember Les posting however no luck with search's of the forum.

[top204]

Many years ago, with the, then, new 18FxxK devices, the SPI peripheral failed with higher interface clock speeds, so software SPI created with optimisation was actually faster than the peripheral.

However, on PIC24 and dsPIC33 devices, and the newer 18FxxK and 18FxxQ devices, the SPI clock can be set for tremendous speeds, and I have not seen it lose clock cycles, as the early 18FxxK devices used to do. So if the SPI device that is being talked too can handle the high speeds, it will be faster and more efficient, but not always transferable to other devices.

[Wimax]

Hi Trastikata,

I updated the compiler and changed the procedure I was using to display the SD directory, searching exactly for the files with the desired extensions, and now it seems to work with both the old SMPI setting 'Input data sampled At End of data Output time' and the new 'Input data sampled At middle of data Output time' with an SPI clock of 10 MHz.

I tried a test program using the code you suggested me with the necessary adaptations and it seems to go ! I'm still wondering why an ultra-verified code used on MCUs similar to the one I used this time gave me nothing short of crazy results.

[trastikata]

I'm still wondering why an ultra-verified code used on MCUs similar to the one I used this time gave me nothing short of crazy results.

Hi Wimax,

I cannot say anything without seeing and testing the actual code and hardware. It might even not be software related issue.

My understanding is that this is a new hardware, sometimes new hardware brings unexpected challenges as wave forms, rise/fall times, peripheral module (pin) delays, triggers ...   

While developing the TFT library I've noticed for example that the 16b 140 MHz PIC produces much cleaner wave forms and had no problem with SPI transfers to and from SD cards, although SPI was running at 70MHz. Whereas the 64 MHz 8b PIC struggles at much lower SPI speeds of 12MHz and I had to introduce certain delays or reduce speed at some places.

Also during initialization SD cards are a bit tricky and don't like and tolerate any irregularities that may arise from faulty wave form. That's why in my code I initialize the SD card using slowed down bit-banging and then switch to full speed HW SPI if desired.

Take a look in my latest TFT library update and go through the receive, send and initialize procs/subs, there are few thing you might find useful to adjust in the original FileSys24.inc for better stability if you intend using HW SPI.

Those issues arose only after extensive testing - for example:
- depending where you read a bit during reception you'd need to assure that SCL line is in the proper state before enabling CS because the bit might be shifted in not where you'd expected it.
- also assure proper state for the SDO line during reception.
- depending on transmission lines design and capacitance it is possible that the clock line is quite faster than the data line which would cause havoc if not treated properly.
- if multiple SPI devices share the same line you might need to initialize them in a specific order otherwise their respective inputs/outputs might be in indeterminate state and load the data/clock line.   
... and so on.

SPI, as simple as it looks like, requires very careful planning and line management, otherwise unexpected result occur.

P.s. Sorry for the vague description, but can't really say much else without having the actual hardware.

[Wimax]

Hi Trastikata,

Certainly you are right, there are many aspects to consider, but what "amazed" me was to find that I had no problems initializing the uSD, nor with file transfer, it always happened correctly as well as creating and deleting files on uSD.
The sore point was the display of the list of files in the uSD root directory (the only directory present) which resulted in the display of a single file endlessly, as if the end of the list was never detected (by the way, it was the last file in the list itself).
This makes me think more of a software problem than a hardware problem, but I definitely need to investigate further.

This is the procedure used before the last changes for directory listing (taken from SD_File_System.bas) which seems not to be working properly with the new MCU:

Code Select Expand

'----------------------------------------------------------------------------------------------------------------------------------------
' Transmit the disk directory to a serial terminal
'
Proc DirListing()

    Dim DirName   As String * 12
    Dim FileName  As String * 12
   
       
    While
        DirName = File_GetDir()                                            ' Look for directories
        If DirName_0 = 0 Then                                              ' Are there any more directories?
            While                                                          ' No. So...
                FileName = File_GetFile()                                  ' Look for files
                If FileName_0 = 0 Then Return                              ' Exit when no more files
                MyFileName = Left$(FileName,8) + "." + Right$(FileName,3)
                HRSOutLn MyFileName, " : ", Dec File_dSize, " bytes"                                            ' Transmit the file name and its size
     Wend
        EndIf
        HRSOutLn DirName, " <DIR>"                                          ' Transmit the Directory name
    Wend

EndProc


The "while-wend" cycle never ends... .
—————
I add another piece to the mosaic: I prudently set the SPI clock to 8 MHz, on the oscilloscope the waveform appears rather clean along the chain. With a lot of patience I also implemented the work-arounds recommended by Microchip for the silicon errata known for the SPI for the revision I have of the MCU. I write correctly on the SD, read, check the existence of files, delete, create, open and close them, but I don't understand why the "File_GetFile()" procedure doesn't work correctly.
—————
P.S.: In your applications how do you add the creation date and time to the list of displayed files ?