Loading examples

[Ozflip]

Am I allowed to ask yet another stupid question?

I've been trying for a couple of weeks to get the blink example into Eclipse. I've been using the File->Import->General->Existing Projects Into Workspace to get it in, but I then have to set all the include paths, etc, manually. And when I do, nothing actually builds.

I know I must be missing something blindingly obvious, but do you actually do your build in Eclipse and deploy to hardware and debug from there? If so, have I missed a tutorial somewhere?

The scons build works file, and I can run OpenOCD from the comand line per your examples, but I'm a wimp and IDEs make life so much easier.

Thanks.

Phil

[Andy Brown]

Hi Phil,

Yes I do all iterative development in Eclipse Kepler SR1 with "CDT 8.2.1" and "GNU ARM C/C++ Cross Compiler Support" (a.ka. the GNU ARM Eclipse plugin).

The main library must itself be imported and built first because its output will be referenced at the link stage. When you've built the library from Eclipse then you can build the examples.

All the include directories are set up to be relative to the workspace location so there should be nothing in there that's related to my PC.

Please let me know if that helps.

Regards,
- Andy

[Ozflip]

Thanks, Andy. I'm giving up .. I think I'm out of my depth. I've been banging my head on the desk for too many hours now!

I've tried with both Linux Ubuntu and CygWin.

The problem is getting the examples to build. They build fine with scons (and work when I send the bin to an STM32F4 discovery with the ST-Link utility), but as soon as I try to open one in eclipse (I've tried Kepler and Luna on both cygwin and ubuntu) they complain they can't find the includes. I have used a number of different workspaces, including the root stm32plus directory.

I right-click in the empty project list and import the projects in that directory - it sees the library and all the examples.

When I open a source file (say, blink), it complains the includes can't be found. I go to the C++ settings->files and directories, and I see the includes but there is an error about .cfg files at the top. Cl;ose and reopen that dialog and all the C++ settings (eg include directories) disappear.

It's almost taken over the last 3 weeks, and the frustration is immense. That's probably my own inexperience with gnu tools and Eclipse. Your actual code looks awsome, and that's why I've put so much effort into it.

I've been madly trying to find an STM32 environment that I could build reasonable Ethernet code in, but I think I need to surrender. Either that, or just use scons to build and a text editor to edit the code .. but how to debug it?

As I said - I think I'm just way out of my depth. Thanks for the help to date, and sorry to annoy.

[Andy Brown]

Hi Phil,

Sorry to hear that you're still having problems with it. This does concern me as I really want this to be as simple to use as possible. I'm putting together a new computer at the moment and so I have a clean environment available that I can use to try this myself. I'm going to document the steps required to get everything working in eclipse properly, step by step.

- Andy

[Ozflip]

Thanks Andy. It's obvious how much work you've put into this. I guess I should keep at it and be so lazy!

I think the issue is to do with importing projects. I'm trying to understand eclipse - I know VS bass-ackwards, but eclipse is close enough but different enough to keep throwing me off.

Anyway, when a project is imported it seems to not be able to find the configurations you have set up, and as a result it refuses to allow editing the various paths. If you install Juno instead of Kepler it goes further and will not event show the paths options.

In Kepler you get this kind of result when trying to set paths on an imported project:http://1drv.ms/1ruvlZd

I'll try starting from scratch instead of importing.

[Ozflip]

OK, getting closer. I was missing an Eclipse plugin, and I have had to fiddle a few include paths.

I'm now at the point where it almost builds, but fails with:

17:47:36 **** Incremental Build of configuration Debug_f4_168 for project stm32plus-examples-blink ****
make all
system/f4/System.d:1: *** multiple target patterns.  Stop.

[Andy Brown]

I can reproduce that error on one of my laptops but it never happens on my main desktop or other laptop (all Windows 7). It'll be environment-related for sure. I'll investigate it. I noticed that if you clean the project (right-click on project, "Clean Project") then you'll be able to build it, but only once until you clean again. Very odd.

[Andy Brown]

I can reproduce that error on one of my laptops but it never happens on my main desktop or other laptop (all Windows 7). It'll be environment-related for sure. I'll investigate it. I noticed that if you clean the project (right-click on project, "Clean Project") then you'll be able to build it, but only once until you clean again. Very odd.

OK I've got to the bottom of that "multiple target patterns" error on Windows/cygwin and it was environmental as I expected.

The problem is that the GNU ARM Toolchain does not come with a "make" or an "rm" command, both of which are required by the Eclipse plugin that does the build. When you run the build it tries to execute "make.exe" and finds the default cygwin "make" executable that does not seem to be compatible with the makefiles generated by the plugin.

We need to install the missing executables ourselves. Follow the instructions on the plugin author's webpage to install cs-make and cs-rm. What I did is just copy and rename (remove the cs- prefix) the two executables into the ARM Toolchain bin directory (same directory as the arm-none-eabi-gcc compiler) and I didn't have to modify PATH settings in Eclipse.

However the next problem I ran into was that two dependent DLLs were missing (you get a cryptic negative error number from make which translates to 0xC0000135 which means a library couldn't be loaded). I needed to download this archive and copy libiconv2.dll and libintl3.dll into the same bin directory as "make" and "rm".

After all that it worked on my misbehaving laptop

[Ozflip]

Thank you again, Andy. That fixed that - I can now build Blink, after I worked out that I have to remove the "lib" from the front of the library's actual name and the .a extension from the back in the project properties (why?).

Flashing from the hex file with the ST-Link Utility works.

So, now to work out how to flash and debug from Eclipse. I'll try to follow your webpage that your pointed out on another thread.

[Ozflip]

Last thank you - I have got the Button example debugging with OpenOCD (I'm not quite sure how I did it, but none the less...)

As I get an understanding of the framework, I'm hoping to get the TCP and UDP examples working. If I can, and they are reliable, you can congratulate yourself on having probably the only useful IP stack out there for ARM micros - at least in the free community. lwip is atrocious.

Thanks for all the hard work and the patience in putting up with noobs like me.

Phil.

[Andy Brown]

Cheers Phil, I'm glad you're there now. Any further questions, feel free to ask again.