Llilum project build error MSB6006: "arm-none-eabi-gcc.exe"

[piwi1263]

After getting llilum sdk installed and trying a first project (no matter what board I choose) in ends up in a MSB6006: "arm-none-eabi-gcc.exe" exited with code 1.

Details: llilum_error_1.txt

I'm using ARM_GCC 5.0.

Any recommendations, would be more than welcome.

[piwi1263]

Don't if this is the way to solve it but by setting the timeval def in socket.h to 0 as documented, did the trick. The generated project when starting a new LlilumApplication was changed to board Nucleo-F411RE and compiled. However couldn't get it to deploy using VS, it started to wait for the board and kept on waiting, after canceling it via the menu build in VS, VS completely stopped reacting and I had to kill the application. However, using manual copy from the .bin file to the Nucleo drive getting from explorer seems to work just fine.

Any tips how to get the deploy working from within VS ? (Or should I raise a seperate issue for that ?)

TIA,

Peter.

[kail]

Hi Peter,

Since you are working with a Nucleo board, please have a look at the steps here: https://github.com/NETMF/llilum/wiki/Open-OCD-and-STM32-Board-Usage Please be sure to change the deploy tool to ST_Link v2 Utility or "Copy to drive".

Another problem you may be having is not having the latest firmware on your nucleo board, which you can fix by running the ST-Link v2 utility, connecting to your board, and clicking the update firmware button.

Hope this helps!

[kail]

As for the compilation issue involving sockets - are you trying to use sockets with the F411? If so, I don't think it's going to work, as there isn't an ethernet driver for that board. And if not, please let us know, as we will need to fix that issue.

[piwi1263]

Hi Mikhail,

thanks for the tip and link. It already improved by changing the deploy tools to use the open ocd and st link utitity. At least it deploys from within VS2015, but creates the folowing message:

And no I'm not trying to use anything towards the ethernet, it is just in the LlilumApplication template when starting a new project.

Any idea what file it might be looking for .... OpenOCD stuff ?

Thanks and kind regards,

Peter

[kail]

If this dialog is coming from an attempt to debug, I can take a guess: did you copy over OpenOCD and all of the required scripts into the openocd directory in your SDK/repo? Double check on that. Otherwise, go to your solution directory, and look for a file called tmp_debug.bat, then delete it, and try again.

[piwi1263]

Your guess was correct, after downloading, copying openocd bins etc to the two places as described in the link you provided a nice OpenOCD window shows (not that I've got anything from it since the program keeps going and does not seem to break at my first set break point. Actually all I'd like is to spit out some Debug.Print("...") stuff as in the netmf interpreter, but I reckon that is somehow, somewhat different ... or do I need to make some cpp function to print out that what I want ...

Is it possible at all just to output some simple text to the debug window in VS ?

P.S. If I hit the pause button in VS it does break and I can F10 step through the source.

[kail]

Unfortunately, printing strings to the GDB output window is not that easy in VS, as far as I am aware.

For an example of a function that we have used for debugging, search for DebugLog0 (should be in mbed_debug.cpp). You can also explore the codebase for how they are invoked (using fixed pointers to char arrays).

Your best bet right now will be to just use breakpoints when you need to inspect a value. Another option would be to use GDB from the command line, set a BP, then give it a command to print a string and continue (something like commands 1; x/s <string address>; cont; end) but I doubt you want to go that route

[piwi1263]

Thanks, already looking in the mbed_debug.cpp and then try to use printf and see where that ends up in what window. Any window is fine, I just need to see the text like a console output, that's a no brainer in netmf ...

The nucleos aren't that kind to visualisation ... does the serial on the arduino headers work, I could try some serial display I have, GFX or simple 2X16 chars ?

[kail]

Yep, serial should work. There used to be an issue with C# serial, when it would crash after 200-some chars, but I'm not sure if that still exists. For simple serial in C, add mbed serial code in DebugLog0 (i.e. serial_init, putc), and you should be able to get serial output over USB to TeraTerm or Putty. You should have access to that function by importing the Microsoft.Zelig.Support.mbed library or just adding [DllImport("C")] public static unsafe extern void DebugLog0(char* message, uint length); in your class.

[lt72]

I fixed the timeval issue with ba64434

[piwi1263]

Hi Lorezo,

thanks for looking into this.

Leaves me with the situation when a break point is set in VS in the managed project it doesn't break ?

Or should I close this and raise a new one, there are several more issues I have ... f.e. I get a red line on every uint32_t use in the native project, cpp members. The solution builds, deploys and does execute, however. I reckon these are cosmetic artifacts.

What is more disturbing is not being able to just do Debug.Print() in the managed project. Is that going to be supported in the end or do we have to look for alternatives ?

You have to know I'm used to the netmf interpreter goodies, so I'm quite spoiled ....

[lt72]

RE: "red line on every uint32_t" ==> interesting, and a bit strange since the header for uint32_t is included.. I'll check as soon as I have a chance and circle back.

RE: Debug.Print() ==> our solution for that at this stage is Microsoft.Zelig.Runtime.BugCheck.Log YES, I agree with you, it is annoying and I will fix this ASAP

RE: breakpoint: what do you mean exactly? if I understand correctly (and likely I am not) you are a) using the SDK b) deploying one SDK -based project to a dev board c) placing breakpoints in the managed code portion and d) you see the breakpoints but they are not hit

is that correct?

[piwi1263]

red lines -> this is not limited to uint32_t, some functions do get this as well. However, it DOES compile, build, deploy, execute. Strange but could live with for the moment, unless this is some root cause for all of my 'not exactly working as expected'

Debug.Print -> I'll try the log. See how far that gets me for the time being.

Breakpoint -> Correct. It does NOT hit the breakpoint in managed code. Using default sdk project and nucleo-411re board, with minor corrections to the config of course. LED1 blinks and I tried to use some port (D2) on the arduino header, works but stops after a while. The on board LD2 keeps on running, the seperate thread piece of code. The while loop ends for some reason. A bit odd. I made port D2 with a different speed to blink just to make sure my changes do get deployed, and run.

If you need more info about the versions or other info so you have some checkpoints for the basics or some sdk build log, or even the log for the llvm build ( it took appx 5 hours ). Please let me know.

Prio to me for this threesome -> Debug.Print, breakpoint, red liners.

Already thanks in advance for your efforts.