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!

[John E KVAM]

i've got an idea that I want you to check.

The number one issue with I2C and non-ST MCUs is that the STM32 can do a very large multi-byte I2C write. Most other MCUs are limited to reasonable numbers, like 32, 128 or 256.

Unfortunately our driver takes full advantage of the STM32, and the WrMulti does not show how to divide up that function into chunks.

The sizeof(VL53L5CX_GET_NVM_CMD) is 40.

I'm guessing your max I2C write is 32.

So the write never completes.

Could you check it please?

re-write WrMulti() to do the write in chunks of 32. (just repeated writes but you have to update the address accordingly.

• john

[DBonh.1]

Thanks, John for the fast response.
Below I pasted a screenshot from the Total Phase I2C analyzer. The analyzer shows all 42 bytes. It also shows the much bigger packets containing the sensor's firmware as transferring okay.
There's something else very strange. After several of the I2C commands from the host, your ULD calls a polling function that waits for a good response from the sensor. In two cases, the sensor responds okay after exactly 25 polling queries from the host. When I add short delays in the polling function, the sensor continues to respond after 25 queries, regardless of how long it takes. This doesn't feel right.
The polling function is also called after the NVM command, and it responds with an error after exactly 16 polling queries, regardless of how slowly I run the poll.
I just now downloaded your v1.3.4 ULD. I was previously using v1.0.4. I'm seeing some minor diffs. I'll let you know after I get 1.3.4 fully incorporated into my Atmel code (I would have designed with an STM processor but Atmels were more readily available from the distributors).
[image: image.png]

[John E KVAM]

the 66 is what you get when the sensor is not actually running. It's a catch-all error. Only the interface logic is going. So you are really going to have to dig into the manual and find out if the AT supports the long i2C access.

(or you can just shorten it up as a test.)

[DBonh.1]

Both an oscilloscope and the protocol analyzer show that the Atmel is sending packets of 32770 bytes, and that the sensor is ACKing all of those bytes. Although Atmel's I2C driver stalls after 22,000 bytes - I opened a case with Atmel for that issue. Until they fix that I'm using a bit-banged I2C driver that can do long packets.

Knowing that the 66 means that the sensor is not running the firmware - that's helpful. I might be able to attack this by attaching the I2C protocol analyzer to one of your eval boards and watch it initialize a sensor. Does your eval board do pretty much the same init routine as your ULD?

[John E KVAM]

The Eval kit does exactly what we are asking you do to. It would be a very good way to debug.

And don't just think the write limitation is equal to the read limitation. One can read up to 5K in some situations, although 2500 is more common.

• john

[DBonh.1]

Great. Although I won't have a complete eval kit until Monday because I loaned out my Nucleo-F401 boards, got more on order. I do have a Nucleo-H7 board along with some LV53L5C boards sitting here. Do you have a Nucleo-H7 driver for your sensor board? Or is it easier for me to wait for more F401s on Monday?

[John E KVAM]

Way easier to wait. The Graphical User Interface software was really only built on the F401RE, and although it could be rebuilt, it would take long than a few days of test time.

Sorry about that.

• john

[DBonh.1]

No prob, we can stall this case till Monday. Talk to ya then. Thanks! -Doug

[DBonh.1]

I got itchy to pursue this so I overnighted a Nucleo board from Mouser. Here's first glimpse of my Atmel side-by-side with STM Eval Board. The Eval board's init function shows additional write statements before each read. This might reflect a problem with how I structure my read statements, not sure yet. I will continue investigating this lead. No need for you to dig in yet until I investigate. But if you know something off hand it might help. I should know more by tomorrow. Thanks! -Doug 406.830.0373.