KernelInitialize crash on STM32F4 platform on HEAD revision

[RobMeades]

Description

• Type: Bug
• Priority: Blocker

STM32F4 target UBLOX_C030_U201 fails to boot. I updated to HEAD revision of mbed-os today (last time was ~4 weeks ago) and now it doesn't get past KernelInitialize. I have a feeling this may not be isolated to my platform, this issue may be the same thing and, indeed, it might be true of any STM32F4 platform. I mention this because I'm the only one who has this specific platform at the moment.

There was initially an issue with the new mbed-os boot pattern trying to write interrupt vectors to flash, which I have fixed, but I'm completely stumped by this subsequent issue.

Here are some people who may be interested or may be able to help:

@0xc0170 , @adustm , @bulislaw , @andreaslarssonublox

Target
UBLOX_C030_U201

Toolchain:
GCC_ARM

Toolchain version:
5.2.1

mbed-cli version:
1.1.1

mbed-os sha:
f31ea01

Expected behavior
Platform boots.

Actual behavior
The last thing the platform does before hitting the exception handler is to execute the assembler instruction svc 0 in the service call to KernelInitialize in rtx_kernel.c, see debugger screenshots below.

Before:

After:

Steps to reproduce
Build anything for the platform and try to run it.

[0xc0170]

There was initially an issue with the new mbed-os boot pattern trying to write interrupt vectors to flash, which I have fixed, but I'm completely stumped by this subsequent issue.

How was this fixed?

Is this only for GCC ARM ?

I'll run some local test on F4. for instance we havent seen this yet. The latest bugfix was done for lwip on F429 nucleo board, the tests run - all green. I'll run some tests on odin board to confirm.

cc @bcostm @LMESTM @jeromecoutant

[0xc0170]

From the PR referenced:

@0xc0170, @bulislaw : Martin, Bartek, my STM32F4 platform (and, possibly, @andreaslarssonublox 's) are, I think, broken due to the change to "replace target defined NVIC_Set/GetVector with the CMSIS implementation". Without cmsis_nvic.c my vectors aren't getting copied into RAM and so the world falls apart. How is this meant to work in the new CMSIS world?

It is done in the mbed boot for any non cortex-m0, thus should be done for ours as well. for more details, look at the mbed_boot code file where the bootup sequence is described. SystemInit should not invoke rely or invoke interrupts

[RobMeades]

The fix for the vector table initialisation issue for my platform was to edit my system_stm32f4xx.c file and set:

#define VECT_TAB_SRAM

..then, further down in the same file, change:

#ifdef VECT_TAB_SRAM
  SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET;
#else
  SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET;
#endif

…to

#ifdef VECT_TAB_SRAM
  SCB->VTOR = NVIC_RAM_VECTOR_ADDRESS;
#else
  SCB->VTOR = FLASH_BASE;
#endif

I'm not sure about other toolchains, will test that. I have also tried an Odin board, which worked for me, so maybe the issue linked above is different and this is just a problem for me. I'd not realised that SVC == SWI, so I'll go find the vector table entry and see if it makes sense.

[RobMeades]

Ref. the vector table copying, agreed that mbed_cpy_nvic() is being called in mbed_boot.c and HAL_Init() is being called again but, when HAL_Init() is called the first time (from SystemInit() on all STM platforms), the attempt to set up the timer interrupt results in a write to flash. I understand that #4485 includes a fix for this in terms of the chip's flash write registers being mucked about but if you're trying to run under the debugger it also really doesn't like it, which makes things somewhat difficult to follow. Editing system_stm32f4xx.c as above makes the debugger behave nice and consistently so I can investigate this next problem.

[RobMeades]

Bugger. I think I see the problem. The change I made to system_stm32f4xx.c isn't going to fix things. The mbed_cpy_nvic() function copies vectors from SCB->VTOR into RAM, but I've just told it that SCB->VTOR is in RAM without actually copying the values there from ROM. What should the correct answer be?

[0xc0170]

I believe that VTOR shall be removed completely from the startup ? systeminit should avoid doing any interrupts ?

How does this startup sequcen work for instance for F429 ? I checked that Vtor line is not there.

[RobMeades]

I'll need to check on F429. I can confirm that if I change SystemInit() to include the following:

  /* Configure the Vector Table location add offset address ------------------*/
  SCB->VTOR = FLASH_BASE; /* Vector Table Relocation in Internal FLASH */

#ifdef VECT_TAB_SRAM
  int *vectors = (int *)SCB->VTOR;
  int *old_vectors = vectors;
  vectors = (int *)NVIC_RAM_VECTOR_ADDRESS;
  for (int i = 0; i < NVIC_NUM_VECTORS; i++) {
      vectors[i] = old_vectors[i];
  }
  SCB->VTOR = (uint32_t)NVIC_RAM_VECTOR_ADDRESS;
#endif

...then the board boots.

[RobMeades]

To update the thread, the call that results in an attempt to set an interrupt vector while the interrupt vector tables are still pointed to flash is HAL_InitTick() in hal_tick_32b.c:

We can't understand why this is not a problem for other STM32F4 platforms though. Can anyone from STM comment? @LMESTM @bcostm @jeromecoutant @adustm

[LMESTM]

@RobMeades @0xc0170 we've also reported issues in booting targets since the merge of #4294
This is tracked here #4459. I reported yesterday that there are still problems for F3 targets at least on HEAD revision.

I'haven't run a full check yet of all boards over mbed2 and mbed5, and I'm not sure on which revision I'd be supposed to do so as it requires time to do so and HEAD is moving fast.

Basically we need to have everything back at their working stage as was before #4294.
@0xc0170 : do you have more investigations ongoing to put everything back in a working state ? We're pretty disappointed by the way this PR was first merged.