[chip-test] Failing UART Tests due to configuring UART1 pins from IOB4,B5 pins to IOA0,A1 pins
Open
Nobody has claimed this yet.
Component:ChipLevelTest
- Dominant language
- SystemVerilog
- Stars
- 3.6k
- Forks
- 1.1k
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 141
Description
Test point name
//sw/device/tests/uart_baud_rate_test
Host side component
Rust
OpenTitanTool infrastructure implemented
Yes
Silicon Validation (SiVal)
Yes
Emulation Targets
- None
- CW310
- Hyperdebug + CW310
Contact person
rprakas-gsc
Checklist
Please fill out this checklist as items are completed. Link to PRs and issues as appropriate.
- Check if existing test covers most or all of this testpoint (if so, either extend said test to cover all points, or skip the next 3 checkboxes)
- Device-side (C) component developed
- Bazel build rules developed
- Host-side component developed
- HJSON test plan updated with test name (so it shows up in the dashboard)
- Test added to dvsim nightly regression (and passing at time of checking)
- [x ] For SiVal test cases, test is running relevant FPGA or silicon regression
The following UART tests are failing - as soon as I reconfigure the pinmuxchannelDUT from Iob4/Iob5 pins to Ioa0/Ioa1 pins
[kUartPinmuxChannelDut] = { .mio_out = kTopEarlgreyPinmuxMioOutIob5, .insel = kTopEarlgreyPinmuxInselIob4,
//sw/device/tests/uart_baud_rate_test_silicon_owner_gb_rom_ext
//sw/device/tests/uart_loopback_test_silicon_owner_gb_rom_ext
The test failure is attributed to the timeout due to the host not receiving any data from DUT.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.