Part Number: MSP432P401R
Tool/software: TI-RTOS
Using the latest MSP432 launchpad (red) with the 1.20.00.45 SDK running 'i2cslaveexample1'.
Instead of using another launchpad for the master, I am using a Beaglebone Black (BBB) from u-boot.
From the BBB:
=>i2c md 48 1
Returns the expected 0x55 and the waveform on an oscope look good
But running the same command again results in a timeout. The oscope shows initial activity, but then I see that the MSP432 is holding down SCL and SDA.
If I reset the MSP432, the SCL and SDA lines go back to normal (high).
The only way I have been able to reliably read the MSP432 slave is to reset the i2c bus in u-boot with 'i2c reset' after every read. What does a reset actually do? I don't see any activity on the oscope. Could the MSP432 not be terminating the transmission correctly after a read and a subsequent read puts u-boot/MSP432 in some sort of 'mismatched' state?
I see the same behavior reading from Linux instead of u-boot.
The goal is to have the MSP432 be a 'standard' i2c slave that should be able to be read from any i2c master.
Thanks.
