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.