Fix to build Discovery 4 using GCC 5.4.1

[josesimoes]

• add new symbol to missing symbols for gcc scatter file
• add new-lib nano setting to tinybooter proj
• add platform emulated setting to solution settings
• add compiler flags to enable C11

[smaillet-ms]

What is it in Tinybooter that is requiring long-long and long-double formatting? Perhaps we should fix/remove that so we don't need to do this and can use newlib-nano?

Well actually scratch that, it seems like the comment is redundant as it is setting NewLibNano == true for GCC...

[cw2]

IIRC, the Tinybooter code does not require long-long and long-double formatting support, but the TinyCLR does (uses "%I64" and "%lld" printf formats). The newlib-nano included in GCC toolchain does not have those options enabled (i.e. long.ToString() and double.ToString() does not work correctly), so there are basically two options:

1. Use default newlib-nano in TinyBooter and standard newlib in TinyCLR,
2. Build a custom newlib-nano with long-long and long-double formatting support and use it in both TinyBooter and TinyCLR.

The ideal solution would be to use default newlib-nano in Tinybooter and a custom newlib-nano in TinyCLR - I guess that could be done with some additional tweaking of linker settings, but it would probably be too confusing...

Unfortunately, I have not yet had a chance to review the recent GCC versions, sometimes they introduce changes in newlib-nano, so if they for example added long-long and long-double formatting by default, it could made things a little bit easier.

[smaillet-ms]

Another option would be to change the CLR code so it doesn't use printf style formatting from the CRT for long and double and instead does it's own thing. Thus, allowing for newlib-nano in all cases. It would be ideal if we could figure out how to eliminate the duplication of the CRT completely (e.g. Tinybooter has a copy of the CRT and so does TinyCLR ) do we really NEED two copies of the CRT in the device?)

[cw2]

The obvious/naïve solution to eliminate Tinybooter's CRT is to eliminate the Tinybooter itself :)

[smaillet-ms]

A fair point, though it presumes that all devices have some sort of firmware update support built into the silicon to allow updates even if the main application image is completely hosed.

Doing that for NETMF requires some major re-work of the wireProtocol and debugger communication layers (and MFDeploy). Effectively abstracting out the entire wire protocol so that a plug-in of some sort could manage all the actions needed by MFDeploy to update the NETMF image. Unfortunately most such facilities built into silicon and devices requires some sort of external hardware/jumper to engage the update. (Although for development purposes the abstraction could also allow for standard JTAG/SWD/CMSIS-DAP access too which would provide full access and control [Yeah, I've been thinking about this one a while!])

[josesimoes]

I vote for changing the ToString implementation instead of sacrificing the newlib nano use.

[cw2]

I understand this is required to enable use of newlib-nano, but is it really worth it to use emulation on a CPU with a hardware FPU just to save a few percents of the firmware size?

ER_FLASH size built with GCC 5.4.1 and standard newlib is 327084, which is about 6% larger than 308380 reported in issue #474; the practical difference is even smaller due to the block size in the flash memory code area.

How about moving this setting to a separate 'size-optimized' solution?

[josesimoes]

Actually this because of the crypto libs. GCC link complains about a mismatch in the VFP flags between the crypto libs and the netmf. This has been discussed a number of times on other threads.

[cw2]

Ah, I have found the issues, thanks.

So, if I understand it correctly, this happens only when crypto.lib is used (resp. installed)? Because IMHO it would be much better to fix the cause in crypto.lib (as you suggest in the other comment) than modifying floating point setting (which would be needed for all solutions configured to use newlib-nano).