Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[chip,dv] Wait for JTAG connection in chip_sw_base_vseq #22893

Merged
merged 1 commit into from May 13, 2024

Conversation

rswarbrick
Copy link
Contributor

The wait_lc_status() task does a DMI read over JTAG to figure out the current state of lc_ctrl. This requires pinmux to route the JTAG signals to LC_CTRL and things get rather confused if we run this task before the routing has happened.

In normal use, the JTAG driver will send an IR command to switch address to the DMI address. Then it will send a DR command to do the DMI read/write. On the next DMI command, it can avoid the silly extra IR command because it knows we're already pointing at the DMI address.

Of course, this doesn't work if the JTAG signals got squashed. In that case, it will not know that IR hasn't changed, so it will send repeated DR commands expecting to see a particular lc_ctrl status come out. But that won't happen because we're not actually looking at the DMI register at all. Oops!

This commit adds a wait to make sure that JTAG has actually been connected up.

Fixes #22793 (and the ridiculously long maximum wait seems to be needed)

The wait_lc_status() task does a DMI read over JTAG to figure out the
current state of lc_ctrl. This requires pinmux to route the JTAG
signals to LC_CTRL and things get rather confused if we run this task
before the routing has happened.

In normal use, the JTAG driver will send an IR command to switch
address to the DMI address. Then it will send a DR command to do the
DMI read/write. On the next DMI command, it can avoid the silly extra
IR command because it knows we're already pointing at the DMI address.

Of course, this doesn't work if the JTAG signals got squashed. In that
case, it will not know that IR hasn't changed, so it will send
repeated DR commands expecting to see a particular lc_ctrl status come
out. But that won't happen because we're not actually looking at the
DMI register at all. Oops!

This commit adds a wait to make sure that JTAG has actually been
connected up.

Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>
@rswarbrick rswarbrick added the Component:ChipLevelTest Used to filter the chip-level test backlog label Apr 30, 2024
@rswarbrick rswarbrick requested a review from a team as a code owner April 30, 2024 08:58
@rswarbrick rswarbrick merged commit bb056f7 into lowRISC:master May 13, 2024
33 checks passed
@rswarbrick rswarbrick deleted the lc-ctrl-chip-test branch May 13, 2024 09:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component:ChipLevelTest Used to filter the chip-level test backlog
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[test-triage] chip_sw_lc_ctrl_rand_to_scrap fails for some seeds
2 participants