Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions boards/nordic/nrf54h20dk/support/nrf54h20_cpuapp.JLinkScript
Original file line number Diff line number Diff line change
Expand Up @@ -169,6 +169,11 @@ int OnTraceStart(void)
return 0;
}

int AfterResetTarget(void)
{
_needCoresightSetup = 1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I click "Reset & Break At Symbol" in Ozone I no longer see Instruction Trace. Based on the commit message I was expected this to help. What does this fix exactly? Is it supposed to fix missing Instruction Trace after "Reset & Break At Symbol"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are trying the thing it should improve yes.
Can you try pause and resume a few times after the initial break? The debugger connection gets reset on the reset so Ozone must recover and hence needs a few branches to actually see where the instruction trace is at, even if it knows the current instruction from the program counter. The instruction trace is mostly just branching information if a branch was actually taken, so it needs to capture quite a bit to get an actual address and derive the current instruction from that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I click "Reset & Break At Symbol" in Ozone I no longer see Instruction Trace.

Wait a minute, you didn't see it continue before did you? So you were checking if this made it better and it didn't live up to expectations or does this actually break instruction tracing on reset for you?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While last week I was getting trace somewhat working if I didn't hit reset, now I am unable to get trace working at all. I just get "No trace clock present, trace may not work correctly."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is very strange, this should at worst case cause the coresight subsystem to be configured more often but to the same configuration. Are you sure you are setting CONFIG_SOC_NRF54H20_TDD_ENABLE=y?
I am reworking this part to be more like a proper zephyr driver here, so it'll be a devicetree entry that gets enabled #95124

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where do I get CONFIG_SOC_NRF54H20_TDD_ENABLE=y from? I do enable NRF_IRONSIDE_TDD_SERVICE and NRF_TRACE_PORT in west build -t menuconfig but I don't see CONFIG_SOC_NRF54H20_TDD_ENABLE anywhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was a feature I added to unlock using ETM. https://github.com/zephyrproject-rtos/zephyr/blob/main/soc/nordic/nrf54h/Kconfig#L69-L78
But in hindsight it was a poor design, I should have gone with the referenced coresight PR #95124 from the start, so tpiu has proper pinctrl, tdd proper power management via a device driver etc. NRF_TRACE_PORT I had not realized existed, I could have probably hidden the TPIU config behind that but think the future pinctrl configuration style is a lot cleaner overall

return 0;
}

int SetupTarget(void)
{
Expand Down