STM32CubeMX V6.6.1 HAL driver crashes, LL interface works

[RMurt.3]

This is my first STM32 project and I am using an STM32F030C6T as a MODBUS slave device. I used the STM32CubeMX V6.6.1 to create a project template and STM32CubeIDE Version: 1.10.1 Build: 12716_20220707_0928 (UTC), along with an STlink interface.

When I build the MX project using HAL driver under project settings/advanced the project builds correctly but when I download into the target device it crashes as soon as it tries to initialise the USART and other devices. If I comment those drivers out so only the GPIO is initialised I can get the GPIO to run for a very short time before in triggers the HardFault interrupt.

If I rebuild the project and change to using the LL driver interface, the code builds and downloads and runs without issues. I can then add my 5 lines of code for a blinky light.

Seems to be an issue with the HAL setup or my environment, any suggestions welcome.

Footprint for the LL interface is

 

HAL footprint

 

[Pavel A.]

How much RAM does your program use? HAL code requires more RAM than LL.

The DS says it has only 4 KB (page 10, table 2) which is er....tight.

Also, it's the time to get more familiar with the debugger, especially the fault analyzer tool.

[RMurt.3]

Added the MX project file.

[Semer CHERNI]

Hello @RMurt.3​ 

First let me thank you for posting.

As @Pavel A.​ mentioned this MCU have a small RAM and Flash with 4KB for RAM and 32KB for FLASH also the fact that the HAL require more memory space than the LL.

The build analyzer tool in CubeIDE give you an estimation about the memory use.

You can work with the LL driver or try to use (-Og) optimization level when compiling the code.

Kind regards,

Semer.

[RMurt.3]

Thanks for feedback.

I added a snapshot of memory footprint which does not seem to be be stressed to much.

I'll look up more on this "fault analyser" tool to see if that helps me.

[RMurt.3]

@start stack is 0x20000ff8 

If I run it the stack is now 0x20000fa0

 

Trying to find documentation on stack location and size now.

[Pavel A.]

Please show more of the fault analyzer info.

The stack location and size is defined mainly by the link script. The initial value of the sp looks good. But the PC at the point of fault is bad (42332600)

[RMurt.3]

Hi Pavel, thanks for your reply.

It seems the PC goes west just after this function call

 

When we get the first interrupt @ Sig int handler 0xfffffff9

Im not sure what to make of that but I think that is the hardfault??

The SFR may be showing me the final state and not when the RTC init was executing

 

Another observation I have made is that if I just RUN then it gives me the error shown above

But If I single step through the MX_RTC_Init() it is all good and It crashes when it tries to go into the MX_ADC_Init()routine. Maybe there is something about the emulator or an optimisation that makes it look like the error is on the adc call.

[RMurt.3]

I am not so sure that the issue has anything to do with the HAL versus the LL interface so much anymore. For this example I changed only one thing (HAL vs LL) and the access to the IO went from crashing to being able to run.

I think the underlying issue is more to do with the interrupt system, I suspect that the difference is how well the IO was initialised in HAL vs LL interface and if it enabled the IRQ.

I made another project without all the IO, just the TIM14 with an IRQ, using the LL interface. First thing I noticed was that the CEN bit was not being set to enable the timer. Anyway once I set the IRQ flag the does the same thing and does same thing about sig int handler at 0xffffffff9 and 0xffffffff1.

Reading around other pages, I have checks that we have extern C around the handlers (name mangling) and that the output is linking to 0x000000 with the irq vector table etc. and it all looks ok.

Even tried triggering the SVpend irq, it always ends up the same - i.e. we do not enter the irq handler and we crash with same error.

I think my next move may be to find some known working code for say TIM14 or anything else that has an IRQ and try to load this (without all the MXcube initialisation stuff).

I would appreciate it if anyone has some good pointers to the steps to check for the simplest IRQ example.

[RMurt.3 · Accepted solution]

I finally managed to get an interrupt working. Yahoooooo

What I found is that the SYS_CFG.MEM_MODE register == 1 (which is system flash, not Main flash)

So I hand edited register and set mem_mode=0 and fianlly we got interrupts calling the irq vectors as expected.

The MEM_MODE register is supposed to configured by the BOOT0 pin which is tied low. BUT there is a an empty check

So this maybe a hangover with using emulator, but for now I have to manually reset this to 0 to set main flash memory.