Support for recent GCC toolchain and STM32F4-Discovery board

[cw2]

I would like to contribute support for recent GCC toolchain (GNU Tools for ARM Embedded Processors, including newlib-nano), but I don't have any MCBSTM32 board for testing, I was thinking something more affordable like STM32F4-Discovery.

Are there any plans to include STM32F4-Discovery port in the official NETMF?

[piwi1263]

I'll vote for this as well, mostly for the support of STM32F4xx MCU with the most recent GCC toolchain.

CW2, what MCU is on that board the STM32F427 or the STM32F429 ? There are a view discovery boards. The nine series is with an LCD controller on board. Maybe the STM32F411 is a good power efficent MCU alternative. It would be on an even cheaper nucleo board.

2015-03-19 16:17 GMT+01:00 cw2 notifications@github.com:

I would like to contribute support for recent GCC toolchain (GNU Tools for ARM Embedded Processors https://launchpad.net/gcc-arm-embedded, including newlib-nano), but I don't have any MCBSTM32 board for testing, I was thinking something more affordable like STM32F4-Discovery.

Are there any plans to include STM32F4-Discovery port in the official NETMF?

— Reply to this email directly or view it on GitHub https://github.com/NETMF/netmf-interpreter/issues/26.

[smaillet-ms]

We don't have any plans for BSPs beyond the MCBSTM32F400, however since it is effectively a superset of a large family of STM32 chips it can be used as the basis for a large set of boards, We are perfectly happy to take additional ports (Including additional chipsets) as contributions

On that note: One thing we are planning to get going fairly soon. Is better support for CMSIS and mBed HAL libraries that already exist. This would allow re-use of the existing "driver" libraries for a broader range of chips without the need to re-write or wrap them just for NETMF. This would make it easier to port to the majority of different Cortex-M chips,

[cw2]

@piwi1263 Initially, I am going to use STM32F4-Discovery that has STM32F407VGT6. Then, it depends - if there is enough interest and resources... but my personal focus would be more likely towards smaller micros.

[cw2]

@smaillet-ms Thanks for the info. Regarding the driver libraries, that is something I have been exploring too...

[ktos]

NETMF for Discovery4 is available now and is working - I'm using this board with STM32F407VG and NETMF 4.3.1 using patches from https://netmf4stm32.codeplex.com/ (Discovery4 itself) and https://stm32f4netmfgcc.codeplex.com/ (GCC patches) compiled with GCC 4.6.2. And a bit of small patches by myself if I remember, but it works - except Tinybooter, I cannot compile Tinybooter with GCC (to work).

Probably we can use this solutions already to include Discovery4 in upstream - not sure about licensing (both of them are Apache License 2.0).

For STM32F429 (with LCD screen) there is official NETMF from STMicro: http://www.st.com/web/en/catalog/tools/PF260087 but I don't even know what version it is.

There is however also a "new" Discovery4 (http://www.st.com/web/catalog/tools/PF259098) with 256 KB of flash and 64 KB of RAM (but with magnetometer, gyroscope and something more).

[piwi1263]

In the doc of the STM32F429 it is 4.3.0 and it is included as a binary. No sources though, maybe ST can be talked into publishing the source on github too ???

However, I assume that they (ST), as a company use the KEIL toolchain and not the GCC one. Weren't they (ST) who bought the whole KEIL stuff anyhow ?

Thanks, for the links though !!

2015-03-20 21:06 GMT+01:00 Marcin Badurowicz notifications@github.com:

NETMF for Discovery4 is available now and is working - I'm using this board with STM32F407VG and NETMF 4.3.1 using patches from https://netmf4stm32.codeplex.com/ (Discovery4 itself) and https://stm32f4netmfgcc.codeplex.com/ (GCC patches) compiled with GCC 4.6.2. And a bit of small patches by myself if I remember, but it works - except Tinybooter, I cannot compile Tinybooter with GCC (to work).

Probably we can use this solutions already to include Discovery4 in upstream - not sure about licensing (both of them are Apache License 2.0).

For STM32F429 (with LCD screen) there is official NETMF from STMicro: http://www.st.com/web/en/catalog/tools/PF260087 but I don't even know what version it is.

There is however also a "new" Discovery4 ( http://www.st.com/web/catalog/tools/PF259098) with 256 KB of flash and 64 KB of RAM (but with magnetometer, gyroscope and something more).

— Reply to this email directly or view it on GitHub https://github.com/NETMF/netmf-interpreter/issues/26#issuecomment-84131393 .

[smaillet-ms]

@piwi1263 ARM bought Keil about a decade ago. AFAIK the NETMF port was done by the same folks who own the CodePlex port. We're more than happy to take contributions from the owners.

[piwi1263]

Well, then it's about time to talk to Cuno.

Op zaterdag 21 maart 2015 heeft Steve Maillet notifications@github.com het volgende geschreven:

@piwi1263 https://github.com/piwi1263 ARM bought Keil about a decade ago. AFAIK the NETMF port was done by the same folks who own the CodePlex port. We're more than happy to take contributions from the owners.

— Reply to this email directly or view it on GitHub https://github.com/NETMF/netmf-interpreter/issues/26#issuecomment-84221704 .

[ktos]

And one more link which may be interesting in topic of STM32F4: https://www.ghielectronics.com/community/forum/topic?id=15350&page=4#msg181101

Cuno from Oberon told that some improvements (for MFUpdate) they had were sent to Microsoft and they were integrated with vNext branch on old CodePlex site. However "We should be working on an update to NETMF for STM32 next week." and I don't see anything changed since a year ago.

However, he also told "We hope to get rid of our own Codeplex site, and instead directly contribute source code to Microsoft's site, in the vNext branch.".

[smaillet-ms]

@ktos Yes, we are talking to Cuno and his team and are hoping to have updates from them as soon as they are able. We've been waiting until we got the framework moved to GitHub to make such contributions easier. Now it's just a matter of Cuno and team finding available time.

[Injac]

I am voting for a working GCC support as well.

[cpfister]

Just saw this discussion today...

@cw2 We have a port for the F4 Discovery board, not all peripherals supported though.

@ktos @piwi1263 The ST Microelectronics port is based on our sources, but they have added drivers e.g. for LCD displays. For that, they use an ST library, which has a license that is incompatible with Apache 2.0. That's why they do not release the source code.

@ktos We're late with publishing our sources. We wanted to go directly to NETMF 4.4 though, and more importantly, to Microsoft's new GitHub site rather than wasting time with our old Codeplex site. We have recently done our first pull requests as an experiment. Now that we can actually build NETMF 4.4 (thanks Steve!), we'll be able to publish the rest as time permits. Our goal is to have it done until end of June. But if commercial customers threaten us with money, they have priority ;-)

We have a number of solutions, for a variety of STM32 board. We can gladly publish them. But we don't have the time to test and maintain all of them (Discovery 4, MCBSTM32E, STM3220G, STM3240G, STM32 Stamp). Should we contribute the code anyway? Does anyone have some of the hardware and is willing to test it?

[Injac]

I am willing to test and to help with the documentation. Going to order 2 Discovery 4 boards now.

[piwi1263]

I've got 2x nucleo Board with the STM32F411 one without the st-link and one with the st-link part of the pcb and already running netmf 4.3 could do some tests as well. Plus I've got a 429 Discovery board to play/test with.

[cpfister]

Ah, I think we have a Nucleo F411 solution somewhere as well...

Thanks @Injac and @piwi1263. Please give us a couple of weeks until we have migrated everything to NETMF 4.4, which is still an unknown to us at the moment.

[Injac]

@cpfister Ok.Thank you guys for all the effort. Eager to test and help.

[smaillet-ms]

As for GCC support we would like to have that for our final release of V4.4, the distribution we'd want to use would come from the ARM supported Launching Pad: https://launchpad.net/gcc-arm-embedded. We are more than willing to take contributions from someone willing to adapt the build and code to support this compiler tool chain.

[Injac]

@smaillet-ms I have already tried to compile with this tool-chain without any luck. Too many errors, too much to fiddle with (if you don't know exactly where to start). On the internet I found today some links, where some people mentioned the CodeSourcery-Tool-chain which should work with NETMF, but does not. There is a lot of confusion out there what people say should work and what not. Good information is hard to get and I am glad too see progress here.

[smaillet-ms]

The previously supported Code Sourcery tool chain no longer appears to be available. Given the active support from the ARM team the Launchpad version seems the best available. However the build targets and settings, not to mention compiler specific conditional code C++ code, assembly code, scatterfile/linker mapping etc... all need to be updated. You shouldn't expect that any GCC will "just work" at this point. So the Launching pad one is where you'd start.

The basics: 1) Update setenv_gcc to handle the new tools 2) Update the targets and settings files specific for GCC to compile the code 3) Update any compiler specific support (guarded by things like #if(ARMCC) or other such tests) 4) Update or create assembly files for this version of GCC. 5) Update the scatterfile.xml for GCC for the MCBSTM32F400 or other board you are using. If the current ProcessScatterFile.exe that transforms the common XML into the tool specific language doesn't support current features of the linker definition files, then it must be updated as well.

[Injac]

@smaillet-ms Thanks. I will definitely start to look into this today. Prepping a separate system now.

[cw2]

I am planning to work on this, as I have added/fixed support for GCC toolchains several times already. Unfortunately, as mentioned in the original post, I don't have the Keil's (reference) board and I cannot make another board port myself due to limited resources.

[Injac]

Hi @cw2 . How much is that reference board? And which board are you talking about ? Can you send me a link ?

[cpfister]

@Injac It's this board: http://www.keil.com/mcbstm32f400/ About $360.

[Injac]

@cpfister Ok. Thanks for the quick reply :) I have sent you a private message on the GHI forums.

[josesimoes]

I have news about this. good news: I've successfully compiled 4.4 with GCC for a Discovery4 board solution. I had to do several tweaks and add a few files. bad news: It doesn't boot. I believe that this is caused by some wrong code in the boot section and/or interrupt vectors. Most likely I've made a mistake porting assembly from the RDS version.

I'll get back to this as soon as time permits.

[smaillet-ms]

If you can at least push it as a branch to your fork, someone else with a greater urgency might be able to pick up where you leave off.

[cw2]

@josesimoes Usually, there are two main problems: first, GCC is instructed to emit ARM instructions for a few assembly files that results in invalid instruction fault (because the micro supports only Thumb/Thumb2), second is wrong memory layout in scatterfile. If you are willing to share your code, I can have a look...

[josesimoes]

@smaillet-ms Just did that @cw2 like I said I'm suspecting that the cause is the "port" I've made in the assembly app_entry, vectors_table, etc. as I'm not very proficient with the ARM32. The scatterfile I'm using there it's based in another one I have for 4.3 that runs nicely. (although I've made some changes to accommodate the LwIP and Ethernet areas...) I believe the thumb/thumb2 is taken care off properly. Really appreciate if you could take a look at it.

Just pushed two branches: https://github.com/Eclo/netmf-interpreter/tree/gcc_support https://github.com/Eclo/netmf-interpreter/tree/discovery4_solution

To make this more manageable I've separate the GCC support and the Discovery4 solution in two different branches. Regarding the first branch: I would like to ask someone using the Keil compiler to verify the changes I've made in DeviceCode/Targets/OS/CMSIS_RTOS/CpuOsIrq.h with the PRIMASK. I've added a comment to the commit.

[josesimoes]

@cw2 I have a few hours to spend on this. Was curious if you've made any progresses so far. No worries or pressure! :) This is just to prevent that we waste time solving the same issue twice.

[cw2]

@josesimoes No problem, go ahead. I've had only a quick look at source - I'd need to build it and run on the hardware to get more information. Although, I am considering using non-RTOS variant first, because it can be compared to previous versions more easily.

[piwi1263]

@CW2 is this not a nice device to start with, since you're looking for small devs.

https://www.ghielectronics.com/community/forum/topic?id=19302&page=1#msg191050

[cw2]

I guess this can now be also closed :feelsgood:

[smaillet-ms]

Yep, got interrupted by a meeting while pruning the issue list, thanks.

[cpfister]

At long last, an update regarding our Disco429 solution... Justin saved us ;-) https://www.ghielectronics.com/community/forum/topic?id=19683

[piwi1263]

Yoohoo, now up to 4.4 and LCD that is an ILI9341 which I have plenty of to play with, and there is at least one netmf driver I found. But that won't work on the Disco429. However this library could be a good start for LCD support on the Disco429 http://stm32f4-discovery.com/2014/06/library-18-ili9341-ltdc-stm32f429-discovery/