Offline GCC compiler works with mbed libraries!

# 12 Oct 2015

A new version of GCC4MBED is available on github at https://github.com/adamgreen/gcc4mbed#quick-start

New features include:

Upgraded GNU tools to GCC ARM Embedded 4.9-2015-q3-update.
Upgraded mbed SDK from revision 100 to revision 108.
The developer can now provide a list of subfolders containing library code to be compiled and linked into their binary. This allows the same library code to be shared across multiple projects without duplication as currently required. The samples/BLEHeartRate/ sample shows the use of two libraries in the samples/BLElibs/ folder: USER_LIBS := ../BLElibs/nRF51822 ../BLElibs/BLE_API
I also added two more rules:
- clean-libs which can be used to delete the output files in the library folders to force a full rebuild of the USER_LIBS folders.
- clean-mbed which can be used to delete the output files in the mbed SDK to force a full rebuild of the SDK.
- The clean-all rule now issues a clean, clean-libs, and clean-mbed.
Added support for NUCLEO_F103RB and NUCLEO_L053R8
- NUCLEO_F103RB support was added by KenjutsuGH
- NUCLEO_L053R8 support was added by Ashier de Leon
Other patches from the community. Thanks!
- Added more specific detail in the instructions from Wiredhome.
- add TOOLPATH for the binaries, can be overriden from Jim Morris.
  - Now defaults to using the GNU tools installed in the gcc-arm-none-eabi/ subdirectory of the gcc4mbed project. Previously it used the PATH. It can still be overridden by using the GCC4MBED_TOOLPATH environment variable.
Renamed LPC_DEPLOY environment variable to GCC4MBED_DEPLOY as it is no longer specific to NXP LPC parts.

A new version of GCC4MBED is available on github at [[https://github.com/adamgreen/gcc4mbed#quick-start]] New features include: * Upgraded GNU tools to **GCC ARM Embedded 4.9-2015-q3-update**. * Upgraded **mbed SDK** from revision 100 to **revision 108**. * The developer can now provide a list of subfolders containing library code to be compiled and linked into their binary. This allows the same library code to be shared across multiple projects without duplication as currently required. The samples/BLEHeartRate/ sample shows the use of two libraries in the samples/BLElibs/ folder: {{{USER_LIBS := ../BLElibs/nRF51822 ../BLElibs/BLE_API}}}\\ I also added two more rules: ** clean-libs which can be used to delete the output files in the library folders to force a full rebuild of the USER_LIBS folders. ** clean-mbed which can be used to delete the output files in the mbed SDK to force a full rebuild of the SDK. ** The clean-all rule now issues a clean, clean-libs, and clean-mbed. * Added support for **NUCLEO_F103RB** and **NUCLEO_L053R8** ** NUCLEO_F103RB support was added by [[https://github.com/KenjutsuGH | KenjutsuGH]] ** NUCLEO_L053R8 support was added by [[https://github.com/ashier | Ashier de Leon]] * Other patches from the community. Thanks! ** [[https://github.com/adamgreen/gcc4mbed/commit/46d250fd0cc4de4e007ffe7e93d75c815868d29c | Added more specific detail in the instructions]] from Wiredhome. ** [[https://github.com/adamgreen/gcc4mbed/commit/c35eb0b34c9827aa60b1f157bd12abf544d0c3e1 | add TOOLPATH for the binaries, can be overriden]] from Jim Morris. *** Now defaults to using the GNU tools installed in the gcc-arm-none-eabi/ subdirectory of the gcc4mbed project. Previously it used the PATH. It can still be overridden by using the **GCC4MBED_TOOLPATH** environment variable. * Renamed **LPC_DEPLOY** environment variable to **GCC4MBED_DEPLOY** as it is no longer specific to NXP LPC parts.

# 29 Jan 2016

First of all congratulations on all the work! It's of great help :D I'm using windows and i found some minor adjustment necessary in the mk files, is anyone having issues with windows?

# 30 Jan 2016

I have had no issues with it under Windows 7 which is where I usually test it. What type of issues are you hitting and what did you have to change to get it to work? In the past, the most common issues that I have seen Windows users hit are due to some Posix-like tools (Cygwin, MinGW, ...) getting picked up and used. This causes problems since I have written the makefiles to work on plain vanilla Windows without these tools. You could be hitting something related or an entirely new type of issue.

# 30 Jan 2016

I didnt make it in the end, I kept having errors and it was probably due to ming getting in the way as you said :) I started or with a new clone and it worked, I'm not sure what I have done differently though :P

I guess I'll remove mingw from the system path, just to be sure :)

One thing i'm still having problems with is the debug compile. Is compiles correctly but the bin produces does not get flashed when I copy it to the board.it's a nucleo 401 :) releases does work instead :)

# 01 Feb 2016

Simone Boscaratto wrote:

One thing i'm still having problems with is the debug compile. Is compiles correctly but the bin produces does not get flashed when I copy it to the board.it's a nucleo 401 :) releases does work instead :)

Really the only difference between a Release and Debug build for the Nucleo 401 boards should be whether the code is built with optimizations turned on or off. I would recommend performing a "make clean" when switching between Release and Debug build types.

What do you mean when you say that it doesn't get flashed correctly?

# 09 Feb 2016

The file is copied in the nucleo drive, but the board does not flash it and make the file disappear, like it does with a working file :) I guess I need to try to flash it with the st link software and see if that helps.. For the makefile, I had to edit gcc4mbed.mk, it makes an explicit reference to LPC1768-deploy which is not my board: P Btw sorry for the late reply xD

# 10 Feb 2016

Simone Boscaratto wrote:

The file is copied in the nucleo drive, but the board does not flash it and make the file disappear, like it does with a working file :)

Sorry I can't help more with that. Maybe Larry Littlefield can offer some advice.

Simone Boscaratto wrote:

I had to edit gcc4mbed.mk, it makes an explicit reference to LPC1768-deploy which is not my board

The only thing that should reference LPC1768-deploy is the deploy target itself. The solution to that should be simple. Don't use the deploy target from the command line but instead use the NUCLEO_F401RE-deploy target appropriate for your board. Originally gcc4mbed only supported the LPC1768 platform and that is when the deploy target was first created. When other platforms were added, new platform specific deploy targets were added as well and the old deploy target was defaulted to LPC1768 so that existing users wouldn't be impacted.

You could add a line like this to the end of your project specific makefile so that you can use make dep401 to deploy to your board so that you don't need to type out such a long target name:

dep401 : NUCLEO_F401RE-deploy

-Adam

# 12 Feb 2016

A new version of GCC4MBED is available on github at https://github.com/adamgreen/gcc4mbed#quick-start

New features include:

Upgraded GNU tools to GCC ARM Embedded 5-2015-q4-major.
Upgraded mbed SDK from revision 108 to revision 113.
- DISCO_F429ZI support was added by JaredCJR.
  - Includes MRI debug monitor support for GDB debugging via serial connection when using Debug builds.
Other patches from the community. Thanks!
- Makefile: do not force user to name its Make file makefile from Clement Leger.

# 13 Feb 2016

I am installing gcc4mbed on Eclipse Mars.1 Windows 8.1. The initial samples compile ok (even with 17 errors) on LPC1768. Error as it enters debug /media/uploads/kg1/gcc4mbedconf14.png Any help would be much appreciated. Regards, Kevin.

# 13 Feb 2016

Kevin,

I don't know much about Eclipse but maybe someone else can look at your screenshots and see an obvious problem.

You could try setting up a debug session using the command line tools just to gather another data point of whether it works there or not. I have notes for how to do that here. If that fails too, I should be able to help you diagnose and correct the problem.

-Adam

# 13 Feb 2016

I can help for the errors you get in the source code, eclipse shows errors because with gcc4mbed you use an external make, and eclipse does not parse iT, it just executes it for the build. I had the same problem, and resolved it configuring the include paths adding those of mbed.

You can follow the eclipse help here I added these:

yourpath/external/mbed
yourpath/external/mbed/libraries/mbed/target/cmsis
yourpath/external/mbed/libraries/mbed/hal

Plus all the other sub folders of your specific board in

external/mbed/libraries/mbed/targets/hal
external/mbed/libraries/mbed/targets/cmsis

/media/uploads/kg1/eclipse2.txt

# 14 Feb 2016

@Adam, Thank you for your replies. Adam please look through the following errors in the text file:

/media/uploads/kg1/gcc4mbedinstall1.png

I would appreciate your advice.

Thank you,

Kevin

# 14 Feb 2016

Kevin, I just skimmed through your text file and one thing I noticed is that your make command is failing at some point so it isn't clear to me if it is actually even building the LPC1768 binary with debug support enabled. You should use make clean deploy instead so that it only tries to build for the LPC1768 target. Many of the smaller platforms will fail to build in Debug because the unoptimized code is too large to fit on the device.

You connect with a terminal program to a HelloWorld sample but don't say what the result of that really is. The HelloWorld sample wouldn't really do much with a terminal program anyway since it just blinks a LED. If the binary was really debug enabled then sending +$#00 should cause the mbed to respond in kind. If it is debug enabled it should also halt before the blinking even starts so if you see blinking then you don't have a debug enabled binary.

I have no idea why your text file is showing the building of the HelloWorld sample but you attempt to debug the FileTest binary instead. Just pick one of them and do all of your testing with it.

Your attempt to run GDB should have produced a mri.log file. Seeing the contents of that might help to diagnose the problem as well but looking at the errors that you are getting I suspect that the mbed just isn't responding. Likely causes:

Not using a Debug enabled binary but a Release one instead.
Using the wrong COM port with GDB.
Not using the 21164 firmware in the mbed interface chip. A type H:\mbed.htm should display output verifying if this is the firmware running in the mbed.

/media/uploads/kg1/mri.log

# 15 Feb 2016

Thank you for your prompt reply. I will work on your email within 10 hours but for now here is the mri.log file.

Regards,

Kevin.

# 15 Feb 2016

Kevin Gordon wrote:

I will work on your email within 10 hours

Sounds good!

The mri.log contained what I figured it would, GDB sending commands to the serial port but nothing ever coming back. I would definitely recommend checking that you aren't encountering any of the 3 issues I listed in my previous post.

/media/uploads/kg1/mri_qayd9GH.log

# 15 Feb 2016

Thank you Adam,

I installed mbedmicrocontroller_21164.if then continued with https://github.com/adamgreen/mri/blob/master/notes/mri-getting-started.creole until this:

(gdb) backtrace
#0  _start () at ../../src/gcc4mbed.c:40
#1  0x00005288 in Reset_Handler ()
    at ../../external/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC176
X/TOOLCHAIN_GCC_ARM/startup_LPC17xx.s:149
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

HOWEVER I continued to the end of your mri-getting-started which seemed ok. Does this need fixing? (corrupt stack?) I have attached the current mri.log.

Should I continue with https://developer.mbed.org/cookbook/eclipse-for-building-and-debugging ?

Thank you for your help.

Regards,

Kevin.

# 15 Feb 2016

You can ignore that error when you are stopped in _start(). If you got through the rest of my MRI getting started guide then you appear to have it working well, from the command line at least. Maybe the interface firmware fix will help with your Eclipse issue as well?

# 15 Feb 2016

Thank you Adam, I will press on. Kevin.

/media/uploads/kg1/eclipse5.txt

# 16 Feb 2016

Adding New Devices to GCC4MBED NUCLEO_F446RE

What firmware should I be using for NUCLEO_F446RE ?

Should I load HelloWorld.bin using the ST-LINK utility software from ST Microelectronics?

Regards, Kevin.

# 16 Feb 2016

The MRI debug monitor can only used for the LPC1768 device. For other devices you will need to use something like CMSIS-DAP or whatever other debug solution is offered for your board. I am not familiar with STM parts so I can't offer much help in that area.

# 16 Feb 2016

Thanks Adam. Perhaps someone who worked on the other NUCLEO boards may be able to look at my attached text file. The make process successfully made the HelloWorld.elf etc files. I need help with the remaining steps to successfully debug.

Regards,

Kevin.

/media/uploads/kg1/eclipse7.txt

# 17 Feb 2016

Good progress!

More tomorrow.

# 18 Feb 2016

@Adam. Please review my web-page. I would appreciate any feedback. Regards Kevin. http://www.rescuerobot.org/drupal/?q=content/best-free-offline-ide-mbedorg-projects

# 19 Feb 2016

Kevin,

Looks good to me! I am glad that you got everything working as you wanted!

-Adam

# 19 Feb 2016

You are doing a great job Adam. Thank you for your support.

Regards, Kevin.

/media/uploads/kg1/k64f-device.mk

# 26 Feb 2016

Hi Adam,

I have been working on a make file for the K64F platform (attached above). Please take a quick look through, especially at ASM_FLAGS and LD_FLAGS, and comment. Perhaps some could be removed?

Regards,

Kevin.

# 29 Feb 2016

Hello Kevin,

I don't see anything obviously wrong with it. Does it work for you?

You can probably remove these flags if you want: -fmessage-length=0 -fno-builtin

-Adam