Storing/reading raw data on micro SDHC card

Hi Magda,

Sorry for the delay.

Magda Butnaru said:

Is there a way to work around the FAT32?

What do you mean by this?

Do you require the file system structure to read the data from the SD card in an operating system like Windows afterwards?

Or are you interested in just writing raw data to the SD Card and then reading raw data from the SD card without the ATAFS or FAT32?

Have you seen the MMC/SD examples in the Chip Support Library download? Download the C55XCSL-LOWPOWER one.

Both file system and non-file system examples are available under... C55 Low Power Chip Support Library v2.50.00\c55xx_csl\ccs_v4.0_examples\mmc_sd\

Hope this helps,
Mark

Hi Mark,

Thanks for your reply.

I am familiar with these examples. In fact, I did base my code on these examples, specifically on CSL_MMCSD_dmaExampleOut . Unfortunately, these examples write and read only 512 bytes. I need to write 8GBytes or close to this size. I do not particularly care if it's FAT32 or raw data. Obviously raw data is simpler.  I just want to reliably fill the card with data sampled in real time. I buffer these data in much larger buffers and attempt to fill the SD card with one buffer while the other acquires the sampled data. I am not able to reliably write more than 100 MB or so. The program hangs with MCSD status 0. Thus I was wondering whether it is important to use FAT32 to write. The off-the the shelf SD cards come in FAT32 format, and I know I clobber this format by dumping raw data, even though I skip a good number of sectors at the beginning.

Let me know how do you think I should proceed to fill 8GBytes with data: raw? FAT32?

Regards,

Magda

Hi Magda,

In your case, you may want to use the raw data instead of the FAT32. The CSL_MMCSD_dmaExample or example 3 for mmc_sd is a good start point.

My guess is that addressing difference for SDHC and SD may cause the error. Since the 8GB SD card is the SDHC card which is using the block address while the SD card uses the byte address. You can change the SD example code as follows:

 for (looper=0; looper<WRITE_LOOP_NUM; looper++)
 {
  if (mmcCardObj.sdHcDetected)
  {
   cardAddr = looper*(BUFFER_MAX_SIZE/512);
  } else
  {
   cardAddr = looper*BUFFER_MAX_SIZE;
  }
  /* Write data to the memory card */
  mmcStatus = MMC_write(mmcsdHandle, cardAddr, BUFFER_MAX_SIZE, gWriteBuff);
  if(mmcStatus != CSL_SOK)
  {
   printf("API: MMC_write Failed\n");
   return(mmcStatus);
  }
 }

If you want it to be faster, you can use bigger BUFFER_MAX_SIZE (word size). You may also need to change the WRITE_LOOP_NUM to the proper size for  your app.

Best regards,

Ming

Hi Ming,

I was already using what you suggested, so I believe the problem is differrent. Have you ever tried filling 8GB raw data using the DMA approach listed in your example? By the way, I am also unable to fill a standard SD card (2GBytes) with raw data.

Regards,

Magda

Hi Magda,

I do not have a 8GB SDHC card, but I did try the 4GB SDHC card. The ccode I posted in previous reply is working. It stops at looper = 483072 which means the SDHC card has 483072*8KB = 3957325824 byte = 3.69GB.

Attached please find the c file and cmd file.

Best regards,

Ming

Hi Ming,

I am the end user for the raw data recorder project that Magda describes.   Up to know, the architecture was a main program  like looper, which keep track of how much data was in the buffer and when to call mmcsd, but with the added complication of an ISR that acquired the data and posted it to the looper buffer very 5 microseconds. We have never gotten that architecture to operate reliably. 

I can reorganize the system to trade off the interrupt and use a single very fast superloop.  But nothing is simple.  I would appreciate your review of the following concept. Note that Part B has to execute within 4 microseconds.

Michael

 Main Part B –  collect data at fixed rate, write to log buffer,  every 512 send sector & data pointer to SD driver

Inputs   starting sector address

Outputs               sector address, pointer to data

Update and write next address to the INTAN; either a DSP 4  bit write directly to the Intan which takes 20nsec,  or use the DSP to toggle the PIC, which takes 5 to 6 * 200ns, to complete. Then the Intan requires a settling time  of 1 microsecond. So, do something constructive with the time.

Poll the DMA driver to see if it needs data;

Yes; then pass the next sector # that it will write to, and the pointer to (appropriate) 512 bytes of data in log_buffer that is ready to go.

No; do nothing else

Read ADC #1, shift and mask the 16bit result into 2 discrete bytes

Read ADC #2, shift and mask the 16bit result into 2 discrete bytes

Write the 4 bytes into the next 4 bytes of Log_Buffer, update counter at the same time

Is log-buffer 50% full?

                No, do nothing

                Yes, toggle log buffer pointer, increment sector address

At end of file?

                No, poll on timer until timer = 0, then jump to top of Part B

                Yes, go to Part C

Hi Ming,

Thank you for posting your example code for writing to an SD card!

Problem:

I have been able to compile it and run it in Debug mode when the target is connected to CCS via the XDS100v1 emulator. However in Stand-alone mode, i.e., when I create a bootloader and burn it to SPI flash using the programmer utility for c5535, the program does not write anything to the SD card.

Symptoms:

I know the methodology for boot loading programs from SPI flash is working. This is because to your sample code, I have added simple LED flashing code on GPIO15 for my custom board. I observed that just before MMC_write() all MMC initializations work. But the does not proceed after the MMC_Write. 

I probed out the pins going into the SD card and looked at SD_CLK and SD_Data0 pins on an oscilloscope. They toggle as expected when running in Debug mode. But when I run in stand-alone mode I do not see any SD_CLK or SD_Data0 signals.

The hex55 command I used to create the bootloader is: hex55 -i *.out -o bootimg.bin -boot -v5505 -b -serial8

Do you know what this issue could be?

Thanks,

Milind

This is where I found my answer. 

http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/110/t/33709.aspx#641859

The issue was Idle Config Register being set to Idle peripherals after bootloading and has to be manually reset