Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bootloader jump to application #1653

Merged
merged 2 commits into from
Feb 14, 2022

Conversation

ABOSTM
Copy link
Contributor

@ABOSTM ABOSTM commented Feb 10, 2022

Summary
After UART Bootloader to jump to application, 2 issues prevent application to run properly:

  • Bootloader changes VTOR register and did not restore it when jumping to application
    It is necessary that application set VTOR unconditionally

  • Bootloader set PLL as SystemClock and keep it when jumping to application
    This prevent any further configuration of the PLL.
    It is necessary change SystemClock source, for example revert to default SystemClock (HSI or MSI) before any further PLL configuration.

Fixes #1637

When USART Bootloader jumps to application,
PLL is used as System Clock. It prevents to reconfigure PLL.
It is necessary to switch back to default Clock (reset value)
before any further PLL configuration.

Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
system/STM32WLxx/system_stm32wlxx.c Outdated Show resolved Hide resolved
STM32 core based on ST HAL automation moved this from In progress to Needs review Feb 10, 2022
@olikraus
Copy link
Contributor

To me it looks like many system_xxx.c files are changed. Wouldn't it be better to set "-DUSER_VECT_TAB_ADDRESS" once in the plattform.txt file, for example here:

compiler.extra_flags=-mcpu={build.mcu} {build.flags.fp} -DUSE_FULL_LL_DRIVER -mthumb "@{build.opt.path}"

I see that the PLL is also changed, so I guess that additional change for the VTOR doesn't matter than and the plattform.txt change is not required.

Anyhow, thanks for adding this. It will simplify work for USART users :-)

@fpistm
Copy link
Member

fpistm commented Feb 11, 2022

To me it looks like many system_xxx.c files are changed. Wouldn't it be better to set "-DUSER_VECT_TAB_ADDRESS" once in the plattform.txt file, for example here:

compiler.extra_flags=-mcpu={build.mcu} {build.flags.fp} -DUSE_FULL_LL_DRIVER -mthumb "@{build.opt.path}"

In fact, this was change by the STM32CubeFW to introduce the USER_VECT_TAB_ADDRESS and we simply aligned it but it brought a side effect with some BL modes. So easiest way is to remove it as it has no benefit.
Same for the clock reset config, before the system_init provided it but was removed.
Crosscheck with BL team brought us to simply restore VTOR and clock by default.

@ABOSTM ABOSTM force-pushed the BOOTLOADER_JUMP_TO_APPLICATION branch from fedacdb to 0152f37 Compare February 11, 2022 09:06
@ABOSTM
Copy link
Contributor Author

ABOSTM commented Feb 11, 2022

I see that the PLL is also changed, so I guess that additional change for the VTOR doesn't matter than and the plattform.txt change is not required.

Both changes are required to guarantee proper application run, after UART Bootloader.

When USART Bootloader jumps to application,
it doesn't restore VTOR (Bootloader Vector Table is used).
It is thus necessary to configure it unconditionally.
By the way get ride of USER_VECT_TAB_ADDRESS

Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
@ABOSTM ABOSTM force-pushed the BOOTLOADER_JUMP_TO_APPLICATION branch from 0152f37 to 0288818 Compare February 11, 2022 17:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

Generic Board STM32G031J6, issues with starting the downloaded code (pinMode hangs)
3 participants