Cortex M0 Vector relocation issue

[stenasc]

Posted on February 07, 2014 at 00:42

Hi,

I'm trying to implement IAP on an stm32f051 device, but get a linker error when specifing VectorTable address is 0x20000000. __IO uint32_t VectorTable[48] __attribute__((at(0x20000000))); STM32F0-Discovery_Demo.axf: Error: L6985E: Unable to automatically place AT section main.o(.ARM.__AT_0x20000000) with required base address 0x20000000. Please manually place in the scatter file using the --no_autoat option.  The program compiles and links when I don't mention a particular address __IO uint32_t VectorTable[48];   Program Size: Code=46848 RO-data=2976 RW-data=1312 ZI-data=6712  and I can see it in the map file.. VectorTable          0x200011e4   Data I know I don't have a lot of RAM so is this the issue? If I could get a workaround without using the scatter file (never used it before), that would be good as well. Hopefully someone can give me a few pointers. Regards Bob

[Tesla DeLorean]

Posted on February 07, 2014 at 03:29

There are several ways of doing this, if you just want a pointer to it, then

uint32_t *VectorTable = (uint32_t *)0x20000000; // VectorTable the ''variable'' will be situated some place else, it points where you want // VectorTable[0] = SP // VectorTable[1] = PC, Reset_Handler Then in the Target dialog carve out the vector space from the IRAM allocation so it's not used for general storage. I would generally play games with the startup.s and scatter file (linker script in GNU/GCC) rather than use the AT directive.

[stenasc]

Posted on February 07, 2014 at 09:53

Cheers Clive,

I will use pointers and see how I get on. I also want to backup the existing app in external flash so if IAP fails I can revert back to the old build. At what address does the current binary live. Is it 0x80000000? Bob

[stenasc]

Posted on February 07, 2014 at 19:51

I tried the following but now the board doesn't boot.

Map file shows... VectorTable                              0x20000050   Data           4  main.o(.data) If I comment it out, board boots. uint32_t *VectorTable = (uint32_t *)0x20000000;         VectorTable = (uint32_t *)malloc(48 * sizeof (*VectorTable));                          //   Copy the vector table from the Flash (mapped at the base of the application         //   load address 0x08003000) to the base address of the SRAM at 0x20000000.         for(i = 0; i < 48; i++)            {             *(VectorTable+(i<<2)) = *(__IO uint32_t*)(0x08003000 + (i<<2));              }         //  Enable the SYSCFG peripheral clock         RCC_APB2PeriphResetCmd(RCC_APB2Periph_SYSCFG, ENABLE);         //   Remap SRAM at 0x00000000         SYSCFG_MemoryRemapConfig(SYSCFG_MemoryRemap_SRAM); Later on I deallocate the VectorTable Memory . Any ideas Bob

[Tesla DeLorean]

Posted on February 07, 2014 at 19:59

The boot loader would typically be placed at 0x08000000, and the app above that, perhaps at 0x08003000 or something.

You're malloc'ing this why?The Vector table is placed at a very specific reason so when you remap RAM at ZERO the table placed at 0x20000000 becomes the table used by the processor. The M0 processor can't change the address like the M3/M4 can.

[Tesla DeLorean]

Posted on February 07, 2014 at 20:01

uint32_t *VectorTable = (uint32_t *)0x20000000;
// Copy the vector table from the Flash (mapped at the base of the application
// load address 0x08003000) to the base address of the SRAM at 0x20000000.
for(i = 0; i < 48; i++)
VectorTable[i] = *(__IO uint32_t*)(0x08003000 + (i<<2)); 
// Enable the SYSCFG peripheral clock
RCC_APB2PeriphResetCmd(RCC_APB2Periph_SYSCFG, ENABLE); 
// Remap SRAM at 0x00000000
SYSCFG_MemoryRemapConfig(SYSCFG_MemoryRemap_SRAM);

You should define the IRAM for your projects (loader, app) to start at 0x200000C0, of length 0x1F40 (for 8KB part)

[stenasc]

Posted on February 09, 2014 at 00:33

Hi Clive,

Yes, regarding malloc...you are correct, you don't want that memory space to be dynamic..point taken. Here's another thing....my current app size is 47012 bytes running from flash. If my new image is roughly the same, I won't have enough space in flash for both current and new images. Is this correct. Am I fighting a losing battle right from the start? Am I correct in thinking that both cuurent and new images should be less than 32K for this to work? Bob

[Tesla DeLorean]

Posted on February 09, 2014 at 00:55

Yes, well that and the image likely has a bunch of hard coded addresses in the vector table that won't work too well if placed in a different area of FLASH.

The trick with updating would be have somewhere to stage a new complete version, be it a different area of FLASH, or on some external storage like an SD card. The usual technique would be to split the image into two pieces, a boot loader, and an application. The boot loader is relatively small and allows for the updating of the application, and validating the existing image before jumping to it. The M0 is a bit confining, it's stripped down to appeal to the 8-bit market, a larger more effective part however is more expensive.

[stenasc]

Posted on February 10, 2014 at 09:41

Hi Clive,

What I plan to do is combine the current app with the bootloader, (have the bootloader placed after the app near the bottom of micro flash). I've done this with a previous processor. e.g. current app at 0x80000000 and bootloader at 0x8000F000 For this I'll integrate the binaries. I have a script somewhere that does this. The main app should download the new updated app into external flash, verify checksum and if correct jump to the bootloader to overwrite the current app at 0x80000000 with the new one. Thats the plan anyway. Do you think it is feasible or can you forsee any issues. Bob

[roberto]

Posted on November 27, 2014 at 11:08

Only to say thank you. Your code works flawless!

Roberto