Initialise RAM interrupt vector tables in SystemInit() for UBLOX_C030 platform #4539
Conversation
…erwise not done until *after* a call has already been made to NVIC_SetVector() in HAL_InitTick().
| SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */ | ||
| #else | ||
| SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */ | ||
| int *vectors = (int *)SCB->VTOR; |
There was a problem hiding this comment.
would this result in copying nvic 2x ? I replied the the issue. Why is HalInit part of SystemInit. Can it be delayed and what would be the implications. We are reviewing this currently
cc @c1728p9
There was a problem hiding this comment.
Well, I suppose it would mean that, but an extra copy step is worth it to have my platform boot and I can't see anything wrong with the platform initialising its interrupt vector table in SystemInit(). If there is a proper/tested answer I'm happy for this PR to be dropped; I'm happy to wait a few days for that answer to come about. If anyone wants working code for the UBLOX_C030 platform I will point them to my fix branch in the meantime.
|
#4543 should fix this problem |
|
@RobMeades Can you please test the referenced pull request above and confirm it works (close this) ? Thank you |
|
Confirmed, that works for me, I will close this PR. |
Following PR #4294 some platforms are failing to boot. The problem in the case of the
UBLOX_C030platform (an STM32F4 MCU) is thatHAL_InitTick()callsNVIC_SetVector()when the vectors have not yet been copied into RAM (this now happens later inmbed_cpy_nvic()). This results in a write to flash and, potentially, the timer interrupt could go off when the vector has not been initialised. The net result is that the platform does not boot.This change sets the RAM interrupt vectors up at start of day in
SystemInit()for theUBLOX_C030platform, allowing it to boot reliably. Without this change the platform is dead.Related: #4532, #4459.