Provided I2C chapter solution in 11.6 hangs in `sensor.init`

[jonhoo]

I'm going through the book with a V2.21 board at the moment, and enjoying it immensely, thank you!

I've now hit section 11.6, and discovered that the solution present in 11.6 does not work. In particular, execution gets stuck at this line:

discovery-mb2/mdbook/src/11-i2c/src/main.rs

Line 40 in 576cea2

sensor.init().unwrap();

I also discovered that I cannot gdb-attach to this one, and it took me a little while to realize that it was because of the different Embed.toml configuration (may be worth calling that out somewhere in the docs?), so I arrived at ^ with print debugging 😅 After changing the config, I discovered that execution seems to be stuck in

nrf_hal_common::twim::Twim<nrf52833_pac::TWIM0>::wait<nrf52833_pac::TWIM0>

specifically with a backtrace of

#4  0x00004d02 in nrf_hal_common::twim::Twim<nrf52833_pac::TWIM0>::write_part<nrf52833_pac::TWIM0> (self=0x2001fcc3,
    buffer=..., final_operation=true)
    at /Users/jon.gjengset/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/nrf-hal-common-0.18.0/src/twim.rs:416
#5  0x0000607e in nrf_hal_common::twim::{impl#2}::transaction<nrf52833_pac::TWIM0> (self=0x2001fcc3, address=25,
    operations=...)
    at /Users/jon.gjengset/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/nrf-hal-common-0.18.0/src/twim.rs:548
#6  0x00004bbe in embedded_hal::i2c::I2c::write<nrf_hal_common::twim::Twim<nrf52833_pac::TWIM0>, u8> (self=0x2001fcc3,
    address=25, write=...)
    at /Users/jon.gjengset/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/embedded-hal-1.0.0/src/i2c.rs:355
#7  0x00000a88 in lsm303agr::interface::{impl#2}::write_accel_register<nrf_hal_common::twim::Twim<nrf52833_pac::TWIM0>, nrf_hal_common::twim::Error, lsm303agr::register_address::CtrlReg4A> (self=0x2001fcc3, reg=...)
    at /Users/jon.gjengset/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lsm303agr-1.1.0/src/interface.rs:60
#8  0x0000104e in lsm303agr::Lsm303agr<lsm303agr::interface::I2cInterface<nrf_hal_common::twim::Twim<nrf52833_pac::TWIM0>>, lsm303agr::types::mode::MagOneShot>::acc_enable_bdu<lsm303agr::interface::I2cInterface<nrf_hal_common::twim::Twim<nrf52833_pac::TWIM0>>, nrf_hal_common::twim::Error, lsm303agr::types::mode::MagOneShot> (self=0x2001fcc2)
    at /Users/jon.gjengset/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lsm303agr-1.1.0/src/device_impl.rs:89
#9  0x00001104 in lsm303agr::Lsm303agr<lsm303agr::interface::I2cInterface<nrf_hal_common::twim::Twim<nrf52833_pac::TWIM0>>, lsm303agr::types::mode::MagOneShot>::acc_enable_temp<lsm303agr::interface::I2cInterface<nrf_hal_common::twim::Twim<nrf52833_pac::TWIM0>>, nrf_hal_common::twim::Error, lsm303agr::types::mode::MagOneShot> (self=0x2001fcc2)
    at /Users/jon.gjengset/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lsm303agr-1.1.0/src/device_impl.rs:98
#10 0x0000119c in lsm303agr::Lsm303agr<lsm303agr::interface::I2cInterface<nrf_hal_common::twim::Twim<nrf52833_pac::TWIM0>>, lsm303agr::types::mode::MagOneShot>::init<lsm303agr::interface::I2cInterface<nrf_hal_common::twim::Twim<nrf52833_pac::TWIM0>>, nrf_hal_common::twim::Error, lsm303agr::types::mode::MagOneShot> (self=0x2001fcc2)
    at /Users/jon.gjengset/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lsm303agr-1.1.0/src/device_impl.rs:81

You can see that we never hit the breakpoint at the next line after init:

(gdb) list
38
39          write!(serial, "pre\r\n").unwrap();
40          let mut sensor = Lsm303agr::new_with_i2c(i2c);
41          write!(serial, "init\r\n").unwrap();
42          sensor.init().unwrap();
43          write!(serial, "set_accel\r\n").unwrap();
44          sensor
45              .set_accel_mode_and_odr(
46                  &mut timer0,
47                  AccelMode::HighResolution,
(gdb) b 42
Breakpoint 2 at 0x1d96: file mdbook/src/11-i2c/src/main.rs, line 42.
(gdb) b 44
Breakpoint 3 at 0x1e24: file mdbook/src/11-i2c/src/main.rs, line 45.
(gdb) c
Continuing.

Program received signal SIGINT, Interrupt.
i2c::__cortex_m_rt_main () at mdbook/src/11-i2c/src/main.rs:24
24      fn main() -> ! {
(gdb) c
Continuing.

Breakpoint 2, i2c::__cortex_m_rt_main () at mdbook/src/11-i2c/src/main.rs:42
42          sensor.init().unwrap();
(gdb) c
Continuing.

Program received signal SIGINT, Interrupt.
lsm303agr::Lsm303agr<lsm303agr::interface::I2cInterface<nrf_hal_common::twim::Twim<nrf52833_pac::TWIM0>>, lsm303agr::types::mode::MagOneShot>::init<lsm303agr::interface::I2cInterface<nrf_hal_common::twim::Twim<nrf52833_pac::TWIM0>>, nrf_hal_common::twim::Error, lsm303agr::types::mode::MagOneShot> (self=0x0)
    at /Users/jon.gjengset/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lsm303agr-1.1.0/src/device_impl.rs:80
80          pub async fn init(&mut self) -> Result<(), Error<CommE>> {
(gdb) c
Continuing.

[jonhoo]

In case it's relevant, this is with a macOS host.

[BartMassey]

Reproduced on my Linux box. Thanks for the detailed report! I don't even get as far as you do.

Will look into it shortly.

[BartMassey]

Oops, spoke too soon. Does seem to work for me: just holding it wrong. Sigh. You have to talk to this thing through a serial port, which is a weird interface. I will add some stuff to make this easier to work with.

[BartMassey]

I always hate to suggest this, but is it possible your hardware is just broken? If you bought a cheap board off Ali or somewhere, you should be aware that I have gotten broken ones through this sort of route in the past. We should put a note about that in the book, and probably add a validation program that goes around and checks that everything is working.

(Fun story: I experienced this during a live tutorial with new Rust embedded developers in China. My demo did not work, and it took me a bit on-the-fly to realize my board was just broken. It turned out to be the only broken one of about 20 boards being used in the class. Was great in the end — got to demo throwing the board across the room and grabbing a new one, which immediately worked fine. Hardware, amirite?)

I assume the earlier examples in that chapter — chip-id and show-accel — work for you? If so, that's weird: show-accel is basically the same code modulo serial IO and magnetometer. I'm assuming chip-id shows 0b110011 and 0b1000000?

Another possibility is miscompilation, I guess. I'm using rustc 1.88.0 and compiling --release.

[BartMassey]

I will work on some changes today that should make this chapter easier to deal with. That said, I don't think any of them will resolve this issue. Apologies.

It could be a Mac thing, but I don't see how: everything up to this point seems to have worked for you… There's nothing special about the code in this chapter that I can think of offhand.

[BartMassey]

Oh and another dumb one. Don't be afraid to power off the board: if I recall correctly, just resetting or flashing it does not reset the AGR. Again, that should be mentioned somewhere.

[jonhoo]

I mean, it could be that the hardware is just broken of course, but yeah, all the previous exercises worked just fine, including chip-id and show-accel:

09:43:23.807: The accelerometer chip's id is: 0b110011
09:43:23.807: The magnetometer chip's id is: 0b1000000

09:44:45.003: Acceleration: x 40 y -438 z -1008
09:44:45.003: Acceleration: x 41 y -436 z -1012
09:44:45.003: Acceleration: x 62 y -428 z -1018
09:44:45.003: Acceleration: x 37 y -439 z -1008
09:44:45.003: Acceleration: x 40 y -443 z -1006
09:44:45.118: Acceleration: x 43 y -440 z -1018
09:44:45.118: Acceleration: x 70 y -26 z -1137
09:44:45.118: Acceleration: x -186 y -402 z -1504
09:44:45.118: Acceleration: x -27 y -509 z -1490
09:44:45.118: Acceleration: x 70 y -551 z -1364
09:44:45.124: Acceleration: x 46 y -486 z -1123
09:44:45.241: Acceleration: x -92 y -530 z -815
09:44:45.241: Acceleration: x -83 y -482 z -943
09:44:45.241: Acceleration: x -214 y -504 z -658
09:44:45.241: Acceleration: x -654 y -756 z -279
09:44:45.241: Acceleration: x -330 y -1160 z -1028
09:44:45.241: Acceleration: x 855 y -941 z -1534
09:44:45.361: Acceleration: x 1448 y -590 z -1787
09:44:45.361: Acceleration: x 1109 y -778 z -1600

I'm running rustc 1.89.0-beta.5 (c24557234 2025-07-12), and tried both with and without --release — they both seemed to get stuck.

But, lo and behold, when I tried the exact same thing again this morning (after leaving the device disconnected overnight), it suddenly now is working. Maybe it was the disconnect? Maybe it was that I flashed chip-id and show-accel in between? Not sure, but hey, it works again! I guess that means we can close this, even if we don't know the root cause 😅

[BartMassey]

The usual hardware comedy — sorry you had to run into it. I've seen this kind of thing before, but usually when some program messed up the AGR in an "obvious" way and left it hung until disconnect.

Glad it worked out for you. By the way, a few PRs landed today, including the annual upgrade to latest dependency versions. Please feel free to pull again before going on.

Again, thanks huge for the detailed and helpful bug report, and for your patience in dealing with it.

[jonhoo]

Not at all — I try to file bug reports I would be happy to be on the receiving end of 😅 Thanks for the quick turn-around!

[hashcatHitman]

I experienced this same issue (on what is now chapter 12, section 6). I tried various different versions of the compiler, made sure probe-rs was up to date, unplugged it, plugged it back in, gave it a day unplugged, and probably a few other things. My board is also V2.21.

Ultimately, I got it to work after quickly filling in the "Compass" tutorial in block mode on https://makecode.microbit.org/, flashing the result, and completing the magnetometer calibration process I was then prompted with. It might have been coincidence, but if anyone else has trouble with this in the future, maybe try calibrating the magnetometer!

[BartMassey]

Thanks much for the report!

It's a mystery 👻 . I've tried with probably close to a dozen boards of MB2, all different versions, and have never seen this. I'm re-opening the issue, since there's clearly something to be investigated here.