SAM V71, SD_MMC_example, FR_NO_FILESYSTEM

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using the SAM V71 Xplained Ultra Evaluation Kit, and trying to use the example SD_MMC_EXAMPLE in Microchip Studio. It fails when mounting the card with result 13 which is FR_NO_FILESYSTEM. I have tried multiple SD cards and formated them with different software, with Fat16 and Fat32, and both Linux and Windows. I haven't managed to get hold of a non HC, FAT16 SDcard. After what I have understood, this code should work for FAT32 as well, and at least with FAT16 even though it's on a SDHC card.
 
I have narrowed the problem down to the check_fs function and the following if statement:

if (LD_WORD(&fs->win[BS_55AA]) != 0xAA55) /* Check record signature (always placed at offset 510 even if the sector size is >512) */
return 2;

 

I thought this statement should be false, or more precisely, the sides should be equal, but they are not. The variable BS_55AA is defined to the value 510. Inside the fs object, the win list has the value 85 at the 510th index, and the value 170 at the 511th index. In hexadecimal 85 is 0x55, and 170 is 0xAA.
 
LD_WORD is defined as follows:

#define LD_WORD(ptr) (WORD)(((WORD)*((BYTE*)(ptr)+1)<<8)|(WORD)*(BYTE*)(ptr))

This seems to put the hexadecimal values of two following indexes and or-ing them together, so that 0x55 and 0xAA becomes 0xAA55. And this works, as 0xAA55 is 43605. I saved the LD_word as blabla in the following screenshot and compared it to a constant WORD blablabla = 43605. They are still not the same.

 

Screenshot of debugging the function where the problem occurs.

 

As shown in my debugging,  LD_WORD becomes 43605 which is 0xAA55, but the if-statement is still true and returns the error code 2. Does this have something to do with the types of the variables? LD_WORD is also of type WORD. I suppose it isn't the example code that is wrong, but me who's doing something wrong. I just thought it was weird that this if-statement runs even though it seems to be false. I do not have much experience, if that wasn't clear already, so sorry if the solution is obvious. :)
 
Would very much appreciate any help! Thanks in advance!

Last Edited: Wed. Apr 21, 2021 - 03:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it a cache problem ?

https://www.avrfreaks.net/forum/...

/Lars

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the input!
 

I should have written in my original post that I had read that disabling cache had worked for some. I hadn't tried this before now, and the test was successful.

 

However, I was hoping I wouldn't need to do this. The rest of the project is time-sensitive and should not be slowed down too much by having to access the RAM more than necessary, especially for all the other operations as well. But how much of a delay/lag impact would this result in for every operation? There is no way to use the cache for other operations and just make the SDcard-functions work with a small impact on other code?

 

Also, if this is the only fix, would it cause less lag if I disabled DMA? In that case, how should I disable DMA, and to what degree do I need to? Found some functions like: dmac_channel_disable(DMAC, CONF_HSMCI_DMA_CHANNEL);  , but this doesn't disable DMA as a whole?

 

Does anyone know why, if this really is the best solution to this problem? Is there no new version of this library/example project made to work with cache enabled?

 

Appreciate any answer to any of this!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

certainly there is a way to benefit from the cache without destroying data integrity. To my knowledge there are two possibilities.

1.) make use of the TCM functionality and put all the SD card related code and data into it. With this approach you have the same performance as caching without data inconsistencies.

2.) invalidate SD card related data just before reading from your SD card.

 

Actually you can combine both. In my application I put the RTOS functionality and the heap (that is the local stack of each task) into the TCM section. Additionally I modified the DMA functions of ASF3 (I'm not using ASF4) to invalidate the cache before activating a DMA read command. Actually the latter one is already included in the latest ASF3 code - however this code invalidates the entire cache that is usually not necessary and will slow down the whole thing. Therefore I modified it to invalidate only the section that is involved in the DMA transfer. You have to make sure that all DMA data is 32Byte aligned to match to the cache structure. This will lead to an inefficient memory usage. In my application this is tolerable especially if you consider the performance gain.

I have to say it takes me a couple of weeks to setup everything properly (I'm using all timers, 2xI2C, 13xADC, 10xGPIO, 3xU(S)ART, SPI, USB MSC+VCOM, SD-Card, 20kHz DACC, AES and about 15 tasks continuously active). However, it was worth doing this. My computation load drops from about 85% to 10% after making use of TCM and cache.

 

I found in this forum and in other sources (e.g. STM application notes) all the hints to make use of TCM and cache.

 

Best Regards

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks!

 

I don't think I will make the effort to optimize for TCM and cache right away, but try out the performance with the d-cache disabled first. However, if this is insufficient, I will be trying this out.