Last entry in vector table provided by ST startup scripts

[hazelnusse]

Posted on September 09, 2011 at 00:16

In all the startup scripts provided by the ST standard peripheral library, there is an entry at the end that is:

  .word  BootRAM     /* @0x1E0. This is for boot in RAM mode for STM32F10x Connectivity line Devices. */earlier in the startup, BootRAM gets defined like:.equ  BootRAM, 0xF1E0F85FThe exact address depends on the particular device (low/medium/high/xl density, connectivity, value line, etc.), but all of them have a BootRAM entry in the startup script, and all are the last entry.I grepped the whole directory tree, and the only place ''BootRAM'' shows up is in the startup scripts.  I can't find any documentation on it at all, and the exception tables in the documentation of each chip don't go as high as this particular exception is located in the vector table, so I'm confused why it is even there.  The memory region is located somewhere in the Cortex-M3's internal peripherals, but I can't find any documentation on it.Does anybody know what this entry is and what it does?  Does it have anything to do with booting from RAM, like the name suggests?  Maybe something to do with the boot pins?Thanks,~Luke

[Tesla DeLorean]

Posted on September 09, 2011 at 05:58

When you boot from RAM (via the BOOTx pins) the execution address is fixed (processor dependent), and not pulled from the +4 vector address.

As I recall the hex code placed by GCC effectively calls the correct address. 000001E0 F85F F1E0        ldr.w    pc, [pc, #-480]    ; $000004 This behaviour has been discussed on the forum before, but I don't remember seeing any explicit documentation. It suggests the processor is running something else first, but without some hardware trace it's hard to tell what.

[hazelnusse]

Posted on September 09, 2011 at 06:32

The startup scripts in the arm and iar folders of the standard peripheral library don't have an equivalent BootRAM entry in the vector table, they simply have the entries of the vector table that are specified in the data sheet.  Only the TrueSTUDIO and gcc_ride7 startup scripts have this, and since both are based upon gcc, I'm assuming this issue is gcc related.

Can anybody explain *what is going on with this*?  I have read the forum posts on this issue and can see that it needs to be in there, but I have no explanation for it and it doesn't really sit well with me to just put code into my application that I can't explain.

[Tesla DeLorean]

Posted on September 09, 2011 at 06:52

It is specific to code booted in RAM, ie you put it there, and then reboot with appropriate BOOTx settings. It doesn't impact code in ROM or FLASH. People typically don't boot code from RAM in a production environment.

One could easily experiment with this, for example placing one piece of startup code at 0x200001E0, and the one pointed to by the reset vector, and seeing which gets executed.

[hazelnusse]

Posted on September 09, 2011 at 07:04

I realize that I can experiment with it, but that isn't what I'm after.  I'm trying to understand:

1)  Why isn't it documented anywhere?2)  Why would this entry in the vector table not exist in the startup scripts for IAR or ARM build systems?Experimenting with it won't answer these questions.  Perhaps somebody from ST knows the answer?

[Tesla DeLorean]

Posted on September 09, 2011 at 07:31

Don't know, it's one of those undocumented features that exist in many microprocessor systems. It's not mentioned in the errata. The coding addresses a specific behaviour of the STM32F1, lack of support in other tools chains simply means they won't generate working code for the RAM booting scenario. It's a highly atypical usage, the RAM is mainly used in this fashion under JTAG control.

[wrs]

Found this thread while searching for the mystery STM32F1 boot mechanism and thought I'd leave a breadcrumb for the next person. The mechanism is explained well in this Stack Overflow answer by Michael Slade.

The short version is that F1 parts in SRAM boot mode use a tiny built-in ROM as the reset vector. The reset PC in the ROM vector is an address just after the interrupt vector table, and is specific to the particular part. The mystery BootRAM instruction at that address is just a relative jump (LDR.W PC, [PC, #-xxx]) back to the "real" reset vector.

The part-specific addresses are as follows (according to Mr. Slade):

• Low/medium density: 0x0108 (value: 0xF108F85F)
• Low/medium density value line: 0x01CC (value: 0xF1CCF85F)
  Note: ST's sample files give the same value as for low/medium density parts. I'm pretty sure this is wrong and have corrected it here, but I don't have any parts of this type to test with. I'd appreciate feedback to confirm if this works.
• All others: 0x01E0 (value: 0xF1E0F85F)