To prevent Flash wear out i am trying to debug code from SRAM on STM32F4 on Keil IDE MDK5.
kindly let me know if anyone has done it.
thanks in advance .
How to run&debug from RAM without flashing flash STM32 devices (Keil)
This procedure was tested by me for F1/F3/F4/F7/L0/L1/L4. The piece related to the flash algorithm is not required - a guy edited my post for unknown reason, and wanted to improve it;) Read my notes in the post to see the details. It does not work for F0 (M0 is different - no VTOR register - you need to re-map memory).
I usually develop the code using SRAM as the code memory. Not sure if this makes sense. I recall TI MCUs with pretty low number of erase cycles.
I think it's nice feature. Nothing more.
It is a good experiment without doubt. I worked through erase/writes cycles on the 15 minute EPROM type, where the reduction in iteration time made a big difference.
I do however think the mechanics of failure, especially under minimal/low stressing, are quite instructive. Had enough flash devices self-immolate that knowing the trigger conditions can be very helpful when holding a manufacturers feet to the fire.
Wow clive you seem to have a lot of experience!
I'm beginning to learn more about ARM eco system through ST discovery kits
Kudos to your made who this amazing board
Anyway would you recommend any materials such as text books to learn faster
? And of course I'm going all the examples in SDK thats helping too.
My university is super primitive so no help from there :-P
On Mon, 4 Jun 2018, 11:35 p.m. Clive One, <firstname.lastname@example.org>
ARM Cortex-Mx TRM (Technical Reference Manual)
Joseph Yiu - Essential Cortex-Mx books
J R Gibson - ARM Assembly Language
S B Furber - VLSI RISC Architecture and Organization
Books on logical and strategic thinking, problem solving. Avoid scripted, guide me, mentality..
Another good thing about trying to use SRAM is to fit the code on some low memory devices like STM32L011
It made me working on the register level;) For hobbyist the time spent on optimization & beautifying the code does not matter...
+1 on CM0/CM0+ the ST parts run really slow once you need a wait-state on flash. Can get close to 64 MHz out of SRAM, as I recall.
I had several STM32 Primer tools with rlink debugger / programmer. I do not like Ride7 so I decided to use Keil and load the binary code directly to SRAM.
I wanted to avoid PCB hacking (boot pins &UART1 access to use built-in bootloader OR swd pins re-routing to connect st-link).
USB was accessible through external connector so I developed USB-based bootloader just to load the code to SRAM...
Of course the STM32CubeProgrammer, for those who do not have such non-flexible devices like Primer / EvoPrimer tools, might be more convenient to use for downloading the code to SRAM...
On Tue, 5 Jun 2018, 1:19 a.m. Bogdan Golab, <email@example.com>
>>kindly let me know if anyone has done it.
Yes, done it on F4's and a host of other platforms. Built systems where a loader permits download and execution of .BIN and/or .HEX files from a terminal also..
uV4 and uV5 provide methods for downloading and running code in SRAM or SDRAM via debug scripts. Not hard to do.
If you are likely to get remotely close to the 10K erase/write cycles you're doing development totally wrong...
Thank you for snappy reply.
And yes I'm pretty sure i wont exhaust 10k R/W cycles. I just wanted to try
SRAM for the sake of knowledge .
I found a similar link for f1. Probably just need to update script with new
On Mon, 4 Jun 2018, 10:18 p.m. Clive One, <firstname.lastname@example.org>
The script in Bogdan's document seems generically workable on M3/M4 platforms (STM32 and beyond). M0+ devices have a VTOR, and M0 can be managed via remapping or strapping.
I'd really like to see the flash fail on the bench, if I lose a device during development it makes for a good object lesson applicable to support and production, seen enough devices fail to meet manufacturer specs over the years I'd rather have something in the lab than the field.
Retrieving data ...