Forum > Embedded - ARM

Compiler bug on arm embedded: How to identify, how to report?

(1/3) > >>

kupferstecher:
Hi,

lately I did some tests with arm embedded, compiling for the microcontroller STM32F103C8 (Cortex M3). Building the cross compiler worked fine, I got LEDs flashing toggled by a timer interrupt, the serial port is sending data and a 1602 text display also works.

The first error, where I blame the compiler: After some code changes (I ported my first program version using the firmware lib [from here: http://www.j-software.dk/stm32f103.php] to direct register calls) in the ISR of the timer interrupt the program crashed when the timer interrupt was enabled the first time. Even having an empty ISR resulted in a crash. But including a random procedure call (e.g. serial port or delay) helped to prevent the crash. Probably the whole ISR was optimized away by the compiler. Changing the optimization level from -O3 to -O0 helped to solve that problem.

The second error: I tried to port some c-code using an I2C interface to connect to a sensor. In the initialisation phase I call an init procedure of the sensor unit. After including this procedure call the program seems to crash directly at startup. Means only having this procedure call corrupts the complete code, even if its never reached. If I comment out the init call, then the programm starts normally with flashing LED, some delays and status messages via the serial port, everything before the code reaches the position of the init call. But if the init call is there, then no LED will light up and no single byte of a status is transfered through the serial port, that means the code is corrupted from the very beginning. Again when I add a random procedure call within the I2C-init-procedure, for example sending a status message through the serial port, then the program will start corectly and reach the initialisation code. Removing such call than the programm again won't startup at all. Changing compiler optimisation settings didn't help in this case.

My question is now, how can I identify such problems so that I can report them. Obviously its a very target specific problem and it arises in the larger context of the program.

I have a debugger connected to the microcontroller, so I could check on which address the programm got stuck, but with the bare address I have no idea in which pascal line this is. For the first issue I'd like to know if the ISR-Procedure is even linked by the linker (it exists as assembler code), but there is no hint in the binary about the procedures or anything. Debug symbols or procedure names are always stripped away, no matter if I change the compiler settings (e.g. -Xs).

Sure I can provide the code to anyone who could try to help, but I don't want to publish it here because the code is still a bit messy. Attached the timer unit for the timer interrupt as reference / example.

Thanks for any suggestions!

mse:

--- Quote from: kupferstecher on June 25, 2017, 10:42:44 am ---I have a debugger connected to the microcontroller, so I could check on which address the programm got stuck, but with the bare address I have no idea in which pascal line this is.

--- End quote ---
I use MSEide to do source level debugging of M3 chips of Silicon Labs (EM32 Tiny Gecko). In order to debug the chip is connected with a demo board from Energy Micro which has a Segger J-Link debugger chip with an USB port for connection to the development PC. On PC there runs an instance of a gdb-server proxy. MSEide connects the gdb-server for debugging. I use gcc as compiler but I assume it should work with FPC too.
Maybe a similar environment can be setup with ST-chips too?

kupferstecher:
Hello mse,

like you have the segger J-link, I have a ST-Link, also connected to the computer with USB . It provides debugging via JTAG and SWD, so from hardware side it should be no problem. But from software side I have no idea how to do the setup. I read some articles (e.g. http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips), also on the internet about gdb etc., but still I have no clue. Do you or anyone else know where to read about some details?

"GDB server proxy" may be a good keyword. I checked in my Em::blocks installation, there is a STLinkGDB.exe with description "STLINK GDB Server (EmBlocks Mar 18 2014 11:17:29)", promising?

Regards

mse:

--- Quote from: kupferstecher on June 25, 2017, 11:48:15 am ---"GDB server proxy" may be a good keyword. I checked in my Em::blocks installation, there is a STLinkGDB.exe with description "STLINK GDB Server (EmBlocks Mar 18 2014 11:17:29)", promising?

--- End quote ---
Yes! For a first step I would try to run the server and to connect the server with a commandline gdb. I can't help much because I work on Linux and I don't know the ST-environment. I can connect the J-Link server in gdb with

--- Code: Text  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---target remote localhost:2331 

Laksen:

--- Quote from: kupferstecher on June 25, 2017, 10:42:44 am ---The first error, where I blame the compiler: After some code changes (I ported my first program version using the firmware lib [from here: http://www.j-software.dk/stm32f103.php] to direct register calls) in the ISR of the timer interrupt the program crashed when the timer interrupt was enabled the first time. Even having an empty ISR resulted in a crash. But including a random procedure call (e.g. serial port or delay) helped to prevent the crash. Probably the whole ISR was optimized away by the compiler. Changing the optimization level from -O3 to -O0 helped to solve that problem.

--- End quote ---
You might have triggered a bug which is in the stack frame optimization code. Do you have a small piece of code where you see this in?


--- Quote ---My question is now, how can I identify such problems so that I can report them. Obviously its a very target specific problem and it arises in the larger context of the program.

--- End quote ---
Debugging or tracing would be the smart way of doing it. What could happen is that one of the exceptions are triggered, which will jump to the default ISR handler. This is just an infinite loop. It would be wise to override those so you can write debug info for those cases. You can compile the RTL with debug info when you build a crosscompiler. That might show some line info. You can do that with CROSSOPT="-g"

Navigation

[0] Message Index

[#] Next page

Go to full version