Auterion / embedded-debug-tools

Tools for debugging and profiling ARM Cortex-M devices as found on the PX4 Autopilot FMU boards
https://auterion.github.io/embedded-debug-tools/
BSD 3-Clause "New" or "Revised" License
47 stars 6 forks source link

[Orbetto]: Running Orbetto on a FC with a daisy chain connection #6

Open wico-merkel opened 4 months ago

wico-merkel commented 4 months ago

Setup:

Problem Description:

I am trying to get the tracing output on a custom flight controller board running a version of the px4-autopilot code. The documentation only mentions the --jlink and --stlink option, but not the --remote. Since I am having a daisy chained MCU, I need to use the --remote with JLinkGDBServer to setup my JTAG scan chain (at least I do not know how to do it otherwise). So one terminal runs the JLinkGDBServer and another one gdb:
% python3 -m emdbg.bench.fmu --target cubepilot_cubeorange_default --remote localhost:2331

Now I run into the following two issues:

Problem 1:
image
I think I entered this functionand px4_reset is not defined in this context. If I manually add the px4_reset, identical to the one in jlink.gdb, I run into the second issue.

Problem 2:
image I think we are never reaching the breakpoint nx_start since the reset did not work correctly.

Is there a way to get this working for the "--remote" option as well? Or are we limited here to the --jlink or --stlink version?


I also have some general question regarding the setup, I hope this is the right place for them too.

image

As far as I understand, replacing the ORBTrace with a JLink Base or any other debugger should not have a impact as long as the JTDO pin is connected to it, e.g. this means the nostalgic Cube Orange Flight Controllerswould not be supported, since they only have the mini debug port. But with the SWD port we only have the 4kB FIFO buffer for our tracing data. Is that correct?

And I also wonder if the software differentiates between the different output options (big red circle, SWD vs SWO). The command used only mentions enable trace, am I correct that both tracing options work in parallel?

Thanks for you help in advance. I am looking forward to get this tool working and giving it a test run.

Regards,
Kevin

wico-merkel commented 4 months ago

.

niklaut commented 2 months ago

The issue is that the default px4_reset implementation tries to reset via the RESET pin, which is probably not connected on your board. You can use monitor reset 0 instead, which will use the internal software reset.

Is there a way to get this working for the "--remote" option as well? Or are we limited here to the --jlink or --stlink version?

monitor reset has different syntax for OpenOCD and JLink, thus we would have to automatically detect what we're connected to. Perhaps over the port number?

But with the SWD port we only have the 4kB FIFO buffer for our tracing data.

Yes, but reading that buffer is not implemented in hardware in any debug probe (like RTT on the JLink), so polling that in software would be too slow to make sense on the STM32H7. JLink does actually support the ETB and MTB, so maybe it also supports the FIFO? It's currently not implemented, but would be good to add? Does not seem to be able to do streaming reads though.

If you can somehow get at pin PB3, you get at least SWO out, which will give you 90% of the benefit already. Your JLink Base also supports SWO input up to 30Mbps, which is quite reasonable, so you don't need a ORBTrace.

I correct that both tracing options work in parallel?

Not in parallel, I think what you read from the FIFO in software is not put on the trace pins anymore. But you can use SWO and TRACE in parallel.