STM32L0 new series support plan in HAL

[arm999]

Hello, there are 3 main sub-series of STM32L0 series:

STM32L0xx1, STM32L0xx2, STM32L0xx3

Judging by the os/hal/ports/STM32L0xx/stm32_registry.h here is the current support status:

STM32L011xx - supported
STM32L021xx - unsupported (same as STM32L011xx, but with encryption)
STM32L031xx - supported
STM32L041xx - unsupported (same as STM32L031xx, but with encryption)
STM32L051xx - supported
STM32L061xx - supported? (I can't find this series on ST's catalog)
STM32L071xx - unsupported (I'm interested in these)
STM32L081xx - unsupported (same as STM32L071xx, but with encryption)

STM32L052xx - supported
STM32L062xx - supported (same as STM32L052xx, but with encryption)
STM32L072xx - unsupported
STM32L082xx - unsupported (same as STM32L072xx, but with encryption)

STM32L053xx - supported
STM32L063xx - supported (same as STM32L053xx, but with encryption)
STM32L073xx - supported
STM32L083xx - unsupported (same as STM32L073xx, but with encryption)

Are there any plans of adding the support in the near future? In case there aren't, I'd like to do it myself (starting with STM32L071xx and STM32L081xx), so is there a guide of doing it or should I just copy-paste the code i.e. from STM32L051xx and modify the code according to the datasheet and reference manual? Thanks!

[Giovanni]

The idea is to support everything as soon we have boards to test on.

Giovanni

[josesimoes]

Hi,

Any plans to add the definitions for STM32L072xx ?
There a nice LoRa board using a mcu from this series....


Thanks!

[Giovanni]

Hi,

Probably it is just matter of adding entries to the registry and hal_lld.h, no plans yet but you could give it a try.

Giovanni

[josesimoes]

Giovanni: I did just that and the build went fine.

Now I have an exception which I can't determine the cause.
(for the record I was having this too before, when I was declaring my board as a STM32L073xx, despite being a STM32L072xx)

Main is as simple as it can be: calling the inits, no threads beign created, just an endless loop with a chThdSleep.

I've traced the exception to this line of code (in chcoreasm_v6m.S):

blx r4 (@ line 104)

It gets there on the very first call to chThdSleep.
The execution goes all the way until it calls chSysSwitch() which goes through _port_switch and arrives at _port_thread_start.
As soon that blx is called, the execution blows.

[Giovanni]

I can only test on existing boards and it works (obviously), are you using our startup files? other custom code/setup?

Giovanni

[josesimoes]

Yes I'm using all the standard startup code.

The only diference here, is that this system has a bootloader, so I'm setting CORTEX_VTOR_INIT to the appropriate address in chconf.h
This same address is also set in the linker file.

For the sake of testing I've overide the bootloader and made the same code start at the default address. It's now working without any exception.
So I say there is a hint here on what could be causing this.

FYI I'm using this bootloader (mechanism and configurations) with SMT32F4, F7 and H7 and it's working as expected.

I'm working under the impression that SMT32L0 has VTOR (I've checked that on ST Cube HAL files and ARM headers).

I'm not familiar with the code that lives in chcoreasm_v6m but knowing that it's working with whatever is in chcoreasm_v7m, could it be that there is a difference there that is causing this?
Considering that chcoreasm_v6m is used on all other series (F0, etc) that don't have VTOR, this could have been overlooked here.

[Giovanni]

L0 has a Cortex-M0+ so it should have VTOR.

Giovanni

[josesimoes]

It has, no doubt about it.

The thing is, when using VTOR an exception is thrown when doing the thread switch.
For the same code, if I DO NOT use VTOR, the app runs as expected.

My suspect is that the thread switch code in chcoreasm_v6m is, somehow, not taking into account the VTOR (when set)

[Giovanni]

Thread switch only involves stacks (old thread stack, new thread stack).

It can be:
1) Stack pointers are not pointing in the proper areas.
2) Thread context structures saved in stacks are corrupted.

Is it a context switch after an ISR or thread-to-thread (look at the stack trace just before the crash).

Giovanni