-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Description
I've noticed similar behavior also on P8 and now on PineTime, both with 1.4.0 Infinitime FW. It is hard to reproduce. Sometimes watch is frozen (cutting-edge PRs or something else maybe?), screen black and button does not react. I try to reboot by holding button. After reboot, the screen is on but the watch did not vibrate and button, touchscreen (touch or doubletap to wake up) or accelerometer (wake on wrist) does not work. After timeout the screen goes dark. Sometimes I need to make like 10 reboots.
Other way to fix it is to short-circuit 3.3V rail for a while, or disconnect and reconnect the battery.
This happend few times to me.
There was #566 which tried to fix it but the problem is that even after 8/16 SCL pulses the sensor still holds SDA low, which blocks the Start condition on the I2C bus. The sensor should give up after 1 byte transfer since it does not get ACK, but it seems is does not release the bus and needs more clocks.
You can read deeper info and scope signals when this happened on my P8 in the #566 . I thought that happened because of special accelerometer on P8, but now it happened also on PineTime.
Here I have video of like 13 resets which fixed that.
https://photos.app.goo.gl/j5HsZEDtwyau68A37
For now I have all my watches sealed, it would be great if someone could try this code devkit and test how it behaves if you ground SDA. I did some tests on my sealed watches but it seems like something more could be wrong with the code, maybe GPIO configuration. I wasn't able to get into while (nrf_gpio_pin_read(Pinetime::PinMap::TwiSda) == 0) loop. Any ideas are welcome.
void declock_i2c()
{
// I2C declocking issue
nrf_gpio_cfg_input(Pinetime::PinMap::TwiSda, NRF_GPIO_PIN_PULLUP);
volatile int i = 0;
while (nrf_gpio_pin_read(Pinetime::PinMap::TwiSda) == 0)
{
nrf_gpio_cfg_output(Pinetime::PinMap::TwiScl);
nrf_gpio_pin_clear(Pinetime::PinMap::TwiScl);
nrf_delay_ms(2);
nrf_gpio_cfg_input(Pinetime::PinMap::TwiScl, NRF_GPIO_PIN_PULLUP);
nrf_delay_ms(2);
if (++i > 100)
{
NVIC_SystemReset();
}
}
}
Not entirely sure how to figure out which sensor does it. I do not use heartrate sensor. Also on P8 is completely different accelerometer (SC7A20) vs BMA42x on Pine. But I would say it might be accelerometer beacuse it is the most frequently read sensor. Sometimes I was able to get to this stuck state by rebooting Pine with button hold. I guess you just have to hit the middle of the I2C transaction to get sensor stuck.
It would be also nice, to have this for some time in release firmware with some notification or counter which would say to the user that this I2C stuck condition happened and how many clocks it needed to get it right. Otherwise we will never know if this code helped in any way.
I did not wanted to write this to already closed and merged PR, but since I cannottest it I also did not created new PR. But if you think this should be PR even with not tested code, I might create it.
Thanks