M-Labs
/
artiq-zynq
10
1
Fork 19
Code Issues 13 Pull Requests Releases Wiki Activity

Soft panic for RTIO PLL reasons #199

Merged
sb10q merged 16 commits from mwojcik/artiq-zynq:pll_error into master 2022-10-21 17:56:34 +08:00
Conversation 8 Commits 16 Files Changed 4 +5 -4
2 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 401bc6bcb3 - Show all commits

3
src/runtime/src/comms.rs
View File

@ -538,7 +538,8 @@ pub fn soft_panic_main(timer: GlobalTimer, cfg: Config) -> ! {
mgmt::start(cfg); mgmt::start(cfg);
//getting eth settings disables the LED - need enable it here // getting eth settings disables the LED as it resets GPIO
// need to re-enable it here
#[cfg(feature = "target_kasli_soc")] #[cfg(feature = "target_kasli_soc")]
{ {
let mut err_led = ErrorLED::error_led(); let mut err_led = ErrorLED::error_led();
sb10q commented 2022-10-05 17:02:50 +08:00
Outdated
Review
Copy Link

Why does it disable the LED?

Why does it disable the LED?
mwojcik commented 2022-10-05 17:07:21 +08:00
Outdated
Review
Copy Link

getting eth settings sets up I2C to communicate with the ethernet controller;

I2C setup also resets GPIO:
https://git.m-labs.hk/M-Labs/zynq-rs/src/branch/master/libboard_zynq/src/i2c/mod.rs#L57

and I2C GPIO (MIO 33, 50, 51) is in the same bank as the error led (MIO 37); so resetting the entire port again causes the LED to go off.

getting eth settings sets up I2C to communicate with the ethernet controller; I2C setup also resets GPIO: https://git.m-labs.hk/M-Labs/zynq-rs/src/branch/master/libboard_zynq/src/i2c/mod.rs#L57 and I2C GPIO (MIO 33, 50, 51) is in the same bank as the error led (MIO 37); so resetting the entire port again causes the LED to go off.
sb10q commented 2022-10-07 18:56:00 +08:00
Outdated
Review
Copy Link

Okay I see. Maybe make the comment a bit more clear (e.g. "we reinitialized the GPIO controller, so only now can we turn on the error LED")
Also, the non-mgmt panic handler should also turn on the LED to make sure.

Okay I see. Maybe make the comment a bit more clear (e.g. "we reinitialized the GPIO controller, so only now can we turn on the error LED") Also, the non-mgmt panic handler should also turn on the LED to make sure.

6
src/runtime/src/panic.rs
View File

@ -37,14 +37,14 @@ fn panic(info: &core::panic::PanicInfo) -> ! {
SOFT_PANICKED = true; SOFT_PANICKED = true;
PANICKED[id] = true; PANICKED[id] = true;
} }
if !soft_panicked && id == 0 {
soft_panic(info);
}
#[cfg(feature = "target_kasli_soc")] #[cfg(feature = "target_kasli_soc")]
{ {
let mut err_led = ErrorLED::error_led(); let mut err_led = ErrorLED::error_led();
err_led.toggle(true); err_led.toggle(true);
} }
if !soft_panicked && id == 0 {
soft_panic(info);
}
println!("Backtrace: "); println!("Backtrace: ");
let _ = backtrace(|ip| { let _ = backtrace(|ip| {
// Backtrace gives us the return address, i.e. the address after the delay slot, // Backtrace gives us the return address, i.e. the address after the delay slot,