2012-09-23 02:13 PM
Are there any examples or application notes about how to execute a Code from internal Ram , i need to do IAP , but when programming flash from a flash based code , the controller hangs and even debugger can't show , it becomes responsive , stm32l151xx errata sheet suggests that this is due to device errors Workaround
''The IAP routine must be relocated in RAM, and programming followed by a dummy read in Flash before resuming execution from the Flash memory '' but there are no example available , please suggest how to do this in IAR2012-09-23 07:45 PM
It's not a problem unique to STM32's, so you might be able to find some examples elsewhere. Moving blocks of code around is a pretty fundamental micro-processor concept.
You should review your IAR documentation as see if there is a pragma or directive to place specific routines into the RAM section/segment. One has to watch however that the code you place there is not calling external routines, or libraries, which are located in flash. The c runtime startup code will copy this data into an RAM, and calls to the routines will execute in RAM. One of the generally more elegant ways to doing this is to have all the code you want to copy (via memcpy, or equivalent) written in contiguous assembler routines, where all the calling/branching is self relative, and the code is self contained. You also have to consider things like the stack, and where the code execution might go once the routines return. Specifically if you've erased the flash, or a different code image now exists in the original location.2012-09-28 12:35 PM
Thanks clive, i found that there is __ramfunc directive to place code in ram ,
There are two parts of my code , one is the Main application and other the IAP , , the stm32l151 errata , CD00278726.pdf '' ultra low power limitations '' does not advises to do IAP from 0x08000000 to 0x0800ffff , so i will prefer to keep it in the other half , i.e. after 0x80010000 , and Main application at 0x08000000 but problem is that everytime after reset the core will start from 0x80000000 , and if by chance once reprogramming is not sucessfull and system resets , there will be no application at 0x80000000 to tell the core to jump to IAP ( 0x80010000 ) , so IAP will not execute , is there any software solution for this , which can make the core always start @ IAP , apart from creating a third project @ 0x80000000 , to choose between IAP and Main Application2012-09-28 01:25 PM
I read something different into the Errata, basically that the flash buffering scheme causes execution reads to provide the wrong data to the processor while you're programming/erasing the flash array. The processor then crashes.
This does not preclude you from placing your boot loader in flash at 0x08000000, leaving it there and not erasing it. A very simple boot loader might only take 4KB, a more complex one perhaps 16KB. I can do a SDIO + FATFS accessing boot loader in less than 16KB. The real take away from the errata is to put the flash loader portion of the code in RAM, and do not attempt to do an erase/write/execute operation on the flash array. Such an operation works on other STM32 cores by stalling processor execution, when it notices an on-going erase/write operation, basically by stuffing thousands of wait states. Apparently the mechanism used on the STM32L is somehow broken, or has some critical path or metastability issue. Presumably the EEPROM emulation uses a different array.2012-10-11 12:22 AM
I modified the code to execute from internal Ram after copy , and its working fine , but i can't use debugger when executing from Ram , i am using ST LINK , when i am debugging the Ram based code , it will never stop at break points , in di assembly i can see that BreakPoints are marked at the function ( at Ram addresses ) still it does not stops , are there any more settings?
2012-10-11 03:49 AM
I modified the code to execute from internal Ram after copy , and its working fine , but i can't use debugger when executing from Ram , i am using ST LINK , when i am debugging the Ram based code , it will never stop at break points , in di assembly i can see that BreakPoints are marked at the function ( at Ram addresses ) still it does not stops , are there any more settings?
That is perhaps something you can discuss with IAR support. Your options may be to set the breakpoints after the run-to-main completes, or switch to the disassembly window and step over, in, out.