Mbed-os: STM32L4 combining support for L431xx, L432xx and L433xx devices

[helmut64]

• Type: Enhancement, Question

At present mbed supports only the 64kB MCU STM32L432KC, this represents one L4 MCU out of 40 different L4 MCU devices, all L4 offering 64kB memory. For my project I use the STM433CCT series which does not allow me to use all LQFP48 Pins within mbed because the STM32L432KC supports only 32 Pins.

My proposal is the following. The Nucleo STM32L432KC implementation could use the MCU HAL definition of the STML433 LQFP100 device. This would allow mbed users to use 39 more MCU devices by choosing the STM32L432KC Nucleo target. Which also means this developers can continue to use the mbed development environment (online and offline) and benefit from mbed.

Is this something ST would agree on, I can offer to do the work and commit a patch. I understand that a new target would be better, however gaining 39 more MCU devices would be a big plus for this compromise.

What do you think?

[0xc0170]

cc @bcostm @adustm @LMESTM @jeromecoutant

[bcostm]

I think your proposal will be confusing for end-users and how your target will be tested ? On which board ? Personnally I prefer to create a specific folder for the L433xx devices and put your target in it as we do for other boards. But do you plan to add your target on mbed ? Or it is just to benefit from mbed L4 files ? On mbed, the "rule" is to create one folder for one real platform. If I understand correctly, you would like to create a "generic" target that could be used for a set of MCUs without using a real board. Correct ? This is interesting but I don't have the answer myself... There are thousands of STM32 part numbers and for sure we'll not put all of them on mbed...

[helmut64]

The current STM32L432KC is a very basic target, it has even no user button. Doing it, as I propose (keeping the STM32L432KC target name) but just using the STML433 LQFP100 HAL device files would enable 39 more MCUs for engineers. For STM32L432KC users everything stays as it, the STML433 is a superset of the of the STM32L432 MCU.

Of course, testing gets only done with the STM32L432KC device.

PS: I don’t plan to put the target on mbed because users cannot purchase it, I am working on a commercial solution and like to use mbed with the online compiler and collaboration for it. The mbed platform is better than Arduino, Keil, IAR, etc. do to the fact that everthing is integrated with version control, collaboration with users and a great forum.

Here are mbed are other examples howusers utilise a similar target, e.g. the stm32f103c8t6 china board using the NucleoF103RB target.
https://developer.mbed.org/users/hudakz/code/STM32F103C8T6_Hello/

I personally use the NucleoL073RZ target for the new nice STM LoRA board (B-L072Z-LRWAN1 ) running with mbed, and I ported the SemTech Lora reference board driver over to the STML0 B-L072Z-LRWAN1 board using the Murata Lora chip deploying it using the NucleoL073RZ target under mbed.

Again I believe the proposal is reasonable, I am happy to discuss it further.

[helmut64]

Hier is my project:

• STM32L4 MCU
• STM LSM303AGR (accelerometer and magnetometer)
• 4 MB external SPI flash used with the mbed FATFilesystem
• Battery operation using two AAA batteries (holder on the back)
• USB Connector on the back (working on DFU programming)
• Debugger interface (SWD, SWO, RX/TX the black connector)
• WiFi connectivity

[helmut64]

Dear STM & mbed Team,
I did a proof of concept for this and it works.

My opinion is extending the STM32L432KC target with broader MCU STM32L43x support would be a smart move, no additional target support needed, the Nucleo_L432KC board would be sufficient for testing and it allows developers to use 39 more STM MCUs.

It is clear to me that a new target like STM32L43xx_GENERIC would an alternate option which is also cleaner but misses a reference board.

Here is what I changed in the TARGET_STM/TARGET_STM32L4/TARGET_STM32L432xC tree:

• device/stm32l432xx.h (moved the content of the stm32l433xx.h into it)

• device/TOOLCHAIN_ARM_STD/startup_stm32l432xx.S (added the six additional intr vectors)

• TARGET_NUCLEO_L432KC/PeripheralNames.h
  (added UART_3/SPI2_BASE/I2C2_BASE/TIM6_BASE+TIM7_BASE

• TARGET_NUCLEO_L432KC/PeripheralPins.c
  (added the additional pin and it alternate pins)

• TARGET_NUCLEO_L432KC/PinNames.h (added the additional pins into the PinName enum)
  An addtional ifdef STM32L43x_GENERIC would allow to hide the additional pins for pure
  Nucleo_L432KC users.

My option is that the mbed platform (Online and Offline) is a very good development environment, we gain new capabilities and libraries rapidly which brings new developers to the platform. Commercial development solutions like Keil/IAR are getting behind and new developers are joining rather mbed or Arduino. I am also very convinced that ST has great MCUs and easy to start devices with the Nucleo and Disco boards. A broader generic mbed support would be a win situation (better than developing additional Nucleo boards).

Why not to give it a test within the Nucleo_L432KC target, and see how to go from there.

Regards Helmut

[bcostm]

Hi Helmut,
I understand your point of view but I prefer to not modify the actual NUCLEO_L432KC target. I prefer to use instead a new generic target as you wrote. But because of the contract between ST and ARM, I am not not sure if we are allowed to publish on mbed a such generic target without having an existing board associated to it... I let ARM comment.

[adustm]

cc @screamerbg
Hello Mihail, any advice on this ?
Kind regards
Armelle

[helmut64]

cc @sg-
Maybe somebody has feedback for this.
The quick solution extending the NUCLEO_L432KC target would mean no mbed change except for the HAL layer which ST controls. Sometimes strait forward implementation can develop into something larger in the long run.

For me it is no problem because I purchased Keil MDK for debugging, and I work also offline with the gcc/gdb, however not using the mbed IDE would be a disadvantage.

[theotherjimmy]

@helmut64 @adustm @bcostm Would you make this generic target public? or would it be used to inherit from and share code in targets.json? I think answering these questions will help us understand what your intentions are.

[helmut64]

Public is the only option because all developers should benefit from using 39 more STM MCUs of the STM32L43xx series. As a reference board we can continue to use the NUCLEO_L432KC.

[theotherjimmy]

@helmut64 I think you/someone would have to send in a board if you make the new target "public": true. If you just use it to share code between targets, I would not expect the mbed enabled program requirements to apply to non-public targets. You are allowed to inherit from non-public targets.

[theotherjimmy]

@helmut64 @bcostm @adustm I just had an offline conversation with Sam to get this information for you. If you make a new target, the mbed enabled program requires shipping us some boards for that target. We use these to support regression testing on hardware.

However, if you refactor the inheritance hierarchy to support an entire family of boards, but make the generic family target non-public, which still allows boards to be added by inheriting from this target, Then you do not need to ship boards.

[adustm]

Thank you Jimmy for this explanation.
I'm not familiar with the public / non public platforms.
The non public platform is still visible in the master of mbed-os, isn't it ?
And can it be used in the online compiler ?

We are here discussing about having a virtual generic platform, that would fit with several platforms.
The idea of reworking the inheritance hierarchy is probably the good one.

Kind regards

[theotherjimmy]

public vs. non-pubilc
The non public platform is still visible in the master of mbed-os, isn't it ?

Nope. It's just used for sharing code between targets.

And can it be used in the online compiler ?

Also no.

The point of declaring something non-public (setting the public key to false in targets.json) is to create a general purpose block of code that is shared between many targets.

non-public targets cannot be compiled for. The only way to compile for them is to create another target that inherits from it. If you were to create a "generic" target, the mbed enabled program would require you to ship a bunch of boards.

[theotherjimmy]

The reason I'm recommending that you re-factor the inheritance is that it allows you to turn on boards and mbed enable them individually. Further, with https://github.com/ARMmbed/mbed-os/pull/4103 you should be able to add your own target that would also benefit from the shared code.

[helmut64]

Thank you Jimmy for the explanation.

For the STM team,
I believe my original idea of combining support for L431xx, L432xx and L433xx devices for the STM32L432KC target would be the easiest way to go.

[adustm]

Dear Helmut @helmut64

My concern with your proposal is that a user of L432 (with a real NUCLEO_L432) will be able to use hw interrupts by software that are not physically available on their hardware.
For instance : I2C2 / SPI2 / USART3 / SDMMC1 / LCD

In your proposal, even the pins will exist in peripheralpins.c

A user willing to use an example made for L433 with the platform NUCLEO_L432KC will have absolutely no information that is it impossible until he/she gets the hard_fault error (which you can see only with a debugger). It will have an impact on the support we will have to provide later on.

I think the best suggestion is the generic target and inheritance story. Some #if defined(TARGET_STM32L433xx) / #if defined(TARGET_STM32L431xx) /#if defined(TARGET_STM32L432xx) should be added in peripheralpin.c / *.s / *.ld / stm32l433xx.h/... files to reuse those files between the L431, L432 and L433 targets.

Kind regards

[helmut64]

Dear Armelle, for the PinNames.h the additional 4xx pins can just be enabled by activating a define .e.g. ENABLE_STM32L43xxPINS in the 432 PinNames.h, which means a normal user will not run into problems of using unavailable pins.

I still feel that lifting the NUCLEO_L432KC target by using the 433 HAL files would allow users to use the mbed online compiler for 39 more ST MCUs.

A new target would not be supported using the online compiler, which means there is no need for it because for Keil MDK or GNU offline compilers these changes can be done in a own fork, however only by very experienced developers

Did you know that the ARM Online compiler is being used by 300k compiles per week
Did you know that the ARM Online compiler produces 40% less code size compared to the offline GCC tool, it also produces significant faster code.

I believe it would be a wining situation for all, ST benefits from broader MCUs support, users benefit from a productivity gain using the mbed online environment which is way easier to use than the office tools.

Anyways we need to discuss options about this case e.g.:
a) Should I close it?
b) Is ST willing to make the NUCLEO_L432KC more generic? (I can help)
c) Should I develop a simple 433 generic board and publish this on mbed?
And sell this for a nominal value. (would be fun, but overkill)

PS: I added your STM-B_L072Z_LRWAN1 LoRa board on mbed, just by lifting an available Nucleo L0 board with the sx1276 driver: https://developer.mbed.org/questions/78000/Support-for-the-STM-B_L072Z_LRWAN1-LoRa-/

Thank you.
Helmut

[helmut64]

As the new "511-NUCLEO-L433RC-P" board is now available, this entire case can be condensed to support the new Nucleo Board " 511-NUCLEO-L433RC-P" which uses the STM32L433.
Is STM adding support for this board?

[bcostm]

No, there is no plan for mbed ST team to add this board on mbed. It is not a technical issue just priority...
But if someone wants to add it, we'll review the code.
Thanks

[helmut64]

I ordered some boards and will look into this.
BTW: You marketing team puts "mbed" compatible on the Nucleo Board, like always.

[bcostm]

OK thanks.

Here the PeripheralPins.c file to help you:
https://github.com/bcostm/bcostm.github.io/blob/master/NUCLEO_L433RC_P_PeripheralPins.c

[helmut64]

@bcostm I prepared the support for the NUCLEO_L433RC target according to the great instructions "steps to create a new STM32 platform", I will check in my NUCLEO_STM32L433_SUPPORT branch soon.

[helmut64]

My new pull #5230 request will add support for the new NUCLEO_433RC board. Once it is accepted this case is obsolete and can be closed.

[bcostm]

ST_TO_BE_CLOSED