MCBSTM32F400 compilation with GCC and networking

[josesimoes]

Hi, Could someone please confirm that the MCBSTM32F400 solution should compile with GCC?

I'm working on adding network support for the Discovery board and was using the MCBSTM32F400 for validation. It turns out that I'm getting a bunch of errors (all SSL related) when compiling MCBSTM32F400. So right now I'm trying to determine if I have something wrong with the SSL and/or LWIP folders structure, or if MCBSTM32F400 doesn't compile with GCC at all.

Thanks!

[smaillet-ms]

The non-networking project was known to build with GCC, however the networking variant was not built or tested with GCC (and likely needs more work as the C-runtime and startup code would need to be adapted to support the different compiler runtime and the underlying RTOS)

[josesimoes]

Thanks Steve. That is correct. I confirm that the NONET variant can be build with GCC.

[josesimoes]

Kind of resolved... I would say that it would be very interesting to have a NETMF solution network capable that can be compiled with GCC. :neutral_face:

[smaillet-ms]

The original question was resolved. Adding GCC support for the Networked variant is a new feature. :wink: (We can tackle that in the V4.5 release time unless someone else has a working Pull request they wish to offer)

[josesimoes]

@cw2 - I was wondering if you were able to successfully build the NONET variant of the MCBSTM32F400 solution with GCC...

[cw2]

Yes, NONET variant compiles fine with GCC (4.9.3) - but that you already know...

[josesimoes]

@cw2 you are correct, obviously... I meant to ask if you were able to build the network variant... :blush: my bad!

[cw2]

Nope, there is some problem with OpenSSL - for reasons unknown, the crypto_openssl.lib built with GCC is missing most of its contents (when compared to MDK build), so there are unresolved symbols in link phase.

[josesimoes]

@cw2 - That's what suspected from looking into the error messages.

I also tried with the Discovery4 board by cloning the RTX stuff from the MCBSTM32F400 solution and setting SSL to false (in the solution project). With this all the OpenSSL errors were gone but the board doesn't boot... Only the tinybooter. I'm trying to figure out where is the problem. If it's the assembler files or some configuration that is missing. The configuration path it's rather convoluted because it jumps and calls functions from the STM32F4 boot loader, solution unit, RTX config, etc. And it seems to require a couple of extra steps with GCC.

[smaillet-ms]

It's all the C/C++ runtime startup. It's different for GCC=Newlib or nanolib so the startup assembly code needs to be adjusted along with the C++ code. That hasn't been done for GCC+RTX for the networking.

[josesimoes]

@smaillet-ms - Understood. Let me ask you this: is that something that your team is planning to address or you'll be waiting for a contribution from the community?

[smaillet-ms]

It's something we'd like to see completed but not something we are presently working on. We've got finalizing4.4 and planning how we'll integrate mBed 3.0 into v4.5 taking a higher priority. If you want to take it on - assign this issue to yourself and go for it!

[josesimoes]

I've been pulling my hair with this for the last week and I'm not getting anywhere. Need a "know good build" to try compare the generated assembly. Can someone please make available the tinyclr_scatterfile.ldf, tinyclr.map and tinyclr.axfdump files of a MDK build to compare with the GCC generated ones?

Thanks

[josesimoes]

@smaillet-ms could you please send me/make available the tinyclr_scatterfile.ldf, tinyclr.map and tinyclr.axfdump files of a MCBSTM32F400 MDK build to compare with the GCC generated ones? Thanks.

[smaillet-ms]

I don't have this available to me at the moment, but I can get those files when I get back into the office in the new year.

[josesimoes]

@smaillet-ms I understand that you must be rather busy with llilum but could you please waste 5 minutes with this and send me those files so I can resume my quest? thanks a lot.

[smaillet-ms]

NOTE: For MDK there is no LDF file as it uses scatter files (same concept but different syntax and details) so I've included that in case it helps. mcbbldfiles.zip

[josesimoes]

@smaillet-ms I've banging my head with this for several days now. Here's what I've found so far:

• the initialization of the heap and stack doesn't seem to be working properly, MDK seems to handle this by itself but GCC doesn't
• the scatter file seems to be missing something:
  • the RTX_stack is always empty and 0 size, which doesn't look right
  • the definition of the objects that are to be placed in the ER_RAM_RW and bss regions seem to wrong because they get all the objects from the lwIP regions as well
  • the lwIP heap and stack seems to be misplaced and it looks they are never init and zeroed in the code
  • the linker seems to be picky and case sensitive so I had to rename a couple of assemblies to be able to get the placement right (for socketshal*_lwIP_os, there were names with lwIP, LWIP and lwip)
• for GCC the PrepareRegions seem to be missing the code to zero and init the lwIP regions
• all the calls to the initialization of the RTXOS are missing. I believe that a call to software_init_hook() is due otherwise it won't work.
• on AppEntry.s for MDK the call to main seems to handle all the initializations and preparations for the RTXOS to work before calling the actual main. For GCC the main that is implemented seems to be missing stuff to make it work.

With what I have so far, I can load the image into DISCOVERY4, it boots, but then it gets stuck in a hard fault. There is an enumeration for the USB device but it fails and shows as an unknown device because it lacks the descriptor (I guess that this is a sign that it was starting to work but then it gets trapped in the hard fault) If you could take the time to review my changes in the following files I would appreciate it. There is a branch with this work here: https://github.com/Eclo/netmf-interpreter/tree/STM32F4DISCOVERY_NET_GCC

In particular: https://github.com/Eclo/netmf-interpreter/blob/STM32F4DISCOVERY_NET_GCC/Solutions/STM32F4DISCOVERY/TinyCLR_NET/scatterfile_tinyclr_net_gcc.xml https://github.com/Eclo/netmf-interpreter/blob/STM32F4DISCOVERY_NET_GCC/Solutions/STM32F4DISCOVERY/DeviceCode/Initialization/tinyhal.cpp

Thanks,

PS: btw, the initialization of NETMF is way convoluted!! It's very hard to follow it and try to make sense out of all that...

[josesimoes]

@smaillet-ms I found out that the * in the linker script doesn't work as expected. Meaning that LwIP regions definition aren't working. I've rework the scatter file to place the RW and BSS LwIP regions along with the main ones, but still segregated so they can be inited and zeroed as required. The globals Image$$ER_LWIP_OS$$nnnn are available in the code.

Please take a look at this commit and review it: https://github.com/Eclo/netmf-interpreter/commit/143e48be6ea13d05b2c94c57c39ddf6538481a42

It's not working yet, but it compiles successfully and I can see in the map file the vars and address contiguous just like in the MDK map, which wasn't happening before.

[josesimoes]

@smaillet-ms I've managed to successfully compile (with MDK) and load the image of the networked DISCOVERY4 solution. This confirms that GCC is not properly handling the initializations of RTX and possibly stack and heap too.

[smaillet-ms]

Best suggestion I have is to use the mbed website for a platform using the same SOC, create a simple test app that uses the RTOS (say two threads each blinking an distinct LED with a different delay in them) and export it as a makefile for GCC. Then try to adapt the code and settings into the NETMF build to get a simple "bootloader" e.g. if you can get the code to init and call into main(), you should be able replicate the rest from the MCBSTM32F400 networking solution. (This is actually what we did for running Llilum on mBed devices)