Closed edersondisouza closed 2 weeks ago
@edersondisouza how did you reboot the SOC? Asserting its #WRST pin? Symptom of timer running 3 times faster than expected should be caused by a failure to change PLL. When SOC is running change PLL sequence, the following HW mechanism will prevent SOC from entering sleep mode and cause the sequence to fail:
Or the patch can be used as a workaround for this symptom. NOTE: after applying the patch, clock frequence of i2c0, i2c1, and i2c2 can only run at 400kHz. i2c testing requires revalidation.
@Dino-Li I'm simply taking the power off - the board is connected to a ykush, which is used to power the USB port on and off. Will try those and report, thanks!
We checked on backup board, and currently we can't reproduce this issue. However, I connected board that is failing to my debug machine and when i change the code following patch the board is stable, but I will run more iterations of tests. Also I checked states on pins: GPM5 low GPH1 low GPE0 high GPA4 high
we can't reproduce this issue on backup board, closing for now, will reopen if the issue appear on new board
Describe the bug Several timer/clock related tests fail after rebooting the it8xxx2_evb. A reboot that triggers the anomaly is uncommon, usually < 5% of time. But when it happens, the anomaly will persist until next reboot. The offending reboot can be detected because the board doesn't start properly - it won't print anything on the serial, but a subsequent flash will work just fine, with the timer anomaly.
The tests failure can be traced to
k_busy_wait()
taking a different time from that expected. When the anomaly is happening, thek_busy_wait()
seems to happen at 3x the expected speed, for instance, a 10s wait will take 3.3s. Note that other methods to count the time will also note this discrepancy (e.g., by usingk_cycle_get_32()
), hence the tests failures.On the it8xxx2_evb, there's a custom busy wait, which uses the "combined timer" feature to track the passage of time. When the anomaly is active, the combined timer itself behaves anomalously, but not the other timers. Here I made some tests and noticed that:
From the datasheet and Zephyr timer initialisation code, I couldn't see any obvious issue. I can't rule out a defective hardware, but I'm creating this issue to see if anyone saw something similar and has any input.
To Reproduce
Keep rebooting the board (in my tests, it seems it happens more likely with a seemingly random combination of rebooting the board, the debug one or both). At some point, the application flashed won't start (no output on serial). After that, flash it with an application like the following, and it will print
!!! k_busy_wait() MISMATCH! !!!
. Several tests that rely onk_busy_wait()
will also fail.Expected behavior
k_busy_wait()
time should agree with other timers in the system, as well as "real world". Several timer/clock related tests also fail.Impact
Tests fail.
Logs and console output
See "additional context".
Environment (please complete the following information):
Additional context
Some of the tests that will fail:
Some more details for some of those: