Program freezes if compiled in debug mode.

[crmoratelli]

Hi.

Recently I was working on this project BMP180-ATmega2560-rust, where I implemented a driver to the BMP180 using this HAL. I was using cargo run to upload code to an Arduino Mega 2560 board.

Everything was working fine. However, as the code got bigger, the program started to freeze. I could still see initialization messages, but it stopped execution at some point. I did some tests, and I noticed that commenting out some code lines allows the execution to continue. However, the local variables had wrong values, which I checked with prints.

Compiling with cargo run --release makes it work without any problem. My experience in C programming with embedded makes me think that, for some reason, the stack could be corrupted. I would like to understand better if there is any restriction in building a debugging target (cargo run) or what else could be causing this behavior.

The link in this message takes you to the repository. This error can be reproduced with cargo run and the running version with cargo run --release, but you need a BMP180 to see it working.

[Rahix]

If, by debug build, you mean a build without optimizations, you are pretty much guaranteed to run into tons of issues. Due to the extremely limited amount of SRAM on AVR microcontrollers, we must rely on a lot of compiler optimizations to get the code into a shape whose memory footprint is small enough.
Otherwise, the stack will quickly grow too large and either corrupt statics or simply lead to an overflow.

Because of this, we usually configure the dev profile (that's cargo run) to also apply optimizations, similar to the release profile (cargo run --release). The relevant code is here:

avr-hal/Cargo.toml

Lines 1 to 11 in 2eb28fa

	[profile.dev]
	panic = "abort"
	lto = true
	opt-level = "s"
	[profile.release]
	panic = "abort"
	codegen-units = 1
	debug = true
	lto = true
	opt-level = "s"

Please make sure you are also using similar settings in your Cargo.toml. If you are still encountering issues, some other difference between the two profiles must be at play. I'd try adding one of the following settings to the dev profile to see whether one of them is to blame:

codegen-units = 1
incremental = false
debug-assertions = false
overflow-checks = false

[crmoratelli]

Thank you! Your response make things very clear.

My original dev profile that came with cargo generate was:

[profile.dev]
panic = "abort"
lto = true
opt-level = "s"

Adding overflow-checks=false made the coding run.

[profile.dev]
panic = "abort"
lto = true
opt-level = "s"
overflow-checks = false`

Now, I can run it with cargo run! However, I understood the need for optimization.

Thanks!

[Rahix]

Interesting to see overflow-checks being the cause here. Do you do something particularly math heavy in your program?

Disabling overflow-checks isn't necessarily bad, just keep in mind the implications.

[crmoratelli]

Yes! BMP180 is a I2C device capable to read pressure and temperature. Pressure calculation from raw data is math heavy.

By "operators will panic..." means a processor's exception, consequently making the program to stop?

Maybe I had two problems: 1) corrupted statics because I could see wrong values in some variables, and; 2) overflows in math operations.

As I am new to Rust, I am trying to understand the basics.

[Rahix]

A panic is sort of a program-controlled abort. So not a processor exception, but rather the program intentionally stopping because of an unrecoverable error. Read more about this in the Rust Book: Chapter 9.1.

Now that you mention it, you could very well have seen panics due to overflow. So be careful here...

In embedded rust, we have to explicitly define the panicking strategy. The most simple way is using the panic-halt crate which simply halts the CPU on panic. The line that pulls in panic-halt is this one:

avr-hal/examples/arduino-uno/src/bin/uno-blink.rs

Line 7 in 2eb28fa

use panic_halt as _;

The disadvantage is of course that you don't get to see any indication of the panic or where it occurred. So a more sophisticated alternative is to provide your own panic handler with custom logic. For example, you could print the location to serial console and also blink an error LED:

avr-hal/examples/arduino-uno/src/bin/uno-panic.rs

Lines 20 to 53 in 2eb28fa

	#[panic_handler]
	fn panic(info: &core::panic::PanicInfo) -> ! {
	// disable interrupts - firmware has panicked so no ISRs should continue running
	avr_device::interrupt::disable();
	// get the peripherals so we can access serial and the LED.
	//
	// SAFETY: Because main() already has references to the peripherals this is an unsafe
	// operation - but because no other code can run after the panic handler was called,
	// we know it is okay.
	let dp = unsafe { arduino_hal::Peripherals::steal() };
	let pins = arduino_hal::pins!(dp);
	let mut serial = arduino_hal::default_serial!(dp, pins, 57600);
	// Print out panic location
	ufmt::uwriteln!(&mut serial, "Firmware panic!\r").unwrap_infallible();
	if let Some(loc) = info.location() {
	ufmt::uwriteln!(
	&mut serial,
	" At {}:{}:{}\r",
	loc.file(),
	loc.line(),
	loc.column(),
	)
	.unwrap_infallible();
	}
	// Blink LED rapidly
	let mut led = pins.d13.into_output();
	loop {
	led.toggle();
	arduino_hal::delay_ms(100);
	}
	}

[crmoratelli]

Nice! I understand the error handling much better now. This panic handler will save me much time in future developments. Thanks!