The RM says we have to process STUP (and therefore clear CNAK to start the data stage)
in the DOEPINT STUP interrupt. Seems doing it in RXFLVL when we receive the data is
too early. This makes it work consistently on all chips, so the quirk is no longer needed.
Fixes#3493Fixes#3459
Initially, this was feature-gated, but has been requested
to be changed to be unconditional, see PR 3488 for reasons.
When filtering is enabled, it intercepts and drops silently
ipv6 packets, possibly somewhere around
smoltcp::iface::interface::ipv6 lines 36, 44 in current head
sha e9b66eadaeacef758ebc4a12378f8d2162144cf4
With filtering disabled (this patch), packets are received
and communication over ipv6 is possible, neighbor discovery works.
related: #2496
Signed-off-by: Krzysztof Królczyk <Krzysztof.Krolczyk@o2.pl>
1. If one received frames under an `interrupt_free` section, in my case
`init` in RTIC, the RX IRQ will fire and clear it's enable bit after
`interrupt_free` is complete. There is no frame to read so RX is now
unconditionally disabled forever.
2. On clearing of RX IRQ, TX stops silently. This happens due to the use
of `write` instead of `modify` when modifying IRQ enable bits.
Solution 1: Enable RX IRQs on every call to `try_read` that return no
data. This solution also solves the issue of very delayed handling of
the RX IRQ which would cause the same issue.
Solution 2: Use `modify` instead of `write`.
Its an internal error which should never be exposed. It should only
occur with wrong driver implementations. We log to the user and return
an Overrun error since handling DmaUnsynced as an Overrun will resolve it.
As per section "43.7.23 LTDC layer x color frame buffer length register (LTDC_LxCFBLR)" of Reference manual for STM32U5 RM0456, CFBLL has to be set to the length of one pixel line plus 3 (instead of plus 7 as for H7)
