STM32F303VCT - Code hangs on sysTick IRQ enable

[jlag]

STM32F303VCT

STM32CubeIDE 1.14.1

Simple program generation with IDE, main() while loop user code that toggles a GPIO.

System hangs during HAL_Init() for the sysTick vector in: 

void HAL_NVIC_EnableIRQ(IRQn_Type IRQn)
{
/* Check the parameters */
assert_param(IS_NVIC_DEVICE_IRQ(IRQn));

/* Enable interrupt */
NVIC_EnableIRQ(IRQn);
}

Break the debugger and we are at an invalid address: 0x1FFFEf06.

I am assuming there is something wrong with either the vector table location and/or the NVIC configuration, but the vector table at 0x08000000 and code/flash are identical to the code that runs on Discovery board.

Both are using SWD. Discovery board is loaded/debugged via ST_LINK USB, custom board is loaded/debugged via STLINK-V3MINIE, USB to SWD.

I have been through many threads regarding user vector table locations, offsets, etc but none have seemed to help. All looks good.

Is there something that the ST-LINK on the Discovery board is doing during load/boot that the V3MINI isn't that could be affecting interrupt configuration?

 

 

[waclawek.jan]

Connect BOOT0 pin to 0V.

JW

[jlag]

Thanks JW, it is grounded via 10K Ohms though.

[TDK]

Sounds like the vector table isn't set correctly.

Uncomment the line that defines USER_VECT_TAB_ADDRESS in system_*.c. Verify with SCB->VTOR value.

[jlag]

@TDK, thank you for suggesting this. I had tried USER_VECT_TAB_ADDRESS yesterday and had no success. This was a previous issue where uwTick was not being incremented as the ISR for its update was never called (assuming related vector table/NVIC config issue). 
Since then, I am running a simple project, opposed to the full application I was running yesterday.

But alas, uncommenting USER_VECT_TAB_ADDRESS has allowed the simple application to run, VTOR is 0x0800 0000 and Tick increment is working as expected.

I will try the USER_VECT_TAB_ADDRESS once again in the full application on the custom board now, and verify it works there as well.

-JL 

 

[TDK]

What value is in SCB->VTOR?

When your code is "stuck", look at VECTACTIVE field within SCB->ICSR to determine which interrupt it's in. Likely it's in SysTick (VECTACTIVE=15) and likely it's in the wrong place due to a bad vector table.

You can view these values in the SFRs window during debugging.

Show screenshots if you can. It helps to see what you're looking at exactly. Sometimes simple things to fix can be lost in translation.

[waclawek.jan]

@TDK , how can the non-running case be explained here?

Under default circumstances, VTOR does not need to be changed from is default. Obviously, here, the System memory is mapped at address 0. If BOOT0 is grounded, and there are no option bits to boot into System memory, then how does this happen? Does Cube have some settings under which it changes the mapping, maybe unbeknownst to the user?

I'm asking as these questions come up quite often, although usually it's a Pattern6 or similar "empty FLASH boots" model, where the explanation is sort of easy, but here?

JW

 

[TDK]

@waclawek.jan On reset, VTOR=0 as you said. The application starts running (BOOT0 is low), but the application doesn't update VTOR by default due to some absolutely inane decision by someone on the CubeMX team. When SysTick is activated, it jumps to the offset in system memory rather than the one that should be specified in flash if VTOR was correctly set to 0x08000000.

The code starts running here, since the problem occurs only after enabling NVIC_EnableIRQ.

[waclawek.jan]

@TDK,

> The application starts running (BOOT0 is low),

Yes, but that also means, that User FLASH is mapped (aliased) at 0, so there's no need to change VTOR.

@jlag,

Can you please revert temporarily to the failing state, and then read out content of address 0x0000'0000 and compare it with content of address 0x1FFF'D800? Also, can you please read out and post content of SYSCFG_CFGR1 (because of its MEM_MODE field)?

Thanks,

JW

[TDK]

(Didn't fully read your reply before which explains that VTOR shouldn't need changed. Apologies.)

Hmm, maybe your understanding is a little better than mine. It would be good to get to the bottom of it since it really is a recurring theme and trips up new users before they even have a chance at understanding what's going on.

Still seems like VTOR isn't pointing to the right place. Maybe the debugger "helpfully" does something non-standard that trips things up. User is debugging, so it's definitely not a fresh start from reset.

[waclawek.jan]

> Hmm, maybe your understanding is a little better than mine. 

Obviously not, otherwise I wouldn't be asking.

Problem is, I never came across such a problem, so don't have any first-hand experience/insight. But of course it may happen to me in the future, too, and I would like to be prepared to that occasion. That's why I'm pestering here.

> Maybe the debugger "helpfully" does something non-standard that trips things up.

Yes, that sounds much like a factor.

> Still seems like VTOR isn't pointing to the right place.

Yes, so I'd add to my request above, in the failed state, to read out also VTOR.

JW

[waclawek.jan]

Here's the solution.

So it was the classic case of BOOT0 being not even floating but held actively high, inadvertently;  and, as @TDK said above, most likely the debugger/IDE added to the confusion to run the application (i.e. what's in FLASH at 0x0800'0000) forcibly(**), regardless of state of the address 0 remap. That resulted in the application failing at the first interrupt, where it picks the interrupt vector from bootloader's table at 0, and in turn gets lost in bootloader's code (in fact, there's no "guarantee" for instant failure - newer bootloaders are Cube-based so they do have e.g. systick interrupt implemented, except that it increments "some" address in memory instead of application's 1ms counter). And then changing VTOR effectively masks this case indeed. As long as the debugger provides that "merciful" startup.

So the real test for this situation would be, try without debugger. Here, that test was successful in that it lead to recognizing the real root of the problem (*).

But most of the cases I've seen is related to the "empty FLASH" mechanism (AN2606 Pattern 6 and similar), which is resolved by a power cycle. Most users would not remove the debugger live, so they would introduce the power cycle without realizing it, thus the problem "goes away" and they wave the whole incident as a fluke.

(*) This case is also a prime example of why the "source code" (here, schematics) should never be trusted, because there's a long path between the source and real life, and many things can go wrong at that path. That's why it's not enough to look at the schematics and at the source code, but it is necessary to measure directly at the pin (plus make sure the pin is properly soldered, yes, even with professional board makers - especially with prototypes, it is always a new set of circumstances and things can go wrong in subtle ways at that stage, too) and it is necessary to read out and check the registers content.

What I personally learned here is, always instruct the OP to measure directly at the pin. In most cases they will ignore it just like they ignore my adage to read out the registers, but maybe there's a fraction of them who will.

JW

[TDK]

Well that explains why I was unable to replicate this.

I did learn something:

On the STM32H723, the reset value for SCB->VTOR is 0x08000000. Directly after reset, that is what it's set to. I can't find any documentation which states this. Cortex M7 documentation doesn't specify this value, presumably it's up to the implementation. Might give some justification for ST's decision to not set the value on startup. (It's still a bad decision, regardless.)

On the STM32F4xx, whatever chip I was using, the reset value for SCB->VTOR is 0

[kmoravec]

I was working for a week on this one. This post solved the issue for me.

I actually got down to starting a new project with only 4 output pins. It would still only go so far before it hung. I felt it was an interrupt, but only had the defaults, none of my own. Certainly ST Code should work out of the box, shouldn't it?

It looks like the answer is no. I took your advice here and uncommented #define USER_VECT_TAB_ADDRESS in system_stm32l4xx.c and my program is not stopping anymore.

Kudos to you. Yet another time you helped me out.

[waclawek.jan]

Hi @kmoravec ,

Actually, the corollary of this thread is, that BOOT0 pin needs to be grounded.

Can you please check, by measuring directly on BOOT0 pin, that it is grounded?

Can you please try to run your program without debugger?

Can you please check that you haven't set bootloader entry through the Option bytes?

In 'L4, there's an additional issue, in that after initial programming, there needs to be a power cycle, because of the "empty" mechanism to enter the bootloader.

JW

[jlag]

What @waclawek.jan said :)