Last two weeks I’m trying to get the I2C version on the TFMini lidar to work with Pixracer.
There is no driver for I2C version at the moment so I created my own.
At the beginning there was a number of issues because of mistakes in my driver implementation but now I’ve stuck with some low-level problem.
To be consistent:
There is a nice example of how to make lidar working with Arduino board. This example does work for me with no problems. Here is my logic analyzer dump with Arduino:
This is a ‘read measurement’ request. It consists of 4 bytes: [DevAddr] + 0x01 + 0x02 + 0x07. Next to that there is a restart condition for starting receiving 7 bytes from lidar. No screenshot for that but everything is OK with that too.
Pixracer has a single i2c bus; I have a compass connected and working normally to the bus. All my tests with lidar I did with connected compass and also with disconnected compass - that didn’t affected anything.
The problem in Pixracer+lidar pair is that the transmission stops after very first byte sent:
Note: I’ve disabled retry-logic in I2CDevice.cpp so there is a single try. With retry-logic on nothing changes actually - there just 3 tries that breaks on first byte.
When that error happens I checked the results returned by underlying chibios drivers, so the master_transmit_timeout() returns MSG_RESET and i2cGetErrors() returns BUS_ERROR.
What I already checked:
- The logical levels should be ok. 3.3V high level and ~0.2 low level.
- There is a 2.2KOm pull-up resistors on the lidar. And also the same resistors on Pixracer too. I’ve removed the ones from the lidar (still working with Arduino, so I’m sure I didn’t broke anything).
- I’ve increased I2C_IRQ_PRIORITY up to 2 - not helped.
- Decreased bus speed to 50KHz - not helped.
- Decreased bus speed to 25KHz - it works! See my assumption below
So I wonder why compass works good on the same bus but lidar isn’t?
The only thing I’ve noticed so far - TFMini does use a CLOCK STRETCHING when ACK-ing the first byte.
Whilst the compass never does CLOCK STRETCHING.
Thought I don’t know if this is a reason or just a coincidence. Is there known issues with clock stretching?
Returning to the fact it works on 25KHz - I’ve missed the analyzer dump but in that case the lidar does not produce a clock stretching on first ACK. Looks like it is because there is enough time for lidar to response at that frequency.
Another thing that confuses me is the timing between the SDA goes low and SCL goes high (T-SU-DAT if I remember correct):
May be it is too short for Master to recognize properly? As per I2C specs the min time for 100KHz is 250ns. There is about 1 microsecond. This is good but still very close to the limit.
Looking at STM32F4xx errata sheet, there are also interesting things exists. It is hard to understand if they’re handled in the core Chibios drivers or not:
I’m out of ideas what else can I try.
@tridge because you’re the comm interfaces master in ArduPilot