STM32F030 Vector Table Relocation Problem

[mike239955]

Posted on July 18, 2014 at 16:39

Have used sample code provided by forum-master, Clive, to relocate my application's vector table to 0x20000000 (base of RAM) in preparation for use with a bootloader.  I also referred to app note AN4065 and the associated sample code.

When I run the code with this relocation, my interrupts all act erratically (in particular, EXTIs appear to trigger from unrelated events).  Power-cycling the prototype results in inconsistent behaviour from one power-up to the next. The sample code with AN4065 is extremely simple and my application is using a whole bunch of interrupts. Exact code without vtable relocation executes flawlessly.  It's as though RAM is ''lost.''  What am I NOT doing that I should be doing? Thanks for any insight. MDupont #bootloader-vector-relocate

[Tesla DeLorean]

Posted on July 18, 2014 at 17:11

By default the base of FLASH is mapped/shadowed at zero, obviating the need to move or relocate the table.

The table needs to be moved if you have multiple images within your FLASH, say one as a boot loader, and another deeper in for the application code. The trick there is to copy the table to the base of RAM, and then map that at zero. If you get erratic behaviour from a table copied to RAM there are a couple of things to consider. Have you carved out space in RAM allocation, and has that been expressed to the linker via  the GUI, scatter file, or linker script? Do you have code that might be overwriting the table, either via a heap or stack collision, or errant pointers? Another caution as you apply the technique between different processors is to make sure the table is of adequate size to hold all the vectors supported by a particular part.

[mike239955]

Posted on July 18, 2014 at 17:39

Clive,

Thanks for the insight.  I used one of your earlier posts as reference.  I believe (...) I have covered those bases but will double check. Here is further info: It looks as thought the Pending Register (PR) in the EXTI register is confused in the scenario where I have used the steps to cause RAM to appear at address 0x00000000. In my system I have interrupts occurring on the following EXTI lines (under normal circumstances): Line_4 (mapped to PC4) // fires regularly from an external ADC Line_5 (mapped to PF5) // external signal used as sort of a ''chip select'' Line_8 (mapped to PC8)  // Fires with switch closure Line_9 (mapped to PC9)  // Fires with switch closure Line_12 (mapped to PB12)  // Fires with switch closure Line_13 (mapped to PB13)  // Fires with switch closure With FLASH assigned to appear at 0x00000000, the above all works. Rebuilding and using the reassignment of RAM to 0x00000000: I am expecting a regularly occurring interrupt on Line_4 (PC4) and it's showing up on Line_13 (PB13) so the system thinks it's constantly getting hit with a switch closure. Also, none of the other interrupts fires. Thanks for your help on this,MDupont

[Tesla DeLorean]

Posted on July 18, 2014 at 17:47

I'd start by looking at the .MAP file to make sure the vectors gets to 0x20000000

In the debugger make sure after the table copy that what you see at 0x08000000 is mirrored at 0x20000000 and subsequently at 0x00000000 after it is remapped.

[mike239955]

Posted on July 18, 2014 at 22:41

I followed your advice and checked the above.  The RAM, FLASH and space pointed to by 0x00000000 are identical.

What I have found, though, is that in the debugger, when I reassign RAM to be at 0x00000000, the SYSCFG register appears to be completely cleared.  When I do memory inspection using the raw address for SYSCFG (0x4001 0000), it appears to be blank. If this is really happening, it is a hint as to what is happening. Does this make sense? Michael.

[mike239955]

Posted on July 18, 2014 at 23:39

Clive,

Did the following:         RCC_APB2PeriphResetCmd(RCC_APB2Periph_SYSCFG, ENABLE);         RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);         RCC_APB2PeriphResetCmd(RCC_APB2Periph_SYSCFG, DISABLE);         /* Remap SRAM at 0x00000000 */         SYSCFG_MemoryRemapConfig(SYSCFG_MemoryRemap_SRAM); ...and miraculously, it works.  I don't know if this is correct or an idiosyncrasy of the STM32F030...but there we go. Thanks, Michael.

[Tesla DeLorean]

Posted on July 18, 2014 at 23:45

/* Enable the SYSCFG peripheral clock*/
RCC_APB2PeriphResetCmd(RCC_APB2Periph_SYSCFG, ENABLE);
/* Remap SRAM at 0x00000000 */
SYSCFG_MemoryRemapConfig(SYSCFG_MemoryRemap_SRAM);

[mike239955]

Posted on July 19, 2014 at 00:04

Further info:

I just bootloaded a whole bunch of STM32F030s and the target code all works. It appears that following the:         RCC_APB2PeriphResetCmd(RCC_APB2Periph_SYSCFG, ENABLE); I needed to do a:         RCC_APB2PeriphResetCmd(RCC_APB2Periph_SYSCFG, DISABLE); in the end. The example ST code for the AN4065 app note does not make use of any significant interrupt stuff so this little detail would be missed. Then again, if I'm wrong in my assessment, I'd love to hear where I'm off in the weeds. Thanks for your insight.  It drove me in the right direction. Michael.

[Tesla DeLorean]

Posted on September 26, 2014 at 16:31

Yeah, sorry that was a cut-n-paste out of ST's IAP example, and reset the peripheral rather than enabled the clock

/* Enable the SYSCFG peripheral clock*/
RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);

/* Remap SRAM at 0x00000000 */
SYSCFG_MemoryRemapConfig(SYSCFG_MemoryRemap_SRAM);

ST might want to fix that also...