FAT32 Conflict with SPI1?

[boardman]

Hiya! Returning to the embedded world, and what a cool world it has become. Definable pins! Awesome! I'm doing a mikroC program for PIC24EP128GP202 that has a mp3 chip and a microsd both on SPI1.

When I traverse the root directory like this:

Code: Select all

     while ( 1 )                                                                // Main loop: forever
     {
restart:
        while(Mmc_Card_Detect)                                       // Loop until card is detected, pin reversed
             ;

        if (FAT32_init() != 0)                                      // Now using FAT32 library to init the card
        {
           show_error_lights(LIGHTS_CODE_FAT_NOT_INIT);
           goto restart;
        }

        first_flag = 1;
        for ( file_count = 0; file_count < MAX_FILES_FROM_DIR;  )    // For every directory entry
        {
          if ( first_flag == 1 )
          {
                first_flag = 0;
                ret_code = FAT32_FindFirst(&dirent);
                if ( ret_code != FOUND )                        // We only want to run this once per directory scan
                {
                  count_out_FAT_error_integer(ret_code);
                  goto restart;
                }

                }
sprintf(debug_buf, "a file %d r equals %d a equals %d", file_count, ret_code, dirent.Attrib);
debug_say(debug_buf);
          }
          else
          {
dirent.Attrib = 66;
dirent.NameExt[0] = 0;
              ret_code = FAT32_FindNext(&dirent);

              if ( ret_code != FOUND )
                 break;                                                           //  This means "end of dir, rewind

sprintf(debug_buf, "a file %d r equals %d a equals %d", file_count, ret_code, dirent.Attrib);
debug_say(debug_buf);
          }
                 // Store audio file names in MAX_... sized array here
      }         
 
    // Other code to loop through and play audio based on file names here
    // Rest of program here etc.

Conditions: I have almost the whole program #ifdef'd out. I am trying to just figure out this directory problem. I have both a lights-only debugger, and a "says it out loud" debugger that I build. I am using the ICD3 and I spent three days trying to get MPLAB X to accept the COFF+HEX file for debugging. Worthless. I have the latest FAT32 library (ending in 7211) for dspic and PIC24. Also: my part was not on the definitions list, so I had to enable it in all three FAT32 places before installing the package into my mikroC. Also, in situations like this, I never use malloc().

Problem: I get one file on FindFirst, and then the 2nd file on FindNext, and then the same second file forever until I hit the MAX of the loop. Note that I "scribble" on the dirent variable to make sure I'm not crazy...and each time its filled with good data (from the same file again). Second filename is "blue.mp3" and attribute ("r") is 32....ARCHIVE.

1) I am thinking that my audio debugger is triggering the problem the regular play code does
2) Tomorrow I'm going to try (painfully) with my "lights only debugger" that can flash out both integers and arbitrary ASCII and see if the audio debugger statements are triggering this bug even though
3) I saw some other posts about SPI1 and FAT32. I don't get it: if both key devices are ON SPI1, how can I do anything about without a hardware change?

Thanks much in advance!

(the experienced guy made humbly into a brand-new n0ob) G.

[boardman]

Doing experimentation all weekend, and its clear there's interference between the MP3 chip and the SD card chip.

I rearranged the code to do all the directory functions first, and then switch to playing. Tracing with LED's into the play code, I see that some files don't play. Detailed tracing shows that the normal flow:

1 - Exists?
2 - Get size
3 - Open
4 - Read in loop based on size, not EOF

File 1 goes all the way, plays nicely. File 2 gets to where we retrieve the size, and I get -540 with the return code is ok. The file opens ok, and the while loop naturally doesn't do anything since the "while file_left_to_do > 0" condition isn't met. File 3 plays, File 4 does not, also has negative size.

When I put a list of files on the mSD chip we get consistent but arbitrary output.

Looking at the mikroe examples for playing MP3 audio, I see in one routine that BSYNC is set in the beginning of the routine, but not the end. Doesn't it have to be restored? I'll post source shortly.

G.

[boardman]

Further experimentation shows the following:
- my audio debugger is interfering with the SD card code (duh) so I switched to lights
- a simple branch of my program (with most code deleted) that just spins through the SD card's filesystem and "blinks out" the file names in blinkanese shows that the first few returns from FindNext() are files on the SD card, and the rest are garbage
- CHKDSK of the card shows no problems

Both the SD card and the audio chip are on SPI1. They have distinct select lines.

Is there any special trick re: the FAT32 library, that might interfere with the audio chip? How does the FAT32 file know what select line to use? Is there an API call to set the select? Etc.?

Thanks in advance. G.

[ISL_Dave]

Is there any special trick re: the FAT32 library, that might interfere with the audio chip? How does the FAT32 file know what select line to use? Is there an API call to set the select? Etc.?

The MMC Library I believe drives the communications interface and uses the Chip Select and the FAT32 library performs the transfer protocol.

You have defined the chip select pin haven't you?

i.e.

Code: Select all

 sbit Mmc_Chip_Select           at LATB13_bit;
 sbit Mmc_Chip_Select_Direction at TRISB13_bit;

I also had weird issues with the FAT32 library on my old design which used a PIC18FJ micro and it turned out that I had neglected to install a pull-up. I have overlooked it because it only seemed to effect two FAT32 functions, the FAT32_Close() and FAT32_GetFreeSpace() functions. I had never experienced any other FAT32 or any FAT16 functions failing when this pull-up was missing.

Strangely, the get free space function was intermittent and depended on how fragmented the card was and the close() function locked the micro up when called if the card had been removed beforehand.

Regards,
Dave