0

We use the ARM Embedded Toolchain based on GCC for our Cortex-M3 projects (arm-none-eabi maintained by ARM).

We lately upgraded from 7.2.1 to 9.3.1 in a project that uses GNU11 and GNU++14 and the newlib-nano (nano.specs) and the optimization level is set to Og.

We face some strange behavior that suddenly just at random one GPIO wont turn on/off anymore, this does not happen if we use 7.2.1. When stepping though the program to check why it wont turn toggle anylonger, all the commands are executed properly: initialization, and then writing a value to GPIO. Also noticable is, that if we change the optimization level to any other level (O0, 01, 02, 0s) it works again, seems that Og with 9.3.1 breaks something.

Then we went ahead and started searching which code section we must exclude from optimization (which function or which instruction) so it becomes runnable again. There we did not find a solution as its not one function call. At random by narrowing down, just by disabling optimization for a random function which has nothing to do with accessing GPIO, it works again.

Currently we have no idea how to proceed further in this matter, to find the root cause of this behavior.

Questions:

  • What did change between 7.2.1 and 9.3.1 when it comes to Gnu11/Gnu++14, the newlib-nano and Optimization for Debug (Og)?
  • How can this be explained that the older version seems to produce a runnable binary where the newer one causes issues?
  • How can you explain, why only Og causes trouble, but all other optimization levels seem to work just fine?

Any hint/input highly appreciated.

user654789384
  • 305
  • 1
  • 4
  • 21
  • It's really probable that you have a bug in your code. It happened to me switching from 7 to 9 in O3 that there were some new optimization using strd and ldrd that had emerged a problem with unaligned pointers. So before blaming the compiler search for your bugs. If then you find exceptional evidence of compiler bugs then we can talk about it but you should be very specific in this case. – Damiano Oct 21 '20 at 11:44
  • Hi @Damiano. Ya possible. My intention is not at all to blame the compiler. Its just what i have so far. Do you have some advice for me to find bugs, like unaligned access. How would you search for this? – user654789384 Oct 21 '20 at 11:47
  • The first thing that comes to my mind: have you tried to stopo with the debugger on the gpio toggle instruction and check if the register is written correctly, and the other gpio register are configured correctly and the peripheral is correctly clocked? You could use also the debugger to configure the gpio on the run and check if the levels changes. From there when you find what's missing you can step backwards to the source of the problem. Assembly inspection could be of help when you find the part that do not behave as expected – Damiano Oct 21 '20 at 12:34
  • gcc has not necessarily gotten better with time the output has somewhat gone downhill since 4.x/5.x to the present, but that doesnt mean buggy output, just possibly performance differences or size. So you may have a timing thing, but you shouldnt be that sensitive to this. You need to examine the compiler output (disassemble this code from each tool) to see the differences and see how your code caused the output. – old_timer Oct 21 '20 at 15:02

0 Answers0