quick-xml 0.19.0, a dependency of svd2utra, uses features
that Rust will deprecate.
Unfortunately, the only versions of quick-xml that do not
use the deprecated language features also break a portion
of the API. In particular, quick-xml will no longer take
a `File` as an input: it will only take a `Path`.
This means that the API for svd2utra is also broken, because
originally it was designed to take a `File`
This patch refactors svd2utra to work with the latest quick-xml,
but also breaks any code that calls svd2utra's generate
APIs.
Fortunately this is fairly easy to fix, the calling code
will typically already have the Path somewhere in it, so
instead of opening the Path and passing it into the function,
one may simply pass in the Path.
verified to address the issue at least in a simple test case
1) drop repeated keys instead of panic-unwrapping
2) reduce key repeat rate to something more sane
Alright, this one was very tricky.
The problem here turns out that if the very last operation
on the RTC was a write before powering off, any spurious
clock/data noise is interpreted as a valid write to the RTC!
Thus, if the last thing you do to the RTC before a suspend is
a write of some sort, the RTC is going to be corrupted. During
shutdown, the RTC lines slam up and down a couple of times:
- they drop low as vcore discharges
- they then pop high once vcore is dead
- they then slowly drop low as vddio drops
in both of these cases, they drop with a very slow (>10ms)
fall time, which gives ample time for the RTC to get excited
and think maybe some data is being written to it! Also on boot,
there is a brief glitch of SDA/SCL at the same time, which looks
very much like a start condition.
Anyways, this patch does two things:
1. Performs a dummy read to a register that is "far from" any
critical data resisters. This puts the I2C state machine
of the RTC in "read" mode, so any future clock cycles just
keep wheeling through the RTC bank as a read, instead of clocking
in data as a write. There is a non-zero chance that the noise
"could" emulate a valid I2C transaction (it'd have to create
the bit pattern that addresses the RTC, with the right timing),
but in practice this hasn't been seen.
2. Disables the RTC block on suspend, prior to suspend. This
will prevent the RTC engine from issuing any new commands as
the core starts to shut down. It's conceivable that e.g. the
"start" bit could randomly flip high as the power goes down
and since the I2C engine is now in the always-on domain it'll
dutifully start clocking out bits as the power goes away.
This patch seems to have stabilized the RTC corruption problem
that was previously witnessed.
CPU is sleeping during I2C transactions, leaving the bus in a state
where the I2C transaction is continuously being fired over and over
again because the way LiteX creates CSRStorage, it gives the
CPU precedence over the block's update.
Basically what happens is that the CPU writes something to the
I2C, goes to sleep, and leaves the I2C block selected. This causes
the I2C block unable to clear its own I2C transaction initiation
register, subsequently leading to the I2C transaction being repeated
over and over again until the CPU wakes up and stops jamming the
bus in that state.
By forcing WFI on during I2C transactions, the CPU is more responsive
during I2C and also we prevent the I2C transactions from being restarted.
This was verified using an oscilloscope.
