0000026921 [hal] TRACE: Abort: 00000001
0000026931 [hal] TRACE: Abort: 00000001
0000026973 [hal] TRACE: Abort: 00000001
0000026983 [hal] TRACE: Abort: 00000001
What does this log output signify?
On a Gen 4 device (RTL872x), during an I2C read or write, the low-level RTL function set the abort flag during the operation. This is transmit; receive is a little farther down in the file.
The abort operation should be initiated by the other side and this flag just indicates that it happened. It's one of a number of possible failures, the most common being timeout.
Hi Rick - many thanks, that gives me the area to investigate.
Rick, I solved the abort issue - due to an external I2C temperature sensor not being connected. My concern is that this scenario (an external I2C device missing) is halting the user firmware and indeed is returning abort for I2C devices on the internal bus as well. Any thoughts please about how this potential scenario should be handled?
Another question - I am testing wake from the WDT (AB1805) using the timer alarm to pin S6/D21. This is not working - i.e. it is not going to sleep. The pin P2_PDU_WDT_FOUT has a pull-up to 3V3 - same as P2 3V3.
SystemSleepConfiguration config;
config.mode(SystemSleepMode::HIBERNATE)
.gpio(P2_PDU_WDT_FOUT, FALLING);
System.sleep(config);
It's just a debug trace and it looks like the function just returns after it, so it should be fine, assuming your logic after that takes into account that the I2C operation can fail. For example, if you want forever for the requested number of bytes to read, that would cause the code to be stuck forever in this case.
Pin S6/D21 (PB[31]) cannot wake from hibernate sleep mode. The note says "No internal pull up or pull down in HIBERNATE sleep mode," which is true, but it's also important that it does not say "Pin can wake from HIBERNATE sleep." I just realized that the sentence about it above the table is confusing; I'll update that.
Hi Rick, which pins can a P2 wake from HIBERNATE sleep from? The reference document has quite a list - is this correct or not?
Are you saying that the SystemSleepConfiguration is failing because the gpio isn't D10/WKP?
D10 is WKP and that can wake from hibernate sleep.
You mentioned using S6/D21. That cannot be used to wake from hibernate sleep. Only pins that list "Pin can wake from HIBERNATE sleep" can be used to wake from hibernate sleep.
if you attempt to wake on an incompatible pin, the device won't go to sleep.
Confusing list - why are S6 and S4 even on this list? OK that explains why after I load the software I can't flash to it again - it gets to 70% and freezes.
That confirms that I need to link the WDT_FOUT to WKP pin through an external circuit wake pulse generator. OR I move some pin assignments and attach WDT_FOUT to S0, S1, S2, D2, D3, D4, D5?
But S6 will work for ULTRA_LOW_POWER and STOP?
Yes, S6 can wake from STOP or ULP sleep. INPUT_PULLUP and INPUT_PULLDOWN also work while in STOP or ULP sleep.
I split the single table of all hibernate-related pins into two separate tables, one for wake and one for pull in the datasheets and Device OS firmware API reference.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.