2021-06-09 06:10 AM
Hi,
i am trying to get STM32F301K8 to communicate with VL6180V1 ToF sensor on my custom board., via I2C (at 20kHz) I had problem getting the API to work so i tried low level I2C access by just sending 0x01 with basic HAL_I2C_Master_Transmit.
I noticed that i can not get ToF sensor to respond with ACK. I checked rise times of the I2C, it is 66ns, due to my long traces, but still well under maximum of 120ns, according to datasheet. I am using default ToF 7bit address of 0x29 (and left shifting it << 1) and on scope it is clearly visible, along with RW bit. Also start and stop conditions are looking as they should, so only problem is the missing ACK. I also tried on 2 different PCBs with fresh out of reel ToFs. Pullup resistors are 4.7k (also tried with 1k) and Vcc is 2.82V.
Could it be that ToFs are faulty or i destroyed them when soldering?
Scope picture of rise time measurement and the I2C master transmit signal are below:
Below are readings from X-Nucleo-6180A1 development kit:
2021-06-14 03:02 AM
Anyone?
2021-06-22 01:39 AM
Ok, i moved this thread to MEMS ad Sensors, if anyone here might help.
2021-06-23 02:05 AM
Hi @KSkor.1 ,
I added the Time of Flight topic for more help.
Hi @John E KVAM, do you have any suggestion about this issue?
Thanks,
-Eleon
2021-06-25 07:15 AM
Is there anyway to can simply shorten the wires. This will make absolutely sure there is not an I2C issue.
Philips designed the bus, NXP bought Philips. They still have the best documention on getting the pull-ups right.
If you are using an STM32 in your design, did you use the STM322CubeMX software to help you design your system?
It pulls in validated code and you should be up and running in short order. And it's free.
I'd say give that a shot.
2021-06-30 12:46 AM
Thank you for response. There are no wires, just trace on the pcb, which i cant shorten. Their length is 85.9mm(SDA) and 86,4mm(SCL). Will check NXPs documentation.
Yes, i am using STMCUBEMX plug in for CubeIDE to setup my code and design system. I also tried my code on the development kit and it worked there(with few modifications because of gpio extender that is used there).
2021-06-30 07:31 AM
Under 10cm should be more than fine. The NXP doc spends a lot of time talking about how to size the pull-ups but your signals look fine. But do double check.
(There's a formula in their doc.)
Yet you say that the sensor doesn't ACK.
In my experience the only ways this chip cannot ACK is it is
1) underpowered.
2) the XSHUT (which is way too sensitive) is not pulled up strongly enough, causesing the sensor to constantly reboot.
3) Wrong I2C address.
4) Poorly I2C pull-up configuation.
I'd double check all of these. If you code ran with the GPIO expander, it should have been a small matter of changing the address.
I can't think of anything else.