The 32l_lcd example is currently not working. This is noted in the code, which skips the GPIO configuration that would make it possible to use the LCD.
The following line occurs in the code: // fixme: GPIO_Init raises a bug in some gcc toolchains
And indeed, if the GPIO_Init lines are uncommented, attempting to compile gives an internal compiler error (ICE) in GCC:
main.c: In function 'main':
main.c:164:12: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6927
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make: *** [main.o] Error 1
I have done some searching online and have found that, though this is an ICE in GCC, it is not really a problem with GCC. It is triggered by invalid use of the attribute((naked)) keyword. The fix that GCC implementors are considering would simply change this from an ICE to a compile error. The basic issue appears to be that attribute((naked)) is intended for pure assembly functions, and not for the way it is used in the definition of main() in the 32l_lcd example. Because attribute((naked)) causes the compiler to not set up a stack frame for the function, almost any C code would have the potential of triggering the ICE.
So, I did a test, and removed attribute((naked)) from the definition of main(). This "fixed" the ICE issue, but I was unable to start the resulting ELF file on the Discovery board.
Why is attribute((naked)) needed on main(), and how can the project be repaired so that the attribute is not needed?
After writing the above, I noticed the setup_stack() function at the start of main(), which sets the stack up to the end of the SRAM area. I presume that it intended to compensate for attribute((naked)) in the definition of main(). So, then I guess the ICE in GCC occurs because GCC can't use a stack that has been set up manually?
I've had some partial success getting things to compile by creating a new main function that contains attribute((naked)) and attribute((used)) in the definition, and which only sets up the stack and calls out to another function that contains everything main used to contain. The idea being that the single call might be safe, and that the new function being called gets the regular prologue, epilogue and stack frame. This compiles, and partially works. I get it to flash the LEDs, but the program crashes when I introduce a call to LCD_GLASS_DisplayString().
LCD_GLASS_Init() and LCD_GLASS_Clear() do not crash.
It looks like the crash happens when stm32l_discovery_lcd.c calls out to LCD_UpdateDisplayRequest() in stm32l1xx_lcd.c.