Panic when enabling task stack traces #72
Comments
|
Interesting! Assuming that |
|
Sure, dump does appear to work, available here: https://us-east.manta.joyent.com/jperkin/public/tmp/hubris.core.1 Note that for some reason (a limitation of semihosting?) humility only works when the system is stopped, e.g. ^C in gdb. If I try to run any humility command against a running system I get this error: The board is an STM NUCLEO-G0B1RE, and my branch is at https://github.com/jperkin/hubris/tree/armv6. It appears to work as expected and I'm currently working on the GPIO driver, but unfortunately with the above issue I'm unable to run the test suite, even after flashing and removing all of the logging so that it runs with semihosting. |
|
The NUCLEO-G0B1RE is one of the three M0+ eval boards I ordered, so will have hardware in hand soon! It would be worth getting OpenOCD out of the way entirely to see if that changes behavior (the OpenOCD backend to Humility relies on somewhat shaky foundation in terms of the OpenOCD TCL interface). Without any archive at all, you should be able to run That said: based on the fact that you have a dump, it appears that they are working properly -- though I do notice from the dump (as you mentioned) that And great work on this so far -- and it feels like old times to get a Manta URL to a dump! ;) |
|
I've been using I don't know if I'm doing this right, but with the device flashed and no OpenOCD running (and no If I fire up openocd and retry it appears to attach (I need to figure out why it's halting, probably due to some missing semihosting bits..): If I fire up gdb and run hubris from there, humility is unable to retrieve register status while the system is running (I'm guessing due to the various debug bits that are missing in ARMv6 compared to ARMv7?): If I then It's also worth noting I'm using the latest trunk of openocd as the support for the G0 devices is quite new, 0.11 works but e.g. a bunch of register values are incorrect. |
|
I somehow missed #70 -- my apologies! Especially if OpenOCD has some recent changes to support the G0 devices, my guess is that we need to update/fix probe-rs. One experiment worth trying: try latest probe-rs (we are quite a bit behind and on our own branch that has some fixes that we have needed) on its own (that is, without Humility), and see if the tooling that they provide can correctly see the chip. If so, we would want to update our probe-rs (which we truthfully want to do anyway); if not, we will want to add G0 support in probe-rs. (You can also get more information about why Humility is failing to create the probe by running with I would also add that the register values being incorrect may well be the root cause of this actual issue (incorrect stack traces); Humility should clearly not be tossing in this circumstance, but it seems likely that the fix will be to detect that the stack is corrupt and indicate as much. |
|
Aha, yes, switching over to the latest probe-rs helps, I can now connect when openocd is not running: Unfortunately I still can't get a In case it's useful here's the output with FWIW there's a small patch required to get building against the latest probe-rs, the diff --git a/humility-core/src/core.rs b/humility-core/src/core.rs
index e4301cd..3905318 100644
--- a/humility-core/src/core.rs
+++ b/humility-core/src/core.rs
@@ -142,7 +142,7 @@ impl Core for ProbeCore {
use probe_rs::architecture::arm::swo::SwoConfig;
let config = SwoConfig::new(0).set_baud(2_000_000);
- self.session.setup_swv(&config)?;
+ self.session.setup_swv(1000 as usize, &config)?;
/*
* Because the probe can have sticky errors, we perform one read
@@ -937,7 +937,7 @@ pub fn attach(mut probe: &str, chip: &str) -> Result<Box<dyn Core>> {
* debug probe because something else has already attached to it;
* we pull this error out to yield a more actionable suggestion!
*/
- if let Err(probe_rs::DebugProbeError::USB(Some(ref err))) = res {
+ if let Err(probe_rs::DebugProbeError::Usb(Some(ref err))) = res {
if let Some(rcode) = err.downcast_ref::<rusb::Error>() {
if *rcode == rusb::Error::Busy {
bail!( |
|
I just noticed in the verbose output that the chip id is incorrect: Looking at the probe-rs support in https://github.com/probe-rs/probe-rs/blob/master/probe-rs/targets/STM32G0_Series.yaml I can't see the STM32G0B1RE listed so will see if adding it and specifying the correct |
|
The app table mismatch is very surprising -- that should really only show up when the archive does not match what's on the flash. What does |
|
As it turns out, there were many problems here.
Fixing all of these problems, we have stack traces! Output from the original dump: $ humility: attached to dump
system time = 34056
ID TASK GEN PRI STATE
0 jefe 0 0 recv, notif: bit0 bit1(T+44)
|
+---> 0x200014f0 0x080112bc userlib::sys_recv_stub
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/lib.rs:336
0x200015b8 0x08010112 userlib::sys_recv
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/lib.rs:283
0x200015b8 0x08010112 userlib::sys_recv_open
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/lib.rs:239
0x200015b8 0x08010124 main
@ /System/Volumes/Data/work/git/hubris/task/jefe/src/main.rs:98
0x200015b8 0x08010030 _start
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/lib.rs:1219
1 rcc_driver 0 1 recv
|
+---> 0x20001b90 0x08014c44 userlib::sys_recv_stub
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/lib.rs:336
0x20001bb8 0x08014058 userlib::sys_recv
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/lib.rs:283
0x20001bb8 0x08014058 userlib::hl::recv
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/hl.rs:83
0x20001bb8 0x08014058 userlib::hl::recv_without_notification
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/hl.rs:121
0x20001bb8 0x08014066 main
@ /System/Volumes/Data/work/git/hubris/drv/stm32g0-rcc/src/main.rs:103
0x20001bb8 0x08014030 _start
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/lib.rs:1219
2 hiffy 0 3 notif: bit0(T+195)
|
+---> 0x200044f8 0x08009774 userlib::sys_recv_stub
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/lib.rs:336
0x20004528 0x080097f2 userlib::sys_recv
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/lib.rs:283
0x20004528 0x080097f2 userlib::sys_recv_closed
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/lib.rs:264
0x20004528 0x080097e6 userlib::hl::sleep_until
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/hl.rs:610
0x20004528 0x08009800 userlib::hl::sleep_for
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/hl.rs:635
0x200047b8 0x080082f6 main
@ /System/Volumes/Data/work/git/hubris/task/hiffy/src/main.rs:110
0x200047b8 0x08008030 _start
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/lib.rs:1219
3 idle 0 5 RUNNING
|
+---> 0x20001cb8 0x0801604c cortex_m::asm::inline::__wfi
@ /Users/jperkin/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-0.7.3/src/../asm/inline.rs:181
0x20001cb8 0x0801604c cortex_m::asm::wfi
@ /Users/jperkin/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-0.7.3/src/asm.rs:54
0x20001cb8 0x0801604c main
@ /System/Volumes/Data/work/git/hubris/task/idle/src/main.rs:13
0x20001cb8 0x08016030 _start
@ /System/Volumes/Data/work/git/hubris/sys/userlib/src/lib.rs:1219
I am going to get the Humility side of this fixed, but I would like to see the Cortex-M0+ support integrated into Hubris. (I have some minor delta on this to allow for Thank you for all of your work on both the M0+ and RISC-V! |
|
Eventually we'll want to add support for the M0+ MTB (micro trace buffer), which is much closer to the ETM-replacement on the STM32H7 and is a lot more suited to Humility than ITM. However, neither the STM32G0 under discussion here, nor the STM32L0 I have, appear to have implemented MTB, rendering it somewhat moot. :-( |
bcantrill
added a commit
that referenced
this issue
Jan 18, 2022
This work contains work done as part of Gimlet bringup, including Idol support for Humility. Improvements: - Incorporation of Idol support in Humility, allowing for both programmatic and command line interface calls of Idol-specified operations. See "humility hiffy" documentation for details. - Addition of a new "humility sensors" command that consumes data from the Hubris `sensor` task (if present). - Addition of a new "humility dashboard" command that consumes sensor data and provides a single captive, graphical interface showing sensor values over time. - Fixes a bevy of issues around Cortex-M0+; see #72 for details. - Fixes #52 to clarify that "humility itm" really needs an archive -- and documented "humility itm" to indicate that it really shouldn't be used unless absolutely necessary. - Add the ability for "humility rencm" to process output gleaned from running Renesas configuration software - Some refactoring and additional command documentation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm porting Hubris to Cortex-M0+ / armv6m so this is likely caused by changes with that architecture, and probably won't be helped by it not fully running yet, but while most commands work great, when requesting stack traces with
humility tasks -sI get a panic.Printing tasks and their registers works fine:
but not when adding
-s:Backtrace:
When running with a reduced app configuration which appears to be running fine (but where I need to halt via gdb before Humility can access over OpenOCD) I also get a hang when trying to add
-s:This may be related. I can provide system images on request if required.
The text was updated successfully, but these errors were encountered: