Has anyone tried executing code/Debug from SRAM instead of flashing everytime on stm32f407 using Keil MDK5 ?

[kiran kanchi]

Posted on June 04, 2018 at 18:32

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 .

[Bogdan Golab]

Posted on June 04, 2018 at 18:40

https://community.st.com/0D50X00009bMM79SAG

 

[Tesla DeLorean]

Posted on June 04, 2018 at 18:47

>>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...

[Bogdan Golab]

Posted on June 04, 2018 at 18:58

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.

[kiran kanchi]

Posted on June 04, 2018 at 19:03

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

mem addresses.

On Mon, 4 Jun 2018, 10:18 p.m. Clive One, <st-microelectronics@jiveon.com>

[Tesla DeLorean]

Posted on June 04, 2018 at 19:57

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.

[Tesla DeLorean]

Posted on June 04, 2018 at 20:05

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.

[kiran kanchi]

Posted on June 04, 2018 at 20:12

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, <st-microelectronics@jiveon.com>

[Bogdan Golab]

Posted on June 04, 2018 at 20:44

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...

[Tesla DeLorean]

Posted on June 04, 2018 at 21:02

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..