i.MX RT 10xx LPI2C Possible Bug

[brghena]

In the start_read() function in the lpi2c implementation for the i.MX RT 10xx, there are two probable bugs.

First, the MTDR::CMD.val() is set to "100" instead of "0b100". This doesn't match the implementation of the start_write() function above. I suspect it's an error.

Second, the MTDR::DATA.val() is set to (self.slave_address.get() << 1 + 1) as u32. The order of operations here applies the "+" first, then the bit shift. I believe the intent was to shift the address up one bit, then apply a 1 as the new least-significant bit to denote an I2C read operation, that would properly be written as ((self.slave_address.get() << 1) + 1) as u32.

Relevant lines of code (after the clippy pass from #3637) are here:

tock/chips/imxrt10xx/src/lpi2c.rs

Lines 701 to 715 in f3e310b

	fn start_read(&self) {
	self.rx_position.set(0);
	// setting slave address
	self.registers.mier.modify(MIER::EPIE::CLEAR);
	self.registers.mtdr.write(
	MTDR::CMD.val(100) + MTDR::DATA.val((self.slave_address.get() << (1 + 1)) as u32),
	);
	self.registers.mcfgr1.modify(MCFGR1::PINCFG::CLEAR);
	self.registers
	.mier
	.modify(MIER::NDIE::SET + MIER::EPIE::SET + MIER::RDIE::SET);
	}
	}

@alexandruradovici can you confirm or reject whether this is an issue?

[alexandruradovici]

@valexandru can you take a look?