Add Supports to STM32 series

[weixiongmei]

Hope STM32 series would be supported soon, the current kits are too expensive for students.. Thanks for great works!

[cpfister]

I would love to see that, too.

[mikehole]

By current kit are you referring to the Netduino boards? I ask this because they have STM32 processors http://www.netduino.com/hardware/ and run .NET MF so I must be missing something.

[piwi1263]

I completely agree with Cuno. I would too see the STM32 being supported, especially the F4/F7 ones

[kail]

Hi all, thanks for your feedback. Adding an STM32 board is definitely on our radar. Is there a particular board any of you have in mind?

[cw2]

STM32F4DISCOVERY and one of the Cortex-M0 NUCLEO boards. I am planning to add support for such a board myself, although not promising anything at the moment - I have not yet actually tried to do so, thus it seems to be relatively easy :)

[piwi1263]

STM32F4DISCOVERY with or without the display, one of the Nucleo boards, preferably STM32F411RE ...

[rocuh]

One little wrinkle is the lack of cmsis dap on the STM boards makes debugging a little messy. I have had a play with the making a basic port to the STM32F7 disco board and that was straightforward, mostly copy/paste from the K64F port. Having mbed as a sort of HAL layer was a good idea!

[piwi1263]

Wow, care to share the details. Blog maybe ?

[rocuh]

https://github.com/roceh if you want to try. Its pretty much sync'd up with the latest llilum build.

[piwi1263]

Ok, thanks a mill !!!!

[kail]

For those interested in attempting to port the STM32 F4 Discovery board, this link might be helpful: https://developer.mbed.org/questions/53937/STM32F3-Discovery-or-STM32F4-Discovery-a/ However, like roceh pointed out, there is no cmsis dap, so flashing will have to be done with the STLink Utility.

The libs can be obtained by creating an Arch Max project in mBed, and exporting the program for Arm Embedded tooling. After that, it is a matter of pattern matching with current mBed libs and the K64F config (CTRL + SHIFT + F in VS, and search for K64F), and modifying the makefile. Good luck!

[piwi1263]

Thanks again.

[weixiongmei]

The kits i meaned are LPC1768 & K64F-FRDM.

If one of the NUCLEO boards or the STM32F7 discovery board can be supported, that would be amazing, Nucleo boards are cheap, and STM32F7 has most of the sources we might use for projects.

Thanks!!!!

[rocuh]

I've used this https://github.com/texane/stlink project to replace pyocd_win for stm debug integration.

st-util.exe -p 3333

One little change that would be useful would be for the args passed to flash_tool.exe be completely specified by the "Llilum Flash Tool Args" debugger property - currently it always prepends the args with the name of the file to flash, unfortunately st-flash has the command line format:

st-flash.exe write file.bin 0x8000000

so the default args would be $(OutDir)\$(LlilumOutputName).bin for the cmsis dap boards and could be changed to write $(OutDir)\$(LlilumOutputName).bin 0x8000000 for the stm boards.

Also I noticed the gdb download (if "Use Flash Tool" is disabled) would not work due to the 'target remote:3333' being done after -ex 'load...' command line

[cpfister]

I agree with cw2: STM32F4DISCOVERY and a Cortex-M0 NUCLEO board.

[kail]

For those of you that are still interested, we have added a guide for creating a new board support package: https://github.com/NETMF/llilum/wiki/Creating-a-Board-Support-Package

As an example, we have also added a BSP for the STM32L152 Nucleo board. If you have any feedback on the guide, or any issues with the BSP, please let us know!