2018-04-09 05:54 AM
I am trying to develop a custom bootloader, using tutorials and examples from everywhere.
Currently I am developing the 'App' which is located in a Flash region different from the Bootloader region, so I am forced to push my App program code forward in a different flash position than 0x8000000 (initial flash position).
I am using this
to create the code of my app in ahttp://www.st.com/en/evaluation-tools/b-l475e-iot01a.html
evaluation board. So, I started creating the project structure using STM32CubeMX 4.25.0. Then, I changed:♯ Set flash parallelism mode to 32, 16, or 8 bit when using STM32 F2/F4 microcontrollers
♯ 2=32 bit, 1=16 bit and 0=8 bit parallelism mode
monitor flash set_parallelism_mode 2
♯ Load the program executable
load
♯ Reconfigure vector table offset register to match the application location
set *0xe000ed08 = 0x800C000
♯ Get the application stack pointer (First entry in the application vector table)
set $sp = *(unsigned int*)0x800C000
♯ Get the application entry point (Second entry in the application vector table)
set $pc = *(unsigned int*)0x800C004
♯ Enable Debug connection in low power modes (DBGMCU->CR)
set *0xE0042004 = (*0xE0042004) | 0x7
♯ Set a breakpoint at main().
tbreak main
♯ Run to the breakpoint.
continue
In the main.c file, I added a toggle led routine using systicks inside the infinite loop.
The main problem I have with my implementation is that SysTick_Handler() is never called, so systicks counter is never increased.
From 0x08000000 to
0x0800C000 in Flash memory, there is nothing (0xFF according to
http://www.st.com/en/development-tools/stm32cubeprog.html
). My code starts in 0x0800C000, where is the vector table.After doing research, I noticed that if I write the booloader code in the section
0x08000000 to
0x0800C000, the app code and systicks work. So, it means my app code is using the vector table of the bootloader (at 0x00000000 position). But if I erase those flash sectors again, my app don't work correctly.
In other forums and discussions, it is said that it is only necessary to change the STM32L475VG_FLASH.ld file and VECT_TAB_OFFSET constant. So, what am I missing?
According to
https://community.st.com/0D50X00009XkfHiSAJ
, I should disable IRQ. But I can't do it because the code comes from Reset conditions.I have attached my Atollic Truestudio project too for better feedback.
I am not using the booloader to jump to my program code. I am just using the Atollic Studio debugger (as the tutorials says) to jump to the starting flash position.
Thank you very much.
#bootloader2018-04-09 06:12 AM
Make sure SystemInit() is being called, and the address in SCB->VTOR when the SystemTick interrupt is enabled.
Check that the SysTick_Handler() is linked properly, and have a HardFault_Handler() that outputs failure data if it ends up there.
2018-04-09 08:34 AM
Make sure SystemInit() is being called
Yes, it is called. I put a breakpoint inside it.
the address in SCB->VTOR when the SystemTick interrupt is enabled
Systicks are configured inside 'SystemClock_Config' funcion in main.c.
STM32CubeMX uses HAL_SYSTICK_Config(), HAL_SYSTICK_CLKSourceConfig() and HAL_NVIC_SetPriority(). Before and after these functions, SCB-VTOR equals 0x0800C000.
Check that the SysTick_Handler() is linked properly
Systick_Handler is properly asigned in 'startup_stm32l475xx.s', inside 'g_pfnVectors:' section. NOTE: I have never modified
'startup_stm32l475xx.s' and it has been completely created by STM32CubeMX.
have a HardFault_Handler() that outputs failure data if it ends up there
Done. But it is not called because systick irq don't work.
2018-04-09 08:44 AM
I'd probably try programming the first two vectors from 0x0800C000 at 0x08000000.
Running from the debugger in this fashion might be the issue here. Do any other interrupts work properly?
2018-04-09 09:35 AM
Do any other interrupts work properly?
My bootloader only activates Systicks and Uart interrupts. So, I tried to use Exti and I2c interrupts in my app. None of them works when I install both bootloader and app, althought uart and systicks do work.
I guess the app code is using the vector table of the bootloader (in 0x0000000 position), so anything is not being used in bootloader is going to fail.
On the other hand, the same app code
withoutthe FLASH offset works perfectly, as usual. So, the problem is not related to my implementation.I'd probably try programming the first two vectors from 0x0800C000 at 0x08000000.
What do you mean? How can I do this?
2018-10-15 07:24 PM
It may already be settled.
Since the value set for address 0xe000ed08 is an offset value, I think it is correct to set "set *0xe000ed08 = 0xC000".
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Ciheijba.html
2018-10-15 11:32 PM
Only in a situation where memory is shadowed at zero, in most cases the safe thing to do is to provide the absolute 32-bit address of the vector table as the processor takes the high order bits to compose a load as directed by the NVIC.