Skip to main content
GS1
Senior III
September 3, 2018
Solved

STM32H743: Is there a different handling for code entry points compared to STM32F4 / STM32F7

  • September 3, 2018
  • 3 replies
  • 1112 views

In all of my projects I have my own bootloader which is located at 0x8000000 and is specially designed to communicate with my own Windows universal Flasher-Tool.

My bootloader initializes necessary components for the needed communication ports (e.g. USB) and looks into a defined flash address (0x08020000) for a start address of the final application.

This is flashed by the bootloader after the final application has been loaded to the application sectors (0x08080000 in this case).

If a correct address is read, then the bootloader deactivates Interrupts, unitializes components and jumps to the start-address + 4.

This handling works perfectly on my multiple other projects with STM32F4 and STM32F7 processors.

Now with the STM32H7 this does not work. The system simply crashes after the jump to 0x8080000 + 4.

I took care that the interrupt vectors are linked to the correct offset, have set SCB->VTOR to the offset 0x80000 and when I compare the flash memory with the hex file, all looks as expected.

But it doesn't work after the jump. Now i am stuck.

Does anybody know what might be the reason that the jump does not work? Is there anything else, which has to be initialized additionally?

Here is my code snippet of the jump part:

 if (bApplVorh)

 {

    ARM_DisableAllInts();

    HAL_DeInit();

    __DI();      //  Interrupts sperren

    if (ulStartAppl == 0)   // ulStartAppl = 0x8080000

      ulStart = 0xFFFFFFFF;

    else               /* Test if user code is programmed starting from address "ulStartAppl" */

      ulStart = (*(__IO uint32_t*)ulStartAppl);

    if (ulStart != 0xFFFFFFFF)   // FlashROM not empty?

    {

       /* Jump to user application */

       JumpAddress = *(__IO uint32_t*) (ulStartAppl +4);

       Jump_To_Application = (pFunction)JumpAddress;

       /* Initialize user application's Stack Pointer */

       __set_MSP(*(__IO uint32_t*) ulStartAppl);

       Jump_To_Application();

    }

    // never returns to here !

 }

    This topic has been closed for replies.
    Best answer by GS1

    Thank you very much for your hints!

    Problem solved: I actually did not activate the Interrupts on the other side with __EI()... I was not aware that this is not done automatically in the startup procedures.

    And: The call to HAL_DeInit() is not necessary - it even blocks the jump to the other side.

    Now my system is working as expected. Thank you again for you help!

    3 replies

    GS1
    GS1Author
    Senior III
    September 3, 2018

    Besides: The final application has been working when located to 0x8000000 and loaded via ULINKPro to the board. So the final application is not faulty.

    Tesla DeLorean
    Guru
    September 4, 2018

    Do you enable the interrupts on the other side?

    Tried stepping through the transition and understanding where it is going?

    What values are getting loaded?

    SCB->VTOR would need to be 0x08080000 not 0x80000

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    GS1
    GS1AuthorBest answer
    Senior III
    September 4, 2018

    Thank you very much for your hints!

    Problem solved: I actually did not activate the Interrupts on the other side with __EI()... I was not aware that this is not done automatically in the startup procedures.

    And: The call to HAL_DeInit() is not necessary - it even blocks the jump to the other side.

    Now my system is working as expected. Thank you again for you help!