CS0/CS1 (and potentially other GPO/GPI lines) clobbered by UART code

[HeathenUK]

In looking to re-use the SPI routines in the firmware for a non-SD device I've had issues with what appear to be the output lines (possible the input lines too?) from the DUART being yanked around unexpectedly during or between transactions.

Of course it's no problem to minimise issues in a single two-byte transaction by deasserting and re-asserting CS, but this issue does also seem to be preventing auto-incrementing/streaming transactions where you wouldn't normally deassert the CS pin until you're done (or I wouldn't, perhaps I'm operating against spec).

@roscopeco had suggested this might be an artefact of older "POST" style code and the firmware setting the whole of the output pins in one go including those not sinking an LED. I'm surprised that hasn't caused any issues with SD transactions!

G

[0xTJ]

Do you know if this is still a problem? Since this issue was made I've had a few looks at where this could happen, and haven't found anything.

Since the DUART uses separate registers for setting and clearing, only the output pins that have bits set in those writes will be affected. As far as I can find (at least in the current develop), the operations on those pins in the firmware seem to only target the needed pins (the heartbeat only uses $20, SPI creates bit masks in registers).

I'm also unsure about what could yank around the input lines, since those are only connected to either the UART or the SPI ports, and are input-only to the DUART.

[roscopeco]

Closing this as superseded, if it is still a problem we can reopen / reraise 🙂