building with GCC 5.2 2015q4 (NOT AN ISSUE)

[josesimoes]

Hi,

Wanted to share that I've successfully build STM32F4DISCOVERY solution with the new GCC 5.2. It seems that newlib nano can now be used. Check bellow the file sizes for that solution (just with the basic assemblies mscorlib, SPOT.Native, Hardware, Usb, SerialPort and Windows.Devices).

GCC 4.9 2015q3 Tinybooter 41812B ER_FLASH 322525B

GCC 5.2 2015q4 Tinybooter 42116B ER_FLASH 322445B

GCC 5.2 2015q4 with newlib nano enabled Tinybooter 42116B ER_FLASH 305209B

[josesimoes]

after soo much excitement :wink: I'm closing this non issue

[smaillet-ms]

Interesting that TinyBooter is actually slightly larger... Were there any build or code changes required for this? If so is there a pull request for them?

[josesimoes]

@smaillet-ms none whatsoever! I just rebuild it with gcc 5. For the second one I did change the project setting to enable newlib nano. On all builds I previously cleared the buildoutput folder.

[kmshim]

Hi, @josesimoes Binary images that has been built with GCC 5.2 2015q4 works fine? I faced to the problem that exception is occurred in the vsnprintf function.

[josesimoes]

@kmshim hi Yes the image was built fine and runs without any problem. When I say this understand that I've put up a simple "hello world" application that did run as expected.

When you say that you have an exception with vsnprintf, where is that exactly and how do you get there?

[kmshim]

hi, @josesimoes I have been porting netMF4.4 to TM4C1294KCPDT(TI, Tiva serises).

STDIO is specified for DEBUG_TRACEx.

Exception from DEBUG_TRACE4 of BootEntry in the tinyhal.cpp.

DEBUG_TRACE4( STREAM_LCD, ".NetMF v%d.%d.%d.%d\r\n", VERSION_MAJOR, VERSION_MINOR, VERSION_BUILD, VERSION_REVISION);

I have no debugger tools, just use UART for debugging. So I have insert code to dump registers when exception is occurred.

Simple information about exception as following.

r0 :0x00000001 r1 :0x0003e0b0 r2 :0x00000008 r3 :0x00000208 r12 :0xffffffff lr :0x0002c937 pc :0x0002c946 psr :0x01010200 BFAR :0xe000ed38 CFSR :0x00080000 HFSR :0x40000000 AFSR :0x00000000

And I have reviewed tinyclr.axfdump with the lr and pc registers. now I find that address is _svfprintf_r function that is called by vsnprintf. Unfortunately I have no debugger. so I can not debug any more. *. Attaching partial code of tinyclr.axfdump as following.

0002c918 <_svfprintf_r>: 2c918: e92d 4ff0 stmdb sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr} 2c91c: b0c1 sub sp, #260 ; 0x104 2c91e: 460c mov r4, r1 2c920: 9108 str r1, [sp, #32] 2c922: 4692 mov sl, r2 2c924: 930e str r3, [sp, #56] ; 0x38 2c926: 900a str r0, [sp, #40] ; 0x28 2c928: f7ff fb16 bl 2bf58 <_localeconv_r> 2c92c: 6803 ldr r3, [r0, #0] 2c92e: 9315 str r3, [sp, #84] ; 0x54 2c930: 4618 mov r0, r3 2c932: f003 f925 bl 2fb80 2c936: 89a3 ldrh r3, [r4, #12] --> here is specified by lr register 2c938: 9016 str r0, [sp, #88] ; 0x58 2c93a: 061d lsls r5, r3, #24 2c93c: d503 bpl.n 2c946 <_svfprintf_r+0x2e> 2c93e: 6923 ldr r3, [r4, #16] 2c940: 2b00 cmp r3, #0 2c942: f001 8138 beq.w 2dbb6 <_svfprintf_r+0x129e> 2c946: ed9f 7ba4 vldr d7, [pc, #656] ; 2cbd8 <_svfprintf_r+0x2c0> --> here is specified by pc register. 2c94a: 2300 movs r3, #0

I have checked if this problem is occurred with another gcc tool chain, MentorGraphics's Sourcery_CodeBench_Lite_for_ARM_EABI 4.8.1.

• binary image that is built with Sourcery_CodeBench_Lite_for_ARM_EABI 4.8.1 works fine.

[josesimoes]

@kmshim very interesting! Could you please send me an email?

[kmshim]

@josesimoes Thank for your interesting. kmshim@serialimage.com

[kmshim]

I figured out that exception is occured because newnanolib is not specified in the TinyClr.proj. After modifying false to true, the exception is not occurred anymore. It's my mistake. Thanks.