CC2540 Chan's FatFS memory issues

There is not a huge amount of memory legroom once the BLE stack is added. The default configuration does not allow for a large number of static variables as a fair chunk >3000 bytes is allocated to the heap. Have you tried using the heap to dynamically allocate the sector map as a long lived dynamic variable (i.e. allocated inside main process init function), or reducing the heap size?

I'm not sure I follow. Do you mean declaring the whole object in my init function and allocating the big array (sector map/window) with osal_mem_alloc(512), as bellow?

void osalInitTasks( void ){

//...

FATFS* sdcard;

sdcard->win = osal_mem_alloc(512*sizeof(byte));

//do my stuff

//osal_mem_free(sdcard->win); 

// want my filesystem available for infinity, so no free

}

About reducing the heap, I did try reducing INT_HEAP_LEN preprocessor to no success. I have used 2048 and 1024 besides the default 3k.

P.S: For this type of allocation, which needs not be freed as I regularly need reads/writes to the card and filesystem constantly mounted, could I do something like using the ROM allocation API (I believe the functions were called osal_nv_something but I don't have documentation at hand).

Yes you have the right idea, but you should do it inside the init function for the task it is associated with for cleanliness. If it is done there, before osal_mem_kick(); it will be placed in long term heap and you shouldn't have to free the memory once it has been allocated. Is the device a central or peripheral role & how many concurrent connections do you need? - this will have an effect on heap needed by the stack. From experience allocating 512 with the default hep length should be ok, but is starting to push the limit. There are some debug functions in OSAL_Memory that you can use to profile your memory use and record the high water mark. This is useful to see if you are getting close to the heap limit. My instinct tells me something else is amiss other than the amount of memory if you still have the same issue after implementing these suggestions.

Thanks for the reply Eng351.

I am already doing it like that, initializing the object inside osal_init_tasks(), before osal_mem_kick(), so it's not the issue.

To answear your questions, I have two devices directly connected to the chip: an ISR periodic information broadcaster that can also receive stuff on demand, and the SPI SDCard reader. I'm not sure what you mean by central role, but the broadcaster device is definitely central, as the application makes no sense without a connection to it. They both connect to USART0, on alt1 and 2. The ISR device broadcasts stuff in customizable periods, from 1 to 30 seconds, and that stuff is parsed and relayed to the BLE stack to reach a connected iPhone. The stuff itself is usually no longer than 40 bytes (might require two GATT messages but that is transparent to me), and I only ever need one single BLE device (iPhone) connected at a time.

About debugging the memory, I have set OSALMEM_METRICS to true in order to debug the various memory values at runtime, but they seem inconsistent even when running working examples.

What I mean is the bluetooth low energy role of your CC254x chip, not concerning any peripherals wired up to it. If you are connecting to an iphone with GATT you will most probably be a peripheral role device - just check what library is included with your project. Peripheral with only max 1 connection shouldn't need an excessive amount of memory. It sounds as if the stack is overflowing somewhere - does the file system code allocate any large auto variables in any of its functions? Have you looked at your memory usage via the map file?

Hi...

I'm looking to do this too...   I have gotten the Chan code to compile, and am about ready to test with my CC2541 application.

My biggest concern has been the inclusion of the "dly_us" function in Chan's code.   I suspect that this will break the BLE functionality if the SD card doesn't respond right away.   How have you dealt with this?   Have you gotten your combination of SDcard/BLE to work?

I was considering breaking the Chan code into multiple tasks so the delays can be "hidden", but this would be a major re-write of the code and I don't know if I have the time to do this.

Thanks!

Hello,

Any ideas/progress?

I tried to use SerialApplication + FatFS. Each part is working itself good. But there is no multi-tasking. So when both components are running (BT + mmc access with blocking delays) BT connection breaks and not working until restart.