/var/www/restricted/ssh/stm32/www/stm32circle/ STM CircleOS forum / Primer 2 - RAM boot mode

Username:     
Password:     
             

Forum

# 1   2009-04-11 10:28:47 Primer 2 - RAM boot mode

robbee
New member
Registered: 2009-03-30
Posts: 4

Primer 2 - RAM boot mode

Hi!

After I read in ST reference that FLASH embedded in STM32F103 is guaranteed to last only 10000 erase/write cycles I started thinking of a "in-RAM" debug mode.

When I switched Boot Mode to "RAM" in Ride7 project configuration I'm having

Wrong boot mode detected: FLASH mode
Expected mode: RAM mode
Aborting.

After looking up at Primer2's PCB I saw that BOO0,BOOT1 are hardwired for FLASH mode and there is no jumper to change to RAM mode.

So before I try to change PCB (remove R12 for the first) I'd like to ask you if after such a change I'll be able to debug in RAM mode using Ride7 ?

Of course I don't think of running Circle OS in such a setup, just some standalone code using only standard ST library.

Please advise!

Robert

Offline

 

# 2   2009-04-11 17:50:50 Primer 2 - RAM boot mode

jetcode
Member
Registered: 2009-04-03
Posts: 49

Re: Primer 2 - RAM boot mode

Hi Robert ... I wanted to share my experience regarding flash longevity. I do not represent STM32 or the Primer 2. I am a user like you. Apologies if this information is redundant.

Manufacturers state a "guaranteed" number of program/erase cycles to give engineers an idea of the lifetime of the part. The number of actual program/erase cycles may be much higher but not guaranteed across all chip lots. Think of it like a military specification in which reliability is given precedent. The guarantee statement is a liability clause for replacing faulty silicon should that occur.

Hypothetically spending 10000 program/erase cycles: If flash was programmed 25 times a day it would take 400 days to reach the guaranteed limit. That's a LOT of development time!

Most users will never reach the maximum number of guaranteed program/erase cycles.

Where this specification does matter most is on systems that use NAND flash technologies for content such as iPod, etc. In an intensive application it is possible to reach a guaranteed limit for a given set of cells which is why NAND flash drivers use a technique called "wear leveling" which essentially ensures that all NAND cell blocks are used equally thereby increasing the life of the silicon. "Wear leveling" will actually move files that are stored longest to the most used cell blocks thereby making available to the system the cell blocks with the least amount of use. NAND flash drivers manage bad blocks over the lifetime of the silicon. NAND flash drivers are expensive and there is a reason for that: efficiency and complexity of design.

My guess is you can rest easy I am pretty sure you will get your moneys worth from the STM32 without flash failure for years to come. Then again I don't know your development style and practice like you do. I typically get a project up and running in 50-500 program/erase cycles.

Joe

Last edited by jetcode (2009-04-11 18:01:27)

Offline

 

# 3   2009-04-12 10:47:07 Primer 2 - RAM boot mode

Francis
Administrator
From: France-Grenoble
Registered: 2007-07-09
Posts: 890

Re: Primer 2 - RAM boot mode

Agree with Jetcode. You can stay in FLASH mode and ignore the numbers... Now, yes, you could boot in RAM mode using RLink, (but without CercleOS).

Offline

 

# 4   2009-04-14 09:53:57 Primer 2 - RAM boot mode

robbee
New member
Registered: 2009-03-30
Posts: 4

Re: Primer 2 - RAM boot mode

I'm on my learning curve therefore was thinking of using RAM just for sake of efficiency. You may be right that I'm not going to reach the cycle limit of the FLASH :-)

Thanks!

Robert

Offline

 

# 5   2009-11-12 16:40:43 Primer 2 - RAM boot mode

Heinz
New member
Registered: 2009-11-03
Posts: 1

Re: Primer 2 - RAM boot mode

I have the same problem with a new Primer2: Using debug in Ride, setting it to RAM-Mode an error occurs:

OPI driver error (1)
Wrong boot mode detected: FLASH mode.
Expected mode: RAM mode.
Aborting.

If I switch to Flash mode, I can download the code and debug the device (but the original programming is lost).

Also I found the resistors on the Primer2 board: Boot1 = H, Boot0 = L
That means device is in flash mode!

It is not the question of circleOS. It happens with and without circleOS.

Offline

 

# 6   2009-11-13 09:10:03 Primer 2 - RAM boot mode

Francis
Administrator
From: France-Grenoble
Registered: 2007-07-09
Posts: 890

Re: Primer 2 - RAM boot mode

Yes, the FLASH mode is hard-set on the Primers. The FLASH is large (512KB), and the RAM is smaller (64KB). Why do you want the RAM mode ?
For debugging ? but the 6 hw breakpoints in the core are quite comfortable).
To save the original program ? but restoring the 'default factory' program is quite easy too.

Offline

 

# 7   2009-11-15 10:10:18 Primer 2 - RAM boot mode

themanix
Member
Registered: 2009-10-17
Posts: 17

Re: Primer 2 - RAM boot mode

Executing from ram is faster... I have some old designs that used to copy the entire flash program to ram and transfer the execution. This would be problematic in STM32 but that was the reason.

   I actually came to the same problem with Boot0 and Boot1 but that was because I wanted to use the bootloader, I am using an R6T6 and I can not make it work so i wanted to give a try with the primer... unfortunately I realized it was wired to boot from flash.

Offline

 

# 8   2009-11-16 07:42:18 Primer 2 - RAM boot mode

Francis
Administrator
From: France-Grenoble
Registered: 2007-07-09
Posts: 890

Re: Primer 2 - RAM boot mode

Executing from ram is faster...

That's still possible... Booting in RAM does not make sense - except for debugging - . I don't understand why you say that copying the program from FLASH to RAM, then executing it would be a problem for STM32. Booting in RAM would be a problem if the program is not there.

Offline

 

# 9   2009-11-16 10:32:39 Primer 2 - RAM boot mode

themanix
Member
Registered: 2009-10-17
Posts: 17

Re: Primer 2 - RAM boot mode

Francis :

Executing from ram is faster...

That's still possible... Booting in RAM does not make sense - except for debugging - . I don't understand why you say that copying the program from FLASH to RAM, then executing it would be a problem for STM32. Booting in RAM would be a problem if the program is not there.

I meant to say that internal RAM is much smaller than the internal flash hence that would be problematic fit the code. There is no problem with ST32 but with an implementation like that.

Offline

 

Board footer