the concurrency issues on I2C are getting hairy, and it was probably a
dubious decision from the start to merge I2C into the LLIO block; but
originally this was motivated by the idea of keeping all the
"miscellaneous slow stuff" in one process to keep the memory footprint
small and make code a bit more readable.
Keeping I2C in the same process space as the LLIO but splitting it
into its own thread and server splits the difference, by giving us
more options to deal with the concurrency, without inflating the size
of the kernel binary and allocating a lot of extra static data.
Here's an arcane bug for you:
When powering down, the Spartan 7 3.3V I/O drivers will
output a roughly 800us wide glitch as 3.3V falls below around
1.7V, if the 0.95V core voltage comes down first (which it does
because we have an active discharge on 0.95V, but not on 3.3V).
In this case, it's just wide and high enough to cause the
BOOST mode line to engage, which takes the BOOST output
and ties it to VBUS, which is just enough for the system to
think you're powering it back on again. Which is not what
you want when powering down.
The ultimate fix was to put a heftier pull-down on the BOOST
line so that it can't trip the BOOST output into the VBUS.
Another option could be more active discharge FETs, but that
would require a full board spin and we are already at certification,
so we'll stick with the stronger pull-down on BOOST. It seems to
be a robust fix in the worst corner cases we can find.
The downside is that when powering an external USB device,
you are burning an extra 30mW of power overcoming the pull-down,
but typically, any external USB devices plugged into Precursor
will burn far in excess of that, so the delta should be negligible.
There is an issue with the rtc commandline time checking
with respect to unhooking its callback, maybe related to
the new disconnect/destroy server code
