Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I2C 'Wait until byte is transferred' loop #85

Closed
ijager opened this issue Mar 18, 2020 · 2 comments · Fixed by #87
Closed

I2C 'Wait until byte is transferred' loop #85

ijager opened this issue Mar 18, 2020 · 2 comments · Fixed by #87

Comments

@ijager
Copy link

ijager commented Mar 18, 2020

I was reading the i2c code since I want to implement it for another chip. Then I encountered the following loop in the send_byte function:

        // Wait until byte is transferred
        loop {
            let isr = self.i2c.isr.read();
            if isr.berr().bit_is_set() {
                self.i2c.icr.write(|w| w.berrcf().set_bit());
                return Err(Error::BusError);
            } else if isr.arlo().bit_is_set() {
                self.i2c.icr.write(|w| w.arlocf().set_bit());
                return Err(Error::ArbitrationLost);
            } else if isr.nackf().bit_is_set() {
                self.i2c.icr.write(|w| w.nackcf().set_bit());
                return Err(Error::Nack);
            }
            return Ok(());
        }

// Wait until byte is transferred

This loop seems wrong as it only ever runs once. Guess it might still work in practice most of the time. I guess the idea was to wait for txe bit to clear like in two lines above?

while self.i2c.isr.read().txe().bit_is_clear() {}

@dbrgn
Copy link
Contributor

dbrgn commented Mar 18, 2020

Most probably a duplicate of #77 and #76.

What version do you use? If master, does the commit before #76 was merged work? If you're using the released version, can you try master?

dbrgn added a commit to gfroerli/stm32l0xx-hal that referenced this issue Mar 28, 2020
The GPIO internal peripheral (IP) does not match the
stm32l0x/stm32l0x2/stm32l0x3 grouping. Instead, there are 4 different
GPIO IPs in the STM32L0 family that define how the pin functions are
mapped to the actual pins. This means that the current I2C mappings are
broken for a lot of MCUs. For reference, these issues have already been
opened because the mappings were broken:

- stm32-rs#76
- stm32-rs#77
- stm32-rs#85

We can use the `io-*` Cargo features to differentiate between these
mappings. This requires that the proper `io-*` feature is set when
compiling (and is thus a breaking change). The easiest way to apply the
feature without looking at the STM32CubeMX database XML files is to
simply use the proper `mcu-*` feature, for example `mcu-STM32L071KBTx`.
@dbrgn
Copy link
Contributor

dbrgn commented Mar 28, 2020

@ijager can you test whether it works with the changes in #87 (https://github.com/gfroerli/stm32l0xx-hal/tree/i2c-correct-mappings)?

# Cargo.toml
stm32l0xx-hal = { git = "https://github.com/gfroerli/stm32l0xx-hal/", branch = "i2c-correct-mappings", features = ["rt", "mcu-YOURMCU"] }

dbrgn added a commit to gfroerli/stm32l0xx-hal that referenced this issue Apr 4, 2020
The GPIO internal peripheral (IP) does not match the
stm32l0x/stm32l0x2/stm32l0x3 grouping. Instead, there are 4 different
GPIO IPs in the STM32L0 family that define how the pin functions are
mapped to the actual pins. This means that the current I2C mappings are
broken for a lot of MCUs. For reference, these issues have already been
opened because the mappings were broken:

- stm32-rs#76
- stm32-rs#77
- stm32-rs#85

We can use the `io-*` Cargo features to differentiate between these
mappings. This requires that the proper `io-*` feature is set when
compiling (and is thus a breaking change). The easiest way to apply the
feature without looking at the STM32CubeMX database XML files is to
simply use the proper `mcu-*` feature, for example `mcu-STM32L071KBTx`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants