Use of Adafruit SSD1306 brakes DFU

I have RobotDyn Black Pill with SSD1306 OLED attached to I2C1 with proper pull-ups.
I’m using latest versions of bootloader, Arduino_STM32 files and unmodified Adafruit GFX and SSD1306 libraries.

Following code, stripped to minimum :
#include <Arduino.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

Adafruit_SSD1306 display;

void setup()
{
pinMode(LED_BUILTIN, OUTPUT);
display.begin(SSD1306_SWITCHCAPVCC, 0x3C); //this line is sufficient to trigger described effect
display.display();
}

void loop()
{
digitalWrite(LED_BUILTIN, LOW);
delay(100);
digitalWrite(LED_BUILTIN, HIGH);
delay(500);
}


Just to clearify:

This board (or same pinout): http://wiki.stm32duino.com/index.php?title=Black_Pill

This bootloader: http://wiki.stm32duino.com/index.php?ti … ws_machine

Which core: “Arduino_STM32 files” ? Perhaps “Roger’s core” https://github.com/rogerclarkmelbourne/Arduino_STM32
IF so, did you select as stated in #3 and #4
Getting Started
1. Buy a Black Pill
2. Burn the bootloader
3. Under ‘Tools → Board’ select “Generic STM32F103 series”
4. Under ‘Tools → Upload method’ select “STM32duino bootloader”
5. Select the correct COM port
6. Open up the blink sketch, change the pin number to PB12
7. Hit upload

My board is exactly this : http://wiki.stm32duino.com/index.php?ti … Black_Pill

I’m using “Roger’s core” https://github.com/rogerclarkmelbourne/Arduino_STM32
and his bootloader : https://github.com/rogerclarkmelbourne/ … n?raw=true
My board is set up properly.

I have worked on my program for some time, and all was right with DFU, until I introduced SSD1306 OLED and code for it. The display works from start, but in the same time DFU stopped working. If I comment out code that handling OLED then DFU works again.

I’m using PlatformIO within Visual Studio Code, and there is a gcc 7.2.1 in it. Now I remembered that when I compiled Espruino firmware for STM32F4 with gcc 7.x it partially or at all not worked. Maybe here is the cause (too agressive optimizations) ?

[shodan8192 – Mon Sep 03, 2018 8:21 pm] –
I’m using PlatformIO within Visual Studio Code, and there is a gcc 7.2.1 in it. Now I remembered that when I compiled Espruino firmware for STM32F4 with gcc 7.x it partially or at all not worked. Maybe here is the cause (too agressive optimizations) ?

If you like it or not, it’s a good idea to run the standard Arduino IDE as recommended before trying things like Sloeber, PlatformIO and other things.
First: You’ll have the software setup wich is approved to work with STM32duino, second you can strip down the malfunction to it (or not, then we are going to help you further!)
So does the code (library) works with the standard IDE?

So does the code (library) works with the standard IDE?
After copy arm-none-eabi toolchain (which is 4.8.3-2014q1) from Arduino IDE to PlatformIO and recompiling program, OLED and DFU now works together.

And there my questions are : it is possible to get fully working program using latest arm toolchain ? What exactly causing problems ? Maybe there are some flags to force compatibility with olders toolchains ?

I also have some problems with gcc 7 q1 release.
It is very cumbersome to identify compiler bugs, so you are better served with a tested working version than searching for a needle in the haystack.

So, OK, I have to stick with toolchain from Arduino IDE.

For me it’s difficult to accept that I cannot use newer toolchain (I have also checked on gcc 6.3.1 with no luck)

The 4.x gcc is actually quite buggy. A number of bugs have been fixed in the newer versions which can change the way code is compiled. The compiler will almost always emit a warning when it compiles code which would have compiled differently in earlier versions.

Try set the ‘verbose’ preference, and see if you can spot anything in the compiler output?

Compilation with gcc 7.2.1 gives additional warnings in compare to 4.8.3 about misleading intendation in SPI library, which I don’t use (included from Adafruit oled lib). None of warnings looks relevant in problem of DFU.

Fix for newer gcc has been merged into STM32duino-bootloader, so tomorrow I will try to compile it with gcc 7 and see if it play well with user code built with the same version.

[shodan8192 – Tue Sep 04, 2018 10:05 am] –
So, OK, I have to stick with toolchain from Arduino IDE.

For me it’s difficult to accept that I cannot use newer toolchain (I have also checked on gcc 6.3.1 with no luck)

I hear this attitude far too often. You cannot do what you want and all of a sudden, it is a forum problem /NOT.

This forum is named, “Arduino for STM32” and that means use of the Arduino IDE and as much Arduino behavior and syntax that can be rolled sensibly within the core. Where syntax differs, it is almost always to support enhancements in the STM32 uC.

The cores, both STM32 by Roger (from Leaflab) and the Official STM32 core by STM and the Generic core are all intended to be used with the Arduino IDE. Moving outside this limited, “tested” environment is your liability. A number of members use Slober and there is a thread which shares lessons learned; but it is not common forum business. You are welcome to post under the IDE section but it is inappropriate to post under the “General” section.

Ray

[shodan8192 – Tue Sep 04, 2018 8:15 pm] –
I will try to compile it with gcc 7 and see if it play well with user code built with the same version.

I have compiled STM32duino-bootloader with gcc 7.2.0 and it works, but nothing has changed.

[mrburnette – Wed Sep 05, 2018 1:25 am] –
You are welcome to post under the IDE section but it is inappropriate to post under the “General” section.

When I started this thread, I had no idea where the problem is, so I posted here. Now, not only section is inappropriate but also a topic. It should be like “In some circumstances DFU stop working when program was built on PlatformIO with GCC 7.x”

It can’t be excluded that in future ARM toolchain get upgraded in Arduino IDE, and then more users will have problem like me. I will continue investigate and if I find solution I will post it under “IDE” section.

As it turns out, that the problem can also apply to any IDE and compiler version i have posted description and solution here : viewtopic.php?f=53&t=4125