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

[Andrei Chichak]

Posted on January 24, 2017 at 00:08

If I understand your question properly, Flash sector 0 is at location 0. According to the ARM architectural design, the processor, when booting, will pick up the initial stack pointer from location 0 and the initial program counter at location 4.

Following that will be the initial interrupt vector table.

Your code hasn't even started running yet. So if you want to have your vector table somewhere else, that's fine, but the initial vector table is located at location 0. The reset value for VBR is 0. After your code gets going, you can move the vector table but, according to the chip design, it starts at location 0.

You see this exact same design on MC68000 family processors BTW.

Andrei from The Great White North.

[waclawek.jan]

Posted on January 24, 2017 at 00:26

Are you trying to use FLASH Sector 0  as data memory, for data to be stored by the application, as an EEPROM replacement?

If so, you can't. As Andrei explained above, Sector 0 (address 0x0800'0000 but also 0x0000'0000 during booting from FLASH) holds the default vector table.

JW

[Sam V]

Posted on January 24, 2017 at 00:12

Sector 0 on the board is at location 0x08000000 if I understand correctly, and it works when I'm debugging but not a general flash.

[Sam V]

Posted on January 24, 2017 at 00:32

Is there a way to use say, Sector 3 instead then? If I cannot use Sector 0 that is totally fine, I'll try another one, but it would be nice to know why (after setting the appropriate vector table offset) it works when debugging but not otherwise.

Thanks!

[Andrei Chichak]

Posted on January 24, 2017 at 00:41

Okay, the 415 is the brother of the 407, so look in RM0090, page 374. 

The chip has a bootloader built in, it resides at location 0. Your code gets written to location 8Bazillion.

Now, when your chip boots, it looks at the level on the BOOT0 pin. Boot0 is used to control what shows up at location 0. If BOOT0 is high, it remaps location 8bazillion down to location 0, then boots from location 0, your code. If BOOT0 is low, you execute the bootloader because it is - right at location 0.

BOOT0 is used as a jiggery pokery way to select wether your code or their code gets executed, but it shows up at location 0.

A

[Andrei Chichak]

Posted on January 24, 2017 at 00:43

How about BBRAM, can you use the RAM in the RTC instead of FLASH?

[Tesla DeLorean]

Posted on January 24, 2017 at 01:55

The code always executes from the image the processor can read from the base of memory at ZERO, the memory that gets mapped here is determined by the BOOTx pins at reset, you don't get an opportunity to change the Vector Table until later, and it of course gets reset by a chip reset. The debugger might work because it stops the processor, and redirects/reconfigures things for you.

There needs to be at least two vector entries (SP and PC) in the FLASH memory that appears at 0x08000000 (0x00000000 mapped). They can point anywhere else in memory. To execute code placed at 0x0800C000 you would need a loader at 0x08000000 or vector entries for SP/PC copied from the table you have at 0x0800C000

The processor and external logic is not that complicated, and the behaviour is pretty easy to predict. People seem to get tied in all sort of complicated knots, but it is very simple and the core is very dumb.

[Sam V]

Posted on January 24, 2017 at 16:49

This actually helps a lot, I wonder if the debugger (which has access to my BOOT0 pin) is doing something during launch that doesn't happen when it's a normal start.

Thanks for the info!

[Sam V]

Posted on January 24, 2017 at 16:50

I  unfortunately cannot, device given to me to write firmware/software on, but cannot do hw revisions and that was not provisioned from the start.