The good news: I tried out the TCPEchoServer example program with the online compiler and it works perfectly. The bad news: I exported it to GCC Arm Embedded and I get the following warnings/errors:

In file included from ./EthernetInterface/lwip/include/lwip/arch.h:43:0, from ./EthernetInterface/lwip/include/lwip/debug.h:35, from ./EthernetInterface/lwip/include/lwip/opt.h:46, from EthernetInterface/lwip-eth/arch/lpc17_emac.c:26: ./EthernetInterface/lwip-sys/arch/cc.h:83:0: warning: "ALIGNED" redefined [enabled by default] ./EthernetInterface/lwip-sys/arch/cc.h:82:0: note: this is the location of the previous definition

Fixed the above by commenting out line cc.h, line 83 Then got the following error:

In file included from /usr/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/include/c++/4.7.4/cstdint:35:0, from ./EthernetInterface/Socket/UDPSocket.h:25, from ./EthernetInterface/EthernetInterface.h:78, from main.cpp:2: /usr/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/include/c++/4.7.4/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options. make: * [main.o] Error 1

Fixed it by commenting out UDPSocket.h, line 25 Then got this linker error:

/usr/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/ld: TCPEchoServer.elf section `.bss' will not fit in region `RAM' /usr/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/ld: region RAM overflowed with stack /usr/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/ld: region `RAM' overflowed by 2040 bytes collect2: error: ld returned 1 exit status make: * [TCPEchoServer.elf] Error 1

I looked at the linker script and saw things like ETH_RAM and in the code saw sections like AHBSRAM0 AHBSRAM1, etc. So what is the status of the EthernetInterface library with regard to exporting to GCC and others?? I am not currently familar with linker scripts and memory sections, but I may have to learn??

Thanks!

As a short term solution, I can point you to my gcc4mbed project on github. It contains a sample called TCPSocket_HelloWorld that works with a slightly older version of the networking libraries. You can replace the main.cpp in that sample with the one from the echo sample and it should build with GCC and run successfully. If nothing else, you can grab this linker script from the same github repository: https://github.com/adamgreen/gcc4mbed/blob/master/build/mbed.ld

Longer term, I am working with the latest networking sources and GCC right now. I hope to issue a pull request later this week that fixes the issues that you mention above plus a few others I have encountered.

I hope that helps,

Adam

Thanks for the quick reply! Your mbed.ld linker script did get things farther along getting the linker to go ahead and create the binary. But apparently there are indeed other issues. The program hangs in the connect() function. For now I'll wait for you to perform your magic...

Thanks again,

Lester

I am a bit surprised that the linker script didn't get you up and running. That and changes related to what you mention already doing above are what I typically do to get the networking code to work. You should check that you have the latest RTOS code. I know that it used to cause a crash in GCC before but it has since been fixed. I can't remember if it was during the connect() though.

-Adam

I take that back! I guess I shouldn't have been surprised! I have received reports that similar connect() problems are still happening with the mbed sources on github even after they accepted my recent pull requests.

It turns out that I have changed some things in gcc4mbed over the last half year that allows the networking code to build and run with its makefiles but those same changes haven't made it into the official GCC solution. I think we are getting close to ironing out all of those differences.

Again, you can use gcc4mbed and start with its TCPSocket_HelloWorld sample. That should get you a good start with the networking stack on GCC.

-Adam

I downloaded your gcc4mbed and compiled up the TCPSocket_HelloWorld sample using your makefile and sources and everything works beautifully! I might play around a little more to see if it's your version of the networking source or your makefile that gets things going. Otherwise it looks like your good work just needs to bubble up to the mothership...

Thanks, Lester

Hi Adam,

I'm newbie to mBed, but I've learn a lot those past two weeks, facing different problems. Now I'm facing the same issues that Lester faced more than 15 months ago. I've did the same he did to workaround the compile issues, and the linkage issue using the mbed.ld, but runnning the resulting binary ends up with an CPU exceptions somehow. My board is a Mini-DK2, so when I've tried to use the gcc4mbed repository, it compiled with lpc_phy_dp83848.c, but I need to compile it with lpc_phy_lan8720.c since my board is Mini-DK2. I'm a bit confused there since the build process doesn't rely on Makefiles, where I should switch the good PHY ?

BTW, about the EthernetInterface generic integration for GCC, do you know latest status, because all the same issues are also faced when trying to compile things such as MbedFileServer_1768MiniDK2 project, but offline using GCC.

Thanks in advance,

Hi again Adam,

I've just saw your comment about "This may be related to https://github.com/mbedmicro/mbed/pull/812" related to my other problem, although workarounded, https://developer.mbed.org/questions/4672/Basic-RTOS-Thread-operations-not-working/?c=14999.

Is all those Aligment things can be releated, ie.: compile fine, but HardFault at startup before main() ?

Thanks in advance,

I would have expected the export to GCC_ARM to be working these days for TCP/IP based projects. If not, point me to a project URL and I will try exporting and investigating the build issues encountered.

Can you point me to a project which uses the lpc_phy_lan8720.c file with the online compiler. I would like to take a look and see how it works there. If you have that lpc_phy_lan8720.c file sitting in your gcc4mbed project, next to your main.cpp, does it get used instead of the lpc_phy_dp83848.c version?

How much do you know about the crash that you are hitting? Do you have a debugger attached so that you can share a call stack, etc.?

Thanks,

Adam

Hi Adam,

Since my discovery with rtos_basic example and you comment about alignment issue, I've played around and got some success out almost all examples, but sometime, I had to switch from one compiler to another to make things work (I've one that comes from crosstool-ng-1.20 and another one from gcc-arm-none-eabi-4_8-2013q4-20131204 ). (I've recently downloaded the gcc-arm-none-eabi-4_8-2014q3-20140805, but I didn't installed it yet). Which compiler works depends probably of resulting alignment since I've switch back and forth until I get something running for a specific project. I've got some success with "mbed_httpserver" project as well as "HTTPServer_echoback". To make them work with lpc_phy_lan8720.c, if I remember, I've borrowed the file from this location (but I think there is a copy also in the MakerBotServer) :

http://sw.lpcware.com/?p=lwip_lpc.git&a=tree&h=5286ee2b6cb6612d6e7e1e7a35c1b4eb4decfdc6&hb=7b84446afe97af955acad1d720696a0de73ab7cf&f=nxpcommon

I've then replace it in my mbed projects like Frank Vannieuwkerke had mentionned in the mbed thread http://developer.mbed.org/users/frankvnk/code/Mini-DK/, and also added the Mac address definition in my main.cpp as he said. With those receipes, I got success with the help of few printf().

About debugging, unfortunately, I'm not equiped with any JTAG dongle, so, the only tools I had was all those printf() ... :-( If you wish, I kept backups of some of the old samples that were not working such as the rtos_basic with the OBJECTS bad order linking. Maybe that can prove the alignment issue.

Thanks, Regards, Martin.

Hello Martin,

If those backups of failing samples are in the form of .elf files then I would love to see them :)

-Adam

Hi Adam,

For tonight, here is the rtos_basic example binaries (*.bin + *.elf) for which I had commenting all the calls to rtos but still linking with it, but hanging before reaching the main().

For other examples, I will need to find proper ones to avoid sending working ones ... :-)

Regards, Martin. /media/uploads/martinayotte/rtos_basic-badlinking.zip

Edit : In fact, I've tested this other one where I've also narrowed issue on linking order, the mbed_httpserver, I'm providing you the badlinked binaries ... /media/uploads/martinayotte/mbed_httpserver-badlinking.zip

Martin,

I just pulled down your two sample .ELF files and looked at the stack for the osTimerThread and they were both unaligned.

mbed_httpserver-badlinking

(gdb) p os_thread_def_osTimerThread 
$2 = {
  pthread = 0xf4d <osTimerThread>, 
  tpriority = osPriorityHigh, 
  stacksize = 2048, 
  stack_pointer = 0x10000279 <os_thread_def_stack_osTimerThread> "", 
  tcb = {
    cb_type = 0 '\000', 
    state = 0 '\000', 
    prio = 0 '\000', 
    task_id = 0 '\000', 
    p_lnk = 0x0 <rt_itv_wait>, 
    p_rlnk = 0x0 <rt_itv_wait>, 
    p_dlnk = 0x0 <rt_itv_wait>, 
    p_blnk = 0x0 <rt_itv_wait>, 
    delta_time = 0, 
    interval_time = 0, 
    events = 0, 
    waits = 0, 
    msg = 0x0 <rt_itv_wait>, 
    stack_frame = 0 '\000', 
    reserved = 0 '\000', 
    priv_stack = 0, 
    tsk_stack = 0, 
    stack = 0x0 <rt_itv_wait>, 
    ptask = 0x0 <rt_itv_wait>
  }
}

rtos_basic-badlinking

(gdb) p os_thread_def_osTimerThread 
$1 = {
  pthread = 0xd99 <osTimerThread>, 
  tpriority = osPriorityHigh, 
  stacksize = 2048, 
  stack_pointer = 0x10000271 <os_thread_def_stack_osTimerThread> "", 
  tcb = {
    cb_type = 0 '\000', 
    state = 0 '\000', 
    prio = 0 '\000', 
    task_id = 0 '\000', 
    p_lnk = 0x0 <rt_itv_wait>, 
    p_rlnk = 0x0 <rt_itv_wait>, 
    p_dlnk = 0x0 <rt_itv_wait>, 
    p_blnk = 0x0 <rt_itv_wait>, 
    delta_time = 0, 
    interval_time = 0, 
    events = 0, 
    waits = 0, 
    msg = 0x0 <rt_itv_wait>, 
    stack_frame = 0 '\000', 
    reserved = 0 '\000', 
    priv_stack = 0, 
    tsk_stack = 0, 
    stack = 0x0 <rt_itv_wait>, 
    ptask = 0x0 <rt_itv_wait>
  }
}

Note that the value of stack_pointer in both is odd and not 4-byte aligned:
0x10000279 and 0x10000271

Thanks for sharing that information. The PR for this stack alignment issue was accepted today so it should make it up to the mbed site soon.

-Adam

Hi Adam,

Thanks for all your efforts, it will make a lot of people happy, me included ! :-) To prove that you were in the right direction since awhile, I'm confirming that rebuilding the same mbed_httpserver-badlinking with you diff provided in the thread https://github.com/mbedmicro/mbed/pull/812, it fixed the issue.

diff --git a/libraries/rtos/rtx/TARGET_CORTEX_M/cmsis_os.h b/libraries/rtos/rtx/TARGET_CORTEX_M/cmsis_os.h
index f19a723..da63205 100644
--- a/libraries/rtos/rtx/TARGET_CORTEX_M/cmsis_os.h
+++ b/libraries/rtos/rtx/TARGET_CORTEX_M/cmsis_os.h
@@ -335,9 +335,9 @@ int32_t osKernelRunning(void);
 extern osThreadDef_t os_thread_def_##name
 #else                            // define the object
 #define osThreadDef(name, priority, stacksz)  \
-unsigned char os_thread_def_stack_##name [stacksz]; \
+unsigned int os_thread_def_stack_##name [stacksz / sizeof(unsigned int)]; \
 osThreadDef_t os_thread_def_##name = \
-{ (name), (priority), (stacksz), (os_thread_def_stack_##name)}
+{ (name), (priority), (stacksz), (unsigned char*)(os_thread_def_stack_##name)}

I presume that other potential cases mentionned in the thread will also be included in your PR ...

Regards,

It was @perkristian that did all of this work and not me. I see that his PR has been merged on github and propagated to this site as well so the issue should now be fixed.

Thanks aynway Adam, since you've at least inspired @perkristian ... :-) Ciao !