I am using this library to sample some sensors over the I2C bus using the PRUs on the Beaglebone Black. It seems as if only the first transaction works correctly, after which the library seems to only attempt to read from register address 0xFF, followed by the SCL line being pulled low (see attached image captures by logic analyzer). I have already opened an issue on their github, but am not expecting an answer there as the repository hasn’t been updated in years and the author hasn’t been active on GitHub since 2019.
While trying to find the problem myself, I decided to write the register address and received data in the shared memory to inspect using prudebug. For this test, I am attempting to read registers 0x00 and 0x03. Interestingly, it writes the correct register addresses into memory (see image), but only the first returned value is correct (0xEA). The value written into the received data buffer in shared memory is 0xFF, which does not make sense. As can be seen from the logic analyzer, 0xFF is the address it attempts to read from.
I don’t know what I am doing wrong here, but any help would be appreciated! My main code is shown below, and the library functions can be found in the linked repository here.
uint8_t curr_data_idx = 0;
uint8_t tmp = 0;
uint8_t reg = 0x00;
volatile uint8_t * buf = ((volatile uint8_t*)(RESERVED_SMEM_ADDR + 32));
int main(void)
{
// enable OCP
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
pru_i2c_driver_DelayMicros(500000);
uint8_t res = 0;
res = pru_i2c_driver_Init(1);
uint8_t saddr = 0x68;
pru_i2c_driver_ReadReg(1, saddr, reg, &tmp);
buf[curr_data_idx] = tmp;
pru_i2c_driver_DelayMicros(1000);
curr_data_idx++;
reg = 0x03;
pru_i2c_driver_ReadReg(1, saddr, reg, &tmp);
buf[curr_data_idx] = tmp;
pru_i2c_driver_DelayMicros(1000);
curr_data_idx++;
__halt();
return 0;
}