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 Example - Error Reading Variable #77

Closed
DanSGiesbrecht opened this issue Feb 13, 2020 · 2 comments · Fixed by #87
Closed

I2C Example - Error Reading Variable #77

DanSGiesbrecht opened this issue Feb 13, 2020 · 2 comments · Fixed by #87

Comments

@DanSGiesbrecht
Copy link

DanSGiesbrecht commented Feb 13, 2020

I'm having difficulty implementing the I2C example:

  • MCU: STM32L071
  • stm32l0xx_hal version: 0.5.0
#![no_std]
#![no_main]

extern crate panic_semihosting;

use cortex_m_rt::entry;
extern crate stm32l0xx_hal;
use stm32l0xx_hal::{pac, prelude::*, rcc::Config};

#[entry]
fn main() -> ! {
    let periph = pac::Peripherals::take().unwrap();

    let mut rcc = periph.RCC.freeze(Config::hsi16());
    let gpioa = periph.GPIOA.split(&mut rcc);

    let sda = gpioa.pa10.into_open_drain_output();
    let scl = gpioa.pa9.into_open_drain_output();

    let mut i2c = periph.I2C1.i2c(sda, scl, 100.khz(), &mut rcc);

    let mut buffer = [0u8; 2];
    const ADDRESS: u8 = 0xFF;

    i2c.write(ADDRESS, &mut buffer).unwrap();

    loop {
    }
}

When debugging using GDB, I get one out of a variety of errors when I stop debugging, such as:

^C
Program received signal SIGINT, Interrupt.
0x080009d8 in stm32l0::stm32l0x1::i2c1::isr::<impl stm32l0::generic::R<u32,stm32l0::generic::Reg<u32,stm32l0::stm32l0x1::i2c1::_ISR>>>::txe (
    self=<error reading variable: Cannot access memory at address 0x20004e3c>)
    at /home/gies/.cargo/registry/src/garden.eu.org-1ecc6299db9ec823/stm32l0-0.9.0/src/stm32l0x1/i2c1/isr.rs:801
801	        TXE_R::new((self.bits & 0x01) != 0)
^C
Program received signal SIGINT, Interrupt.
0x080009e8 in stm32l0xx_hal::i2c::I2c<I,SDA,SCL>::send_byte (
    self=<error reading variable: Cannot access memory at address 0x20004dd4>, 
    byte=<error reading variable: Cannot access memory at address 0x20004dd8>)
    at /home/gies/.cargo/registry/src/garden.eu.org-1ecc6299db9ec823/stm32l0xx-hal-0.5.0/src/i2c.rs:183
183	        while self.i2c.isr.read().txe().bit_is_clear() {}
^C
Program received signal SIGINT, Interrupt.
core::cell::UnsafeCell<T>::get (
    self=<error reading variable: Cannot access memory at address 0x20004db0>)
    at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libcore/cell.rs:1539
1539	/rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libcore/cell.rs: No such file or directory.
^C
Program received signal SIGINT, Interrupt.
0x080009bc in vcell::VolatileCell<T>::get (
    self=<error reading variable: Cannot access memory at address 0x20004e38>)
    at /home/gies/.cargo/registry/src/garden.eu.org-1ecc6299db9ec823/vcell-0.1.2/src/lib.rs:32
32	        unsafe { ptr::read_volatile(self.value.get()) }

I'm relatively new to Rust. Is this an issue with the I2C example, or am I missing something else? Any assistance would be greatly appreciated.

@dbrgn
Copy link
Contributor

dbrgn commented Feb 13, 2020

@DanSGiesbrecht see #76. we're also using the STM32L071 and hit the same strange issues 🙂

@DanSGiesbrecht
Copy link
Author

DanSGiesbrecht commented Feb 13, 2020

Thanks for pointing that out! I'm going to test tonight - if that's my only issue, I'll close this.

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