Release builds only work with opt-level = 0/1

[fmckeogh]

Hello,

I am only able to get release builds to function if opt-level = 0 or opt-level = 1 is added to Cargo.toml. If it is not added there are no errors during building and a much smaller binary is produced, but nothing is displayed. I have tested this with my own project, and both the blinky and graphics examples. I have not tested on any I2C displays.

I'm probably doing something stupid and normally I'd be fine just using opt-level = 1 and calling it a day, but unfortunately the binaries are too large for my MCU.

Thanks! :)

Edit: I was wrong to say nothing is displayed; every 4 or 5 resets sometimes the program works and stuff is displayed, but cutting power and resetting again results in no image. Debug binaries always work regardless of power loss and frequency of resets.

Second edit: I realise it is probably just the display's internal cache retaining data written with debug binaries

[jamwaffles]

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?

[fmckeogh]

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 :(

[fmckeogh]

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?

[therealprof]

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.

[jamwaffles]

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.

[therealprof]

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

[fmckeogh]

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

[WGH-]

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.

[WGH-]

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).

[jamwaffles]

Closing as fixed 🙂