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:
Hi guys, any advice, suggestion?
Will it makes sense to check lines with oscilloscope? I have no scope so I will need to find one for rent, if that could help somehow.
In your last 2 images: what I see is the sensor holding the SCL line low for clock stretching and then its ack. That part seems correct. What I don’t see is the stop condition: sda going up when scl is already up. After the ack the slave is releasing the sda line, master is forcing it down, but then it releases SDA and SCL together. That doesn’t seem right.
If the sensor doesn’t handle repeated starts, then it should explain why it’s not working.
Yes that’s the point, it looks like the master aborts the whole transaction for some unclear reason.
As I wrote, the only thing I suppose is something wrong with clock stretching support by master.
Sensor requires the repeated start here, this checked with Arduino many times.
Tfmini plus is working fine for me with another board, Emlid Edge, using the same driver. I will capture a trace later today or tomorrow there to check the difference.
This is with CUAV v5, thus a stm32f7. See that when we are going to read it’s considered a repeated start (Sr) rather than a Start because there wasn’t a stop condition (at least not one grabbed by the resolution of my logic analyzer - I traced at 2MHz).
This looks like the transaction was interrupted or the end of the transaction was not handled correctly, both CLK and SDA just released.
Notice that the last failed LOW timing of the CLK (F) is shorter than normal ones (N)
This part looks similar to my case (#3 in the first post), but I have that interruption after the first byte.
Do transfer() returns any error or it still returns OK?
Yeah. There’s something wrong with the I2C driver in Chibios I suspect. I was able to force generating the stop condition by using the autoend flag on stm32, but then I’m not getting the interrupt when the transfer ends. I need to find some time to take a look on it again.
Plz tell me if I can somehow help diagnosing the issue.
Isn’t it worth to create a ticket to draw some attention to the problem? As it seems the most FC on F4 and F7 MCU are affected.
