Moving the start address to 0x8005000 (or 0x8002000)

Development of new Cores using the STMCubeMX and HAL
Post Reply
User avatar
RogerClark
Posts: 7171
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Moving the start address to 0x8005000 (or 0x8002000)

Post by RogerClark » Sat Sep 12, 2015 5:01 pm

Just a quick update.

I have been trying to see if I can change the start address from 0x800000 to 0x8005000 for bootloader operation.

So far I've not had any success, by adding

-DVECT_TAB_OFFSET=0x5000

to the build common flags, and also wrapping the code in the CMSIS that normally defines this as 0x00, in #ifdef's

I think I'm going to need to go back to first principals again, and confirm that Blink does work normally using my Maple mini (on HAL MX), and then try moving the start address and upload an run using STLink.

Of course I may have missed something else I need to change to move the start address

PS. I also changed the linker file

MEMORY
{
FLASH (rx) : ORIGIN = 0x8005000, LENGTH = 128K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K
}


Can anyone tell me if I have missed something that I need to change to run from 0x8005000 ?

eck
Posts: 1
Joined: Sat May 16, 2015 2:18 pm

Re: Moving the start address to 0x8005000 (or 0x8002000)

Post by eck » Sun Sep 27, 2015 5:32 am

Which bootloader did you use? I managed to get this to work when testing the generic bootloader. I used an own small test program where I just redefined the start address in the linker script to 0x80005000, no other changes needed. But I remember I did need to change the bootloader to relocate the IRQ vector table. I think it was as simple as SCB->VTOR = 0x80005000.

User avatar
RogerClark
Posts: 7171
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Moving the start address to 0x8005000 (or 0x8002000)

Post by RogerClark » Sun Sep 27, 2015 5:50 am

I was using a maple mini, and I think it still has the old / original Maple bootloader, which has the sketch code start address of 0x8005000.

But I have not tested the maple mini via STLink, so I dont know if the problem is the start address or just that the core for the maple mini does not work at all

victor_pv
Posts: 1681
Joined: Mon Apr 27, 2015 12:12 pm

Re: Moving the start address to 0x8005000 (or 0x8002000)

Post by victor_pv » Sun Sep 27, 2015 4:09 pm

I think I may be missing something, I don't completely understand what you are trying.
Are you trying to get the bootloader to run from 0x8005000, so to have something else in 8000000 to 8004FFF?

What exactly do you want to have in that block if I may ask?

User avatar
RogerClark
Posts: 7171
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Moving the start address to 0x8005000 (or 0x8002000)

Post by RogerClark » Mon Sep 28, 2015 6:23 pm

Hi Victor

I was trying to use the HALMX generic F103C core (aka maple mini core, I think) on an existing Maple mini with the bootloader

But to get the HALMX core code to run i had to make a new variant of the HALMX that has the linker script changed so that the code address starts at 0x8005000 (I'm using the old bootloader on the board I'm testing with .... but it doesnt make any difference to this problem).

And also I have to change the vector table offset, to 0x8005000
And I had to update the HALMX core tools to include the "maple-upload" files i.e the scripts (and dfu-util on the pc).

Anyway, I made the linker and vector table changes, put the maple mini bootloader into perpetual mode, uploaded via DFU.

But blink didnt flash the LED.

I know that I should really test the maple mini without the bootloader by uploading using STLink but I've not had time to do this yet.

jcw
Posts: 171
Joined: Mon Oct 26, 2015 8:16 am

Re: Moving the start address to 0x8005000 (or 0x8002000)

Post by jcw » Wed Oct 28, 2015 1:27 pm

FLASH (rx) : ORIGIN = 0x8005000, LENGTH = 128K
Not sure this is still relevant, but that should be 120K iso 128K.

User avatar
RogerClark
Posts: 7171
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Moving the start address to 0x8005000 (or 0x8002000)

Post by RogerClark » Wed Oct 28, 2015 7:30 pm

Thanks @jcw

Its something I was looking at a month ago, but is on hold at the moment because I have too many bug fixes etc and other new features to deal with.

Hopefully I can get back to looking it it when I have more time.

i agree it should be 120k if the base address is not 0x800000 but this would not be the cause of the problem ( of it not even running Blink )

BTW. Some flash size definitions in linker scripts are deliberately wrong.

Its because we cant switch linker file on data from more than one IDE menu setting.
So for boards the generic boards, the linker script is set at the flash size of the highest size of the set of boards.

Its not a big problem as the IDE checks if the sketch will fit, so we dont need the linker to check as well.

If we every split the boards up into a more granular arrangement we may be able to do it correctly, but at the moment I could not find a way to dynamically pass the flash size into a gcc linker script as it didnt seem to be supported by gcc.

You can pass some vars into a linker script, but AFIK, not the flash size :-(

jcw
Posts: 171
Joined: Mon Oct 26, 2015 8:16 am

Re: Moving the start address to 0x8005000 (or 0x8002000)

Post by jcw » Wed Oct 28, 2015 7:34 pm

Too high a value can be a problem if the linker script places the stack at the top of RAM downwards.
Dunno whether the ones in this context do.

User avatar
RogerClark
Posts: 7171
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Moving the start address to 0x8005000 (or 0x8002000)

Post by RogerClark » Wed Oct 28, 2015 7:38 pm

ummm

its just the flash that is set to high, and we have not had an issue so far.

Generally within a series of boards e.. STM32f103C all MCUs have the same amount of ram, just different amounts of flash

jcw
Posts: 171
Joined: Mon Oct 26, 2015 8:16 am

Re: Moving the start address to 0x8005000 (or 0x8002000)

Post by jcw » Wed Oct 28, 2015 8:04 pm

Aww, right. Flash, not RAM. Ok, ignore me :)

Post Reply