Modyfing/replacing C funtion during STM32 work

[jakub.k]

Hello,

I'd like to implement simple DSP job on my STM32F4 discovery board. I wish to have possibility to change it during STM32 work without flashing program memory. Can I do that?

It's like I compile some C funtion to my library, send it to target (via usb), who will update/substitute DSP processing function to the new one saving in into the SRAM. C language recognise function as an address of its beginning, right? I would implement like two SRAM spaces for two functions I will switch between them every time new one is completely copied into memory.

STM32 will constantly gather some input data (but NOT from USB-key), process it with my DSP function and sent it back to Codec that I will add to my target, don't worry about hardware now.

 

[bigdogguru]

It's like I compile some C funtion to my library, send it to target (via usb), who will update/substitute DSP processing function to the new one saving in into the SRAM. C language recognise function as an address of its beginning, right? I would implement like two SRAM spaces for two functions I will switch between them every time new one is completely copied into memory.

Your plan certainly sounds plausible.

The STM32F4 series provides a 112KB SRAM1 area accessible by both the I-Bus, D-Bus and S-Bus, as well as DMA, Ethernet and OTG-USB.



You can typically specify the storage area of a particular section of code within the compiler/IDE toolset.

For example, using KEIL you simple right click on the source code file and assign an appropriate memory storage location for the resulting binary:



You will need to utilize either a standardized function prototype for all dynamic routines.

Or predefine several typedefs which act as function prototypes which you can then point to the specific entry point of the routines and utilize as function pointers.

The scheme would be essentially several function pointers which point to only two entry points, the proper function call chosen depending on the newly downloaded routine.

The new routine can then be downloaded via USB written into the SRAM at a predetermined entry point, it shouldn't be any serious issues dividing the SRAM1 area into two banks.

BigDog

 

[jakub.k]

Ok thanks, I really can see it now.

To be more precise:
1. It could be of course one function prototype like "void dspProcess(void)". It will always work on the same input data buffer (DMA) and output them back to codec - after it's fully executed. But the size of the routine will change along with the another downloaded versions, is it a problem? The DSP routine could be small (like multiple all the samples) or more complicated like filtering.
2. Going through manulals and references I'm still not sure where all variables are stored during executing whole stm32 program (from 0x200...?) and will them interact (destroy) with my program data (compiled and sent user routines). Which stm32 chip mechanism lets me seperate SRAM into banks?
3. You mentioned using IDE's to decalre where the sending data should be located. Finally I want use Matlab with Coder toolbox to generate C files, and link Matlab with compiler to generate final (assembled) version which I will send to target. Messing with header files (like automatically adding macros and defines - Matlab can do that) should do the trick?
4. Finally I realised that using USB data transfer will complicate my project so I change it to UART interface and FT232 chip -> PC. It will be slower of course but during data exchange DSP routine could be halted so "re-programming" speed is not fundamental.

After that 4 notes I would ask you if you still consider my project feasible or see some difficulties.
2.