STM32MP13XX Custom Bootloader issue

[Aerokii]

Hello! I'm attempting to build a custom bootloader for the STM32MP133C, heavily reliant upon the STM32MP13XX hal layer and then provided cmsis_core and cmsis_device_mp13 packages/pieces. 

I'm attempting this on IAR (company decision) which has added some wrinkles to this. I load the main application to the NAND flash using a custom flashloader, and then run the Bootloader code from sysram. Can't do both at the same time because IAR's flash loader uses the sysram.

The bootloader initializes the necessary items- the HAL, system clock, DDR, UART, Flash, Ethernet, etc. I have it blink an LED 5 times for fun, and then load the .bin file from flash into a specific offset in the DDR, where I'm hoping to run from. I then set a function pointer to the starting location of the main app, and run that function pointer. It looks pretty simple/straightforward, as shown below: 

GetApplicationDetails(flash); //loads from flash to DDR. 
void (*p_AppEntryPoint)(void);
//boot the full OS
p_AppEntryPoint = reinterpret_cast<void(*)(void)>(DDR_START+DDR_OFFSET); //0xC0000000 + 0xA838
p_AppEntryPoint();

However, the app isn't running. I should be seeing the telltale lights of flashing LEDs, but no such luck. Am I missing something obvious? I see some examples have to reset/configure the stack pointer, but others don't, so I don't know if there's something common to the typical STM32 linking that I'm missing. 

Thanks for your time/help!

[js214]

Some suggestions ...

In your screenshot you seem to be stopped just before the jump-off point. What happens if you single-step the core past that point?

Have you unsecured the peripherals you are using?

Are you sure the code you're executing doesn't reconfigure the DDR while running out of it?

If it helps, compare your code with my custom bootloader: https://github.com/js216/stm32mp135-bootloader

It would help diagnosing your issue if you posted the source code for the minimum (non-)working example of what you're trying to do.

[PatrickF]

Hi,

have you tried to look at and maybe reuse some example provided within STM32MP13Cube /Projects folder ?

There seems to be some ready made IAR projects examples.

https://wiki.st.com/stm32mpu/wiki/STM32CubeMP13_Package#Projects

https://wiki.st.com/stm32mpu/wiki/STM32CubeMP13_Package_release_note

Regards.

[Aerokii]

Stepping once seems to drop me into the vector table, as pictured in Step_Standard.jpg. 

The peripherals are indeed unsecured (that was a whole other journey), the code is not reconfiguring the DDR, and I'll absolutely take a look at the custom one you built, thank you! 

If the available posts don't resolve the issue, I'll come back with a pared down version of what's not working to post. 

Thanks so much!

[Aerokii]

Hello Patrick!

Indeed I have, they were my starting/jumping off point for this. In particular, I've been using FSLBA_Sdmmc1 as inspiration. I was not able to get that particular example to work, though- when reading what was written from the SD card, there was no sign of life after jumping to the provided example app.

[Aerokii]

Alright! So, I've tried modifying using some things from your custom bootloader. Alas, I didn't _quite_ have the luck I was hoping for, but it's been a learning experience I've appreciated, so thank you! 

I've linked the minimum non-working example as a .7z file. It exists as three projects- the flash loader, the bootloader, and then the app itself. Flash loading's still a work in progress, but it at least does write to flash, so what I've done so far is set up the bootloader to, when "app" is defined in the linker's input "Keep symbols" section, load up the output from the "app" project into flash. Debugging won't work from this mode, since IAR's flash loading uses up all the sysram and won't just load up the bootloader after it... so I'm doing some added work to fix that. 

Anyway! One the flash is loaded with app_header.bin (using STM32's typical header, added during the make of app.bin), I remove the "app" symbol from the linker input section and run the bootloader as normal. 

And that's... the long and short of it. Hopefully there's something obvious in there I'm missing, and as always- thanks for your help!

https://drive.google.com/file/d/14timto72E6c3dwDWaMwjQd5VNeSheATH/view?usp=drivesdk

[js214]

The .7z file contains 448,407 lines of C and 1,640,333 lines of assorted other stuff. Not what I had in mind as a *minimum* example! With that level of totally pointless complexity I'd strongly to advise you to create an actually minimal example, like my Blink program . Verify explicitly what the full linker script and startup code is.

General principle: if your "Blink app" contains precisely the same instructions as a "Blink function" in the bootloader, then it just has to work. But if the app you're trying to run does some sophisticated initialization, unknown-to-you startup assembly codes, etc., then the debugging will be very difficult.

[Aerokii · Accepted solution]

Ha! Fair enough. After testing some things out with your blink app I was able to compare that with some behavior I'd been seeing when trying to run my actual apps. 

The problem ended up being with a neglected section of code trying to re-initialize some timers that very much did not want to be re-initialized. With the help of writing a flash loader that writes directly to DDR as well as flash I was able to sus it out and make the necessary changes to get the bootloader bootloading. Thanks for your guidance and sharing your example code!