ELF to EABI problems [SOLVED]

IoT Modules Development tools
1

Hi

I’m moving a working OpenAT application from the ARM ELF GCC toolchain to ARM EABI GCC toolchain.
The result is that AT+WOPEN=7 returns result 17: bad priority value.

By making small changes to the code, like commenting out lines that are not event executed, the application would sometimes run, but produce very weird results (30 < 3, false == true and so forth). I’ve verified that the compiler settings are the same as the ELF toolchain.

The app consists of a static lib and the main application, both written in C++. If I create a new application that doesn’t do anything but call a few methods in the static library, it works as expected. This leads me to believe the size of the app may be the issue.

Another weird symptom is that the status screen contains incorrect information: The first few character are cut off from the Name, Company, Version and some component names. This is the console output:

"DWL","V08b13","","Sierra Wireless",55344,"111611 18:03","dda36757","00010000"
"FW","FW_SRC_747_8.SL6087G","R7.47.0.201202010317.SL6087","Sierra Wireless",2221420,"020112 03:17","31be8644","00020000"
"OAT","525.1","ko","ac (Pty) Ltd",1341068,"052812 16:53","35e3915d","00260000"
 -"loper Studio","2.2.0.201205091434-R9457"
 -"Open AT Framework package","2.37.0.201202280640"
 -"Open AT OS Package","6.37.0.201202060950"
 -"Firmware Package","7.47.0.201202010317"
 -"Internet Library Package","5.43.0.201202100610"
 -"Security Plug-in Package","1.5.0.201108111447"
"ROM","800000"
"RAM","200000"
"DWLNAME","SL6087"

Note the “loper Studio” in stead of “Developer Studio”, 525.1 in stead of 2.2.525.1, “ko” in stead of “Sefeko” and "ac (Pty) Ltd’ in stead of “Gendac (Pty) Ltd”

More info:
-SL Series (SL6087)
-App is written in C++ with the required memory and eabi stubs included as documented
-App size: 1341068 bytes
-Single task: 3072kb stack size
-Newest Developers studio, with all patches applied (2.2.0.201205091434-R9457)
-Memory config: +WOPEN: 6,3712,1408 (I’ve changed this many times)
-Memory type: 256K / 1MB+ makes no difference.
-Optimization: I’ve tried -O0, -O1, -O2 and -Os - nothing makes a difference

I’ve changed every setting I could think of, but with no results. Does anyone have any advice?

2

Nothing obvious, unfortunately :frowning:
All I can suggest is to try introducing parts of your application (which is pretty big…) one after the other, in order to locate which part is introducing the “instability”…
Or maybe address your Sierra Wireless contact for a code review.

3

Thanks for the response.

The code is quite big at the moment, but this problem occured when it was a lot smaller as well.

I’m starting to suspect that the global variable section is being corrupted/overwritten. If something overwrites the adl_InitTasks, adl_InitApplicationName and others, it would explain the behaviour I’m seeing. The problem is that our task isn’t even run, so the code that overwrites the global variables must be some static object that is being initialized. I haven’t found anything like that yet.

I’ve used arm-none-eabi-readelf.exe and objdump to dump the .data and .bss sections. I haven’t really seen anything suspect yet. There are no C++ objects in the .data section. I’ve also double checked that we have no static class members anywhere.

I am in the process of cutting out parts of the code to see if the problem goes away, but it is slow going.

4

Can’t be: adl_InitTasks & adl_InitXXXName symbols are RO, so can’t be corrupted at runtime by your code.
If you can send me (in PM if you prefer) the smallest possible application able to reproduce the issue, we can have a look.

5

Hi
I’ve built a small application that contains fragments of our actual app and zipped it up for you. I would really appreciate it if you have a look as I’m stuck.

I’ve noticed one strange thing: DS intermittently tells me that “Running firmware requires 0x180 as Open AT application start address, but applicaiton to be downloaded was linked at 0x260000”. This problem normally goes away when I close and reopen the serial port.

6

Ok, we reproduce the issue here with the archive you sent.
We’re going to look forward in order to identify the root cause.

7

Thanks. Good to know that its not something specific to our hardware here.

8

Quick: I tested the newer compiler from CodeSourcery (4.6.1) and I get exactly the same behaviour. So it doesn’t seem to be linked to a specific compiler version.

9

Ok, so we found what’s triggering the bug, and how to fix it.
Actually, such kind of behavior occurs when you declare an Open AT application task entry point in a .cpp file. In the sample you attached, if the Main.cpp file is converted to a simple C file (i.e. simply renamed to .c), the behavior disappears.
No further explanation about this, but in this case, the tool which generates binary image (to be downloaded in the module’s memory) needs some more padding between various sections generated by gcc linker.
The bug will be fixed in 2.2.1; meanwhile you can either use the workaround mentioned above, or replace the file you find in plugins/com.wavecom.openat.ide.ebs.armelfgcc_xxxx/scripts directory by the attached one.
Let us know if it’s ok for you.

10

Thank you very much for the solution. Initial indications are that it works.

I first tried to define the task in a c file, but that didn’t seem to work. Replacing the the script did work however.
I will however play around a bit with the task definitions, as replacing the scripts on each developer’s machine is not ideal, but OK for now.

Two questions:

  1. Any indication on when 2.2.1 will be available?
  2. I get AT+WOPEN=7 => 7,8 when I use the test app I sent you earlier. The help file indicates that its a link problem (The application global variables area initialization is not possible). Is it because the test app is so simple an has no global variables?
11

Good to hear that the solution is working.
About your questions:

  1. 2.2.1 release is a matter of days; it will be released within the end of June.
  2. Actually there can’t be no global variables at all, since both ADL & standard libs have their own global variables. Anyway, we don’t reproduce this +WOPEN:7,8 behavior with your test app. When simply import the project + apply the patch, the app is running fine.

Please tell us if you encounter issues, to let us fine tune the fix if needed before the 2.2.1 release.

12

I’ve been testing the solution for the last few days and I can confirm that it is working. Thank you very much.

The only issue I’ve encountered was with decoding backtraces. So far, I get the following error every time I try to decode a backtrace:

An internal error occurred during: "Decoding Backtraces in progress".
Java heap space

This is even with only one, relatively short backtrace:

Invalid memory API call
	Unknown function (67250)
	Unknown function (34387)
	Unknown function (3443d)
	Unknown function (2fee7)
	Unknown function (208d5)
	Unknown function (2e240b)

The only reason I mention this here is that backtraces used to work with the ELF compiler. Is it possible that the backtrace decoding has a problem similar to what you found in the fromelf.py script?

13

Thanks for the feedback.
Sounds like your app is pretty big. When DS tries to decode backtraces, it has to parse the application binary, which seems to lead DS to run out of memory.
You should have a look to DS help page concerning memory configuration (Getting Started > Memory Configuration)
This will help giving more memory to DS.

14

Thanks, tuning the memory parameters did the trick