Using flash Sector 0 for application memory

[Sam V]

Posted on January 23, 2017 at 23:54

I have been trying to use Sector 0 on the STM32F415 chip to allow me to only consume 16K of the memory as I don't even need to persist half of that. 

Unfortunately, even after setting Vector offset (and testing if FLASH offset helped), I can only run my program in DEBUG mode. For some reason, debug works as expected, but the second I try to run it on its own (just flashing to the board) it gets hung up somewhere and ST-LINK Utility says that it is halted and cannot be ran.

I can solve my issue by using Sector-11, but that consumes a whopping 128K whereas 16K is already way more than I need, and I cannot use the EEPROM due to being given a board that cannot have hardware modifications.

Any help would be appreciated!

#flash #vector-offset

[Tesla DeLorean]

Posted on January 24, 2017 at 17:01

No the debugger doesn't control the BOOTx pins. It can however stop and change execution, and reprogram the VTOR and mapping registers.

The processor is very dumb, it does things in a very mundane way as described in the core technical reference manuals, and the ST manuals.

VTOR is reset to zero, the memory presented to the core at address zero is used to start the device, the memory mapped into this region is the BASE of RAM, FLASH or ROM depending on the strapping of the BOOTx pins.

You need to stop fighting with the way the processor is designed, it is a battle you will lose, and embrace the functionality as implemented, and adapt to it.

[Tesla DeLorean]

Posted on January 24, 2017 at 17:06

Then stop fighting the processor. Why can you not put a pair of vectors (SP and PC) into the base of FLASH at 0x08000000?

There are three other 16KB FLASH sectors that can be used for data storage and configuration if you carve them out of the space the linker is provided to place the firmware.

[Andrei Chichak · Accepted solution]

Posted on January 24, 2017 at 17:09

Unfortunately the system is not completely plastic, you (and your keepers) have to live within the constraints of the hardware. In embedded systems, you are dealing with very constrained systems.

If you can't add a battery to use BBRAM, and you can't add external flash or eeprom, and you can't use sector 0, then the choices are made for you. You're going to have to waste a bigger sector. 

That choice is going to really suck when you run out of code space and erasing the sector blows out a chunk of your program.

As I always say 'there are tradeoffs'.

[Sam V]

Posted on January 24, 2017 at 17:09

The pair of vectors at 0x8000000 is actually a great idea, I hadn't considered that.

[Sam V]

Posted on January 24, 2017 at 17:17

This all helped a lot, and luckily I have the free space to handle this using a larger sector for now, I'll have to cross the 'out of space' bridge when I get to it, likely with a forced hw revision.

Thanks for everything

[T J]

Posted on January 27, 2017 at 00:32

Hi Clive, as per your suggestion above, I have tried to find these manuals for download.

' core technical reference manual '

I cant find the register descriptions...

ARMv7 ref manual, Cortex M0 manual...

none have the register descriptions.

I found this one, ARM® Architecture Reference Manual ARM®v7-A and ARM®v7-R edition

this has many resister descriptions, but I could find any descriptions for peripherals,

for example, the IER register within the CANBUS set.

Can you point me to a complete register set document ? I am working with the STM32F091.

Thanks for the support Clive, they should pay you....

I would be willing to pay for the forum...

is there such a forum ?

Thanks Clive,

[Andrei Chichak]

Posted on January 27, 2017 at 07:48

Nick,

The peripherals are not a part of the ARM architecture. These are added by the manufacturers and vary wildly.

You are probably looking for the 

STM32F091 reference manual. Weighing in at 1004 pages:

http://www.st.com/content/ccc/resource/technical/document/reference_manual/c2/f8/8a/f2/18/e6/43/96/DM00031936.pdf/files/DM00031936.pdf/jcr:content/translations/en.DM00031936.pdf

 

A

[Tesla DeLorean]

Posted on January 27, 2017 at 08:26

As Andrei indicates the ARM TRM's just describe the core, ie the CPU, ITM, DWT, NVIC, etc, ie the stuff they licence from ARM directly. The books by Joseph Yiu provide this detail from a different perspective, a more practical/pragmatic one. I've been tinkering with ARM stuff since the mid-80's when they were Acorn.

Each vendor adds there own peripherals, memory subsystem and caching. Some of ST's peripherals use third-party IP, these include USB, CAN and Ethernet, here the manuals get a bit sketchy and take some deciphering. Other people licence the same IP, and some times their documentation is better/different. For the ST side of things the Reference Manual is the primary source of information. Some more internal aspects of the design can be gleaned from presentation slides, source code and inference from block diagrams. I have a background in IC development and validation, so I understand the logic, and what to look for, and experiment with.

I accept PayPal and hardware.

[Tesla DeLorean]

Posted on January 27, 2017 at 08:37

Quoting myself

'I don't see any errata for the CAN peripheral, you'd be better digging into the Third Party IP vendor's documentation to understand the internal mechanics. bxCAN - IPMS/CAST'

Not sure this is the bxCAN, but popped up with a little fishing..

http://www.can-wiki.info/doku.php?id=controllers:cast

 

I did some analysis of the CAN filtering, and posted examples.

[T J]

Posted on January 27, 2017 at 22:37

earlier Clive stated

' I did some analysis of the CAN filtering, and posted examples '

where are they posted?