Anyone using libmaple.a? « LeafLabs Garden

LeafLabs Garden » Development

Anyone using libmaple.a?

(10 posts) (4 voices)

Started 1 year ago by bobc
Latest reply from jonatan.olofsson

bobc
Member

I'm struggling to get my port of libmaple to Arduino 1.5.x working reliably. The problem is that the sketch I built doesn't run after it is downloaded. A reset doesn't help, but after a power cycle it runs fine. I'm pretty sure it is not hardware, the same thing happens on 3 different boards.

I have built the sketch using the Maple IDE (012), and also from the command line in libmaple, and those work fine.

I guess there is some initialisation not being done in my build. Trying to nail down the differences, a major one is that I build libmaple.a (make library) then link my sketch etc with it.

I searched for examples of people using libmaple.a, but all makefile examples I found link against *.o directly.

Tomorrow I will try without libmaple.a.

Posted 1 year ago #
ala42
Member

I always used libmaple.a separatly build with a makefile without using the maple IDE at all.
You need to spread some information to get help.
Do you just want to make the lib interface compatible or do you want to use a different compiler and IDE ?
What did you change in your port ?
Which board do you use to run your code ?

Posted 1 year ago #
bobc
Member

Sure, here is more info:

The goal is to create a "third-party hardware package" for use with the stock Arduino IDE 1.5.x, as described here https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5---3rd-party-Hardware-specification

To do that, I have taken the libmaple code, added a new boards.txt and platforms.txt files based on information in maple-ide, and written a small java tool to call dfu-util. I haven't made any code changes to libmaple files, but have moved files around to meet the requirements of the Arduino IDE. The ARM compiler is the one delivered with Arduino 1.5.7, which hails as "arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.3 20140228 (release) [ARM/embedded-4_8-branch revision 208322]"

The repo for this is at https://github.com/bobc/maple-asp

Hardware I am testing with:

Iteadmaple

http://imall.iteadstudio.com/development-platform/arduino/arduino-compatible-mainboard/im120411012.html

OLIMEXINO-STM32

https://www.olimex.com/Products/Duino/STM32/OLIMEXINO-STM32/

Baite maple mini ARM STM32

http://www.aliexpress.com/store/product/leaflabs-Leaf-maple-mini-ARM-STM32-compatibility/812021_1987703487.html

Do you have a link for "libmaple.a separately build with a makefile without using the maple IDE" ?

Cheers

Posted 1 year ago #
ala42
Member

There is a Makefile in the libmaple directory, simply call "make library".

I have tested my STM32F4 ported libmaple version with the aeroquad 3.2 code (https://github.com/AeroQuad/AeroQuad) lately with the latest launchpad arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors) 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147] without problems.

Posted 1 year ago #
bobc
Member

@ala42, thanks for the info. That gives me confidence to pursue the problem. I note that your version of libmaple is based on the leaflabs one around June 2012, there have been a few changes in the leaflabs source since then which may be significant (or maybe not!)

I have taken files out of the libmaple.a archive file until the sketch downloads and runs OK. That I think shows that at some level my compile/link process is good, and the issue is *something* to do with linking objects from the archive file.

I've had problems with weak symbols before, and my hunch is that it is something to do with that, as there are several place in libmaple where weak symbols are used.

Hopefully I can find the problem file by putting files one by one back into the archive file.

Posted 1 year ago #
ala42
Member

> I note that your version of libmaple is based on the leaflabs one around June 2012, there have been a few changes in the leaflabs source since then which may be significant (or maybe not!)

There are several changes in my version that are significant for sure :) One example is the nops I had to add in the micros() code because of the better gcc 4.8 optimization, otherwise the interrupt was too slow to intercept in time.

Posted 1 year ago #
bobc
Member

There are several changes in my version that are significant for sure :) One example is the nops I had to add in the micros() code because of the better gcc 4.8 optimization, otherwise the interrupt was too slow to intercept in time.

Nice one :) I think I was hitting that bug as well.

After more struggling, I have now got sketches to run reliably built using maple-asp. I have to have a copy of libmaple code for each variant, which is very messy. Sometime I will get a JTAG set up and have a more detailed look, but there are other things I want to look at. e.g. how to get drivers signed, how to download using ROM bootloaders, provide support for linux, etc

Thanks for your help.

Posted 1 year ago #
jonatan.olofsson
Member

The problem is that the sketch I built doesn't run after it is downloaded. A reset doesn't help, but after a power cycle it runs fine. I'm pretty sure it is not hardware, the same thing happens on 3 different boards.

I am having this issue with my maple mini right now as well! I have been replacing the makefiles with another buildsystem (tup), and have everything working great except for this issue. Do you know what fixed this particular problem, in your case?

Posted 1 year ago #
gbulmer
Moderator

Have you reduced the program to the simplest case, something like blink?

Have you tried comparing a small, simple, sketch built in a way which works with the same sketch built in a way that does not?

There are a few causes I can think of.

This probably is not the issue, but it is worth being clear. Are you loading to RAM intitially? IIRC, there was a period when there was a bug in the bootloader that might look like that problem.. If a program is loaded in RAM, the bootloader needs to know. however, part of the point of loading into RAM is to *not* load from there after a power cycle. So, IIRC, the bootloader sets a 'magic value' in RAM so that it would come back through reset and start at the program in RAM. However, it did not reset the magic value after a load into Flash. So it would keep trying to run from RAM until a power cycle destroyed the magic value. I thought it had been fixed, but maybe you have an old bootloader?

If you have a program that works when built by the Maple IDE, but not when built otherwise, try to compare the files.
A first step would be just check their sizes.

Within the Maple IDE package, there is gcc's nm and objdump. The nm program will give the list of symbols (functions and global variables) in a executable (before the IDE strips it down to a hex, IIRC). So a step would be to get the symbols in each file and then sort and compare the two lists, e.g. with sort | uniq, or sort the files then diff. If there are different symbols, then it may be clear what is happening.

If this shows very few differences, and it isn;t clear, then try objdump on each program to get an assembler listing, and diff those. If you are lucky, the order of the object files will be similar enough that the differences are clearer.

(Full disclosure. I am not a member of LeafLabs staff)

Posted 1 year ago #
jonatan.olofsson
Member

Thanks, gbulmer,

Great advices, it was of much use.

I did, indeed, use just a "blink" program. In the end, I had to ditch building/linking with libmaple.a, as it seems too much was stripped away by the linker if linked with the library.. Fortunately, this was trivial with my tup setup, so once I decided for that, it worked right away!

Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.