Closed codecubepi closed 5 months ago
This PR fixes #389. However, I was not able to fully address the weird time out behaviour. See this issue comment: https://github.com/Severson-Group/AMDC-Firmware/issues/393#issuecomment-2142338423
Thanks! I will get this merged into the staging branch.
Resolves some final issues in the AMDS driver:
Invalid Data Issue
389
This was addressed by adjusting the flop timing of the data lines coming into the AMDS driver.
The state machine in
adc_uart_rx.v
is also a little more robust in how it determines the validity of each packet. Previously, if the first packet sent across a data line was corrupt (failed the parity check), the parent SM would give up and not even direct the child SM inuart_rx.v
to read the following packets. This is no longer the case, the parent SM will keep going through the normal state cycle (HEADER -> MSB -> LSB) even if an earlier packet becomes corrupted. The transistion from the DONE state back to IDLE is only made once all packets have been read.Finally, a timer was added which allows the user to read the latency in microseconds from the trigger (and SYNC_ADC being sent to the AMDS) to the first packet appearing on the data line.
Strange Timeout Behaviour
393
This issue was not fully resolved in this PR. I attempted to restructure the timeout system so that there are two timeout events: a long timeout event if the first packet does not appear on the data line within 10us of the trigger (this was easy to add using the new timer mentioned above), and a second timeout for each individual UART start bit.
The driver is timing out (yay), but sometimes the SMs inexpicably are still running and incrementing the data corrupt counter when they should be stuck in IDLE.
The merge plan is to:
v1.3-staging
v1.3-staging
v1.3.0