cancel
Showing results for 
Search instead for 
Did you mean: 

How to optimize SDIO writing with incoming CAN messages in sync?

WNguy.1
Associate II

Hello everyone,

I've made a code within my STM32f405 MCU that writes SD 4 bits wide bus onto an SD card.

I'm making a program where "HAL_CAN_RxFifo0MsgPendingCallback" fills a "uint32_t dataCANID[14339]" array and increments a counter. This counter value in the main() will continue until its filled the "buffer-1" and f_writes & f_syncs, resets the counter value to overwrite the buffer with new CAN ID messages. I'm running into an issue where I'm losing HUGE amounts of data ~roughly 30% of CAN messages coming in.

My test runs as follows:

USB-CAN adapter sends X amount of messages, I compare it with the written SD bin file on how many IDs were written, then account for the max "buffer" size loss and get the difference.

I'm wondering what I can do to reduce this loss or improve it?

DMA transfer? Hard coding the Rxfifomessege, CAN interrupts disabled?

Any tips or tricks would be greatly appreciated!

Below is my main functions:

//MAIN

 while(1){

   if(counttrack == (MAX_BUFFER_SIZE_BYTES - 1)){

   counttrack = 0;

   HAL_GPIO_TogglePin(LED_RED_GPIO_Port, 0);

f_write(&myFile, twodataCMDID, sizeof(twodataCMDID), &rtnBytes);

HAL_GPIO_TogglePin(LED_RED_GPIO_Port, 1);

f_sync(&myFile);

   }

   }

//CAN MSG

void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef * hcan) {

HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, &rxheader1, dataCMD);

twodataCMDID[counttrack] = rxheader1.ExtId;

counttrack ++;

}

1 ACCEPTED SOLUTION

Accepted Solutions

The callback should manage the buffer, and either use a ping-pong arrangement, or copy the data to an inactive buffer that the foreground task can flush WITHOUT the callback/interrupt interfering in the background.

The counttrack could also advance too far in the current implementation. You need to manage/bounds check in the callback.

The buffer you write should ideally be a multiple of the sector or cluster of the underlying file system, ie 512 bytes, 4096 or 16384 bytes for example.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

2 REPLIES 2

The callback should manage the buffer, and either use a ping-pong arrangement, or copy the data to an inactive buffer that the foreground task can flush WITHOUT the callback/interrupt interfering in the background.

The counttrack could also advance too far in the current implementation. You need to manage/bounds check in the callback.

The buffer you write should ideally be a multiple of the sector or cluster of the underlying file system, ie 512 bytes, 4096 or 16384 bytes for example.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Thanks! I was in route of doing the ping-pong arrangement, this was a concept code that works so I'll definetly have some more safety checks for the counttrack :). Thanks for the advice, I'm going to dive into DMA transfer and interrupts for streamlining the Data. Great useful info