Skip to main content
RMurt.3
RMurt.3
Associate II
October 26, 2022
Solved

STM32CubeMX V6.6.1 HAL driver crashes, LL interface works

  • October 26, 2022
  • 5 replies
  • 4809 views

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

0693W00000VOIHgQAP.png 

HAL footprint

0693W00000VOIIjQAP.png 

This topic has been closed for replies.
Best answer by RMurt.3

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

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

5 replies

Pavel A.
Pavel A.
Super User
October 26, 2022

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
RMurt.3Author
Associate II
October 26, 2022

Added the MX project file.

Semer CHERNI
Semer CHERNI
ST Employee
October 27, 2022

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.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
RMurt.3
RMurt.3Author
Associate II
October 27, 2022

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
RMurt.3Author
Associate II
November 6, 2022

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
RMurt.3AuthorAnswer
Associate II
November 8, 2022

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

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

Terms & ConditionsAccessibility statement