I'm trying to get the TDK CH201 and CH101 sensors to work. After porting the API and writing the firmware to the sensor, I'm able to get range reading from the sensors. So I2C is setup and working, as is the firmware on the sensor.

After a few seconds of operations (reading amplitudes) the sensor pulls the SDA line low and doesn't release it. It still responds to signals on the INT line, just doesn't get out of the bad I2C state. Sometime, like 1 in 10, it will just work for half an hour without problem.

Edit: I just tried lowering the SCL to 50kHz and it now seems to work consistently. Just really slow...

Edit: Working on a custom board using a STM32L1x, 3.3V on the MC side and 1.8V on the sensor side with a PCA9517D level shifter between them, 10k pull-ups on both sides. Trace length is about 1cm on the 3.3V side and ~10cm on the 1.8 side (flexprint, less than 1cm on the PCB). Copied the I2C part of the ST32-HAL into my project.

  • 1
    \$\begingroup\$ What pull-up resistor values were you using (at high-speed), maximum length of trace, and at what voltage? Please put this info into the question. \$\endgroup\$
    – rdtsc
    May 9, 2022 at 14:14
  • \$\begingroup\$ Did you forget to mention on which MCU or hardware platform your firmware runs and accesses the I2C chips? More info, schematics, source code, wiring, etc needed. \$\endgroup\$
    – Justme
    May 9, 2022 at 16:37
  • \$\begingroup\$ Not enough for an answer but what finally fixed it was turning up the optimization level. \$\endgroup\$
    – Max
    May 11, 2022 at 9:27
  • \$\begingroup\$ @max can you post your solution as an answer? \$\endgroup\$
    – Voltage Spike
    Nov 23, 2022 at 14:58
  • \$\begingroup\$ @VoltageSpike sure, but the answer is only slightly more satisfying (or usefull) than the numerous "device was broken, got a new one, now everything is ok" answers ;) \$\endgroup\$
    – Max
    Nov 23, 2022 at 15:45

1 Answer 1


Turns out the microcontroller was pretty packed and had a lot of interrupts running and the I2C interrupt was running at a low priority (as per customers requirements). So the I2C ISR wasn't handled fast enough and this somehow got the bus stuck (not entirely sure on which end) without throwing a bus error exception though.

What fixed it was turning up the compiler optimization to -O3. Had optimization turned entirely off for debugging. With -O3 both normal and fast mode worked just fine.

Ran into the same issue when turning on the I2C fast mode (400khz) and IO-link. But that was deemed acceptable by the customer as both won't be turned on at the same time and IO-link being quite resource hungry is a known issue. Basically the microcontroller was running pretty close to it's computing limits and handwritten code is just a bit too slow compared to compiler optimized code.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.