STM32F103 Bootloader Branching Troubles

[benjamin2399]

Posted on March 25, 2015 at 02:45

I've read just about all the existing posts regarding jumping from one code section to another and still I cannot jump without triggering a hard fault.

I'm adhering to advice given such as always jump to an address with least significant bit set, disabling interrupts, setting SP etc.. So my main code supports firmware update (32K file) via USB-MSC. All the complicated routines have been completed, checksums, writing the data to flash (0x08010000) and I've stepped through the debugger and can confirm the data is where it should be. I've written code (with no dependencies on addresses - it should work in RAM or Flash at any location) I copy the code to either RAM or Flash, again confirmed it is there (exact word by word replica as seen in the memory windows) but when I jump (BX R0) to the fixed address I always end up triggering a hard fault. I can 'BX R0' to the original code in the flash (approx 0x0800409D) and it executes without a problem. I just cant jump to 0x08018000 (or 0x08010001) to execute the erase and flash-write code. I'll post my code here if there is nothing obvious that I'm missing. I am assuming 0x08018001 is not in-valid for somereason? Do I need to lock the flash before executing from it? I've also noticed other branches in my code will branch to an even address without issue (Keil assembled code) So I'm not sure how strict the requirement to branch to an odd address is in the STM32F103... Any insight would be appreciated Thanks, Ben #jump-bootloader-branch-bx-r0

[Tesla DeLorean]

Posted on March 25, 2015 at 03:52

But what exactly are you putting at 0x08010000? If it's the vector table for your code, then it's not executable, it's a table of vectors, the first one pointing at a stack address, and the second one at the REAL entry point.

Show the data at 0x08010000, or attach a .HEX and .MAP for it.

[benjamin2399]

Posted on March 25, 2015 at 05:17

Hi Clive1,

The data stored at 0x08010000 is written from a binary file sent to the device via USB (though a custom bootloader - which is not the problem). As a test, I am writing a copy of the binary written to 0x08000000. The data is there, confirmed by st-link tool and through debugging. The data I am trying to jump to resides at 0x0801800 which is a copy of a routine that resides around 0x0800409D. This routine erases sectors 0-64 and copies the flash from 0x08010000 to 0x08000000. I know this code works when executed at 0x0800409D though I cannot jump to and execute it when it is placed at 0x08018000. I'll attach the code shortly. So you think it is a problem with the address of the first half-word?

[Tesla DeLorean]

Posted on March 25, 2015 at 05:34

I've got no magic insight into what you've actually done.

Copying code that runs in one location might not work if it calls other code, that didn't get moved too. What does the Hard Fault Handler tell you about the location and nature of the fault?

[benjamin2399]

Posted on March 25, 2015 at 09:06Hi Clive1,All fixed! As you had wrote in another post the address to jump does indeed have the least significant bit set. I was getting the labels' address (which too was offset +1 byte) as the source address for the transfer. This was 1 byte too late. Masking the label address with 0xFFFFFFFE fixed my problem.Thanks for your time!