Invalid check in jump_to_app() for STM32F7 when using ITCM

[DrTon]

There is check in jump_to_app() here:
https://github.com/PX4/Bootloader/blob/master/bl.c#L269

That checks if start address of outside of flash (<0x08008000 for FMUv5) and breaks jumping.
But when using ITCM on PX4FMUv5 with STM32F7 this address is at alias address 0x00208000.

Workaround is dirty hack in vector table (not PX4 firmware):

_vectors:
        .long       __main_stack_end__
        .long       Reset_Handler + 0x08000000 - 0x00200000  // <-- to pass check in PX4 bootloader

Not sure if it works 100% correct, but app starts (not PX4 firmware).

Probably that was a reason why ITCM is not used here?
https://github.com/PX4/Firmware/blob/master/boards/px4/fmu-v5/nuttx-config/scripts/ld.script#L121

[LorenzMeier]

@DrTon Thanks! @davids5 Could you have a brief look?

[dagar]

I'd be interested in this if we can find a way to use ITCM without requiring a breaking coordinated bootloader + firmware change.

Last year @davids5 and I briefly experimented with the accelerator (ART) on an fmu-v5. The only area I found it to make a noteworthy difference was with EKF2 where the it's executing an enormous amount of generated code (> 100KB).

Branches we used for testing if anyone is curious -
bd7616b
PX4/PX4-Autopilot@c74ecab

[DrTon]

@dagar, have you measured how much ITCM gives for EKF2 calculation?

About breaking change: do you have some user-friendly way for bootloader upgrade? I have done this before on PX4FMUv2: user flashes via USB special firmware that updates bootloader (important to not break this process :) ). Then new firmware can be loaded.

[dagar]

Yes, but not exhaustively. At the time it was somewhere between a 15-20% decrease in cpu usage for the EKF2 task. Given that EKF2 is already well under 10% of the total cpu on fmu-v5 it's not immediately that interesting, but I'd like to get to a point where we can run a matrix of estimators across the different sensors combinations.

We have a reasonably friendly bootloader upgrade option driven by a parameter now. https://github.com/PX4/Firmware/blob/1b8c2c82d50c8d91f1363f4cd2e1253fd0683f6f/boards/px4/fmu-v2/init/rc.board#L19-L35
Although I still think it's a bit risky for users.

[davids5]

IIRC we not have F7 bl_update so that needs to be on the list.

Here is a good reference

https://www.st.com/content/ccc/resource/technical/document/application_note/0e/53/06/68/ef/2f/4a/cd/DM00169764.pdf/files/DM00169764.pdf/jcr:content/translations/en.DM00169764.pdf

I think for simplicity and if it is possible we should consider keeping the bootloader the same. The fix the app entry to jump to the AIX address space with ART on.

[LorenzMeier]

Closing as stale.