VL53L5 init stalls at get offset NVM data

[DBonh.1]

I'm implementing the VL53L5CX ultralight driver on an ATSAM4L. The sensor responds correctly when requesting Device ID and Rev. The init function runs without errors (status = 0) through the loading of firmware and restarting the sensor's MCU. But one of the next steps in the init function is getting the offset NVM data. It writes VL53L5CX_GET_NVM_CMD without error (status is still = 0). Then it polls the sensor, and at that point it returns status = 66.

I have a Total Phase I2C protocol analyzer on it during the entire init process. It reports no errors during any of the transactions. Any ideas? This step is the first WrMulti() call where the register address is not 0 (it's 0x2fd8). So that is a possibility. But the I2C analyzer shows 0x2fd8 being correctly passed to the sensor. So I'm running out of ideas. All help or suggestions appreciated!

[DBonh.1]

I sure wanted to use Atmel's ASF TWI driver. But on the ATSAM4L the TWI transmit stops dead and hangs after sending 22,174 bytes. We need to send 32,770 bytes of firmware. I have an open case with Microchip on that but they haven't solved it yet, so I resorted to a bit-bang.

I suspect the TWI limitation on the ATSAM4L is related to how the total amount of program flash isn't a lot bigger than that. Atmel might have assumed that no one will need to send I2C packets that big.

[John E KVAM]

I just posted some ST code (written by a collegue) that breaks long I2C transactions into smaller chunk sizes.

I posted it under:

I2C multi-byte read and write functions with i2C byte limit. (st.com)

It should help a lot. Although you will still have to adapt it to your MCU.

• john

[DBonh.1]

Thanks, John, because one of Microchips off-the-shelf I2C drivers stalls at 22,000 bytes. I've had an open case with them for weeks but they haven't solved it yet. I won't be the only one who hits this. It's only with their barely-big-enough ATSAM4L. Their bigger ATSAMs that have more memory do not have this limitation. Thanks!! -Doug

[John E KVAM]

Someone reported that bug a while back and I think it was fixed in version 1.3.1.

The current version on ST.com is 1.3.4.

But I don't blame you for running older code. There does not appear to be any way to check for a newer release except to download the code and look at the version.

That might be the bigger issue.