Release builds only work with opt-level = 0/1 about ssd1306 HOT 10 CLOSED

Hm, strange. What device and Rust version are you using? I haven't needed to add opt-level to my STM32F103 projects to get them to work which is odd. I'll dig out my SPI display if I find some time and try to repro. Do you have an I2C display you can test with?

from ssd1306.

Using the latest nightly, with a bluepill, on Mac OS. I'm testing on my Ubuntu machine now. I'm afraid I had to cut some traces on my SSD1306 to use the SPI interface, so I don't have any I2C displays :(

from ssd1306.

Tested, no dice. I flash with opt-level=1 and it works, flash with opt-level=s and it doesn't. Do you normally build on the debug profile?

from ssd1306.

I'm always compiling with opt-level=s and never had such a problem.

I just tried an example of my nucleo-f042k6 crate and it worked just fine with opt-level=s.

@jamwaffles NB: We should release a new version to fix crates using ssd1306 as dependency.

from ssd1306.

I just tried cargo run --example blinky_i2c --release and got a panic in GDB (macOS, Rust 1.27.0 nightly 2018-05-15). --release implies opt-level=3 according to the defaults in the manifest. @Chocol4te do you get the same thing?

Adding various opt-levels to [profile.release] in Cargo.toml is odd:

• opt-level = 0 works
• opt-level = 2 does not
• opt-level = "s" works for me on a Blue Pill over I2C.

This is very odd. I'll get my SPI display out tomorrow and see if that crashes also.

@therealprof We should indeed. I'm going to look at bumping to the latest releases of most of the deps to keep up with the ecosystem.

from ssd1306.

So I just tried s, 2 and 3 here on my STM32F042 and they all work just fine.

from ssd1306.

The latest nightly breaks cortex-m-rtfm so I am now using nightly-2018-05-11.

I think I've found the issue. When stepping through line by line with the debugger it works. When I ignore breakpoints, or step very quickly, nothing gets written to screen. I'm guessing there's a delay that is getting optimised away somewhere, maybe needs a #[no_mangle]?

I was wrong, that didn't fix the problem. I guess next is looking at the list of optimisations under each opt-level and comparing to find the ones that are different between 0, 1 and 2, 3, s and z

from ssd1306.

I don't know if this is the same issue, but I'm struggling to make it work on a Blue Pill board (regardless of debug level).

My code works fine on two f4xx boards (Nucleo F411RE and f407-based "black vet6" board).

But on a Blue Pill board, display either doesn't turn on at all, image is glitched, or rarely it's normal.

Maybe there's something wrong with my board, I'll try a different one next week.

from ssd1306.

As it turned out, I used PB13 as DC (data-command selector), but it didn't work for some reason. Logic analyzer showed "high" all the time. I switched to PA9, and now it works.

So, the driver works for me on Blue Pill on any optimization level (both default release and LTO-enabled). Didn't test true debug build because apparently it consumes too much stack and crashes (t's naive Game of Life implementation).

from ssd1306.

Closing as fixed 🙂

from ssd1306.