Using f_write in a loop to write multiple chunks of data, doesn't seem to work

[JWood]

I'm using the following code:

				 //100KB buffer
				 uint8_t testBuffer[100000];
 
				 for(int i = 0; i < 100000; i++)
				 {
					 //Fill buffer
					 testBuffer[i] = 'U';
				 }
 
				 BSP_LED_On(LED_BLUE);
 
				 for(int z = 0; z < 5; z++)
				 {
					 res = f_write(&MyFile, testBuffer, sizeof(testBuffer), (void *)&byteswritten);
				 }
 
				 BSP_LED_Off(LED_BLUE);
 
				 //Check write OK
				 if((byteswritten == 0) || (res != FR_OK))
				 {
					BSP_LED_On(LED_RED);
					Error_Handler();
				 }
				 else
				 {
					f_close(&MyFile);
				 }

To test writing 5 100KB chunks to the SD card.

Regardless of the size of each chunk, the first one seems to write fine, then after that, nothing.

I've tried a short delay between chunks but it doesn't seem to help.

Do I have to flush the buffer or anything like that inbetween f_write commands?

[Tesla DeLorean]

What STM32 / board?

f_write() should work without additional intervention or delays, provided your DISKIO layer performs its job properly, and is well tested/validated.

You're not going to be able to resolve low level issues from the top level abstraction

[JWood]

Hi Clive, thanks for the quick response!

I'm using the F722ZE Nucleo board with the uSD FatFS example provided in the cube package.

Obviously this uses SPI mode as it's designed to work with an arduino TFT shield. I've been using it just fine so far, but I'm not sure where to go from here.

[Tesla DeLorean]

Using SDIO here on NUCLEO-64/144 implementations for speed

The Adafruit SPI SD driver had some issues with multi-sector read/write, I posted a bug report about this many moons ago. Not really spent a lot of time on the SPI due to the relative slowness for logging applications. To make it work you'd need to focus on debugging the DISKIO/SPI implementation.

Really want to write blocks that are a power of two, 32KB (0x8000) would be sweet-spot for speed/size. The erase blocks on the SD card's NAND are likely >=128KB

[JWood]

Okay this is some very confusing behaviour for me.

If I declare the for loop variable (z) as a global volatile, the code runs just fine, and I can write as many times as I like.

Once I change it back to for(int z = 0; z < 5; z++), the variable z seems to keep getting reset to zero and the code just loops eternally.

I've never seen something like this before, can anyone spot what I'm doing wrong?

[Tesla DeLorean]

I wouldn't have massive arrays as auto/local variables, the stack usually can't deal with that.

[JWood]

Declaring it as a global seems to have fixed everything, still a little slower than what I'd like but I'll have to look into using SDIO instead or try and boost the SPI clock rate up.

You've been a great help Clive, very much appreciate it!