| 26 Jul 2021 |
 cnnblike | the issue is like this: https://pastebin.com/NjEHTH24 | 09:17:11 |
 bradleyharden | I'm not sure this will work. The clocks struct won't have a static lifetime until it is moved into a static. I think the only way to access something with a static lifetime in init is for it to be a local resource of init itself. | 09:17:23 |
| cnnblike | * the issue is like this: https://pastebin.com/NjEHTH24 | 09:17:35 |
| bradleyharden | When you paste, please use Markdown to format the code. It's really hard to read that | 09:18:02 |
| cnnblike | ok | 09:18:21 |
| cnnblike | yep, I thought maybe some one in rtic community may have already been trapped into same scenario like me | 09:18:35 |
| cnnblike | * impl<'a> UsbPeripheral<'a> {
pub fn new<L, LSTAT>(usbd: USBD, _clocks: &'a Clocks<ExternalOscillator, L, LSTAT>) -> Self {
Self {
_usbd: usbd,
_clocks: PhantomData,
}
}
}
| 09:19:29 |
 mriise | (gdb) break SDIO
Breakpoint 1 at 0x1986: file src/main.rs, line 17.
(gdb) continue
Continuing.
init start
init end
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
lib::__wfi () at asm/lib.rs:50
50 asm/lib.rs: No such file or directory.
(gdb) list breakpoints
Function "breakpoints" not defined.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x00001986 in core::sync::atomic::atomic_load<u8> at src/main.rs:17
(gdb) step
blinky::app::rtic_ext::main () at src/main.rs:17
17 #[rtic::app(device = lpc55_hal::raw, dispatchers = [SDIO], peripherals = true)]
(gdb)
i feel like this is right, but still no dice...
| 09:21:25 |
| bradleyharden | cnnblike, I don't understand the clock type enough, but it seems like it isn't Send or Sync. Do you need to actually store it as a resource? | 09:23:42 |
| cnnblike | In reply to @bradleyharden:matrix.org
cnnblike, I don't understand the clock type enough, but it seems like it isn't Send or Sync. Do you need to actually store it as a resource? actually no, storing it just to make sure it have a static lifetime | 09:26:55 |
| cnnblike | will store it as "static mut" solve the problem? | 09:29:14 |
| bradleyharden | In your code right now, the clock struct is not static. It's dropped at the end of init. So your code wouldn't work there | 09:30:06 |
| bradleyharden | But I don't know that you need it to be static | 09:30:45 |
| bradleyharden | What happens if you remove it from the Shared struct? | 09:31:02 |
| cnnblike | it went back the previous scenario, dropped at the end | 09:31:39 |
| cnnblike | https://github.com/jamesmunns/m60-keyboard/blob/ee6dd111a253994a6c24b12379e0cfd7b947c487/src/bin/keyberon_app.rs <- similar attempt made on rtic & nrf52840_hal | 09:32:25 |
| cnnblike | but prior to 0.6.0-alpha5 api | 09:32:34 |
| cnnblike | in which the usbd_dev is stored in LateResources, is there an difference between Shared+Local vs LateResources | 09:33:23 |
| cnnblike | from what I can see in the implementation, they should act similar | 09:33:48 |
 AfoHT | In reply to @mriise:matrix.org
(gdb) break SDIO
Breakpoint 1 at 0x1986: file src/main.rs, line 17.
(gdb) continue
Continuing.
init start
init end
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
lib::__wfi () at asm/lib.rs:50
50 asm/lib.rs: No such file or directory.
(gdb) list breakpoints
Function "breakpoints" not defined.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x00001986 in core::sync::atomic::atomic_load<u8> at src/main.rs:17
(gdb) step
blinky::app::rtic_ext::main () at src/main.rs:17
17 #[rtic::app(device = lpc55_hal::raw, dispatchers = [SDIO], peripherals = true)]
(gdb)
i feel like this is right, but still no dice...
Seems you're dealing with gdb just fine. Something isn't setup properly is my guess, this is why I'd like you to check your hardware registers for the relevant parts, like systick, interrupts enabled etc
I'm quite fond of https://github.com/bnahill/PyCortexMDebug but you can also print raw addresses with gdb, and check the registers related to peripherals
| 09:36:01 |
| bradleyharden | Yes, they are similar. I'm not sure. I don't understand the types enough. It doesn't seem like you should need a &'static for the clock struct. But if you do, I'm not sure how best to do that right now. Seems like you might still need your own static mut. | 09:37:01 |
| bradleyharden | AfoHT, there's no way to create a late static resource in init, right? | 09:38:32 |
| bradleyharden | You can have early static resources as local resources of init | 09:39:10 |
| bradleyharden | But you probably need the singleton macro or something for late static resources | 09:39:38 |
| cnnblike | In reply to @bradleyharden:matrix.org
Yes, they are similar. I'm not sure. I don't understand the types enough. It doesn't seem like you should need a &'static for the clock struct. But if you do, I'm not sure how best to do that right now. Seems like you might still need your own static mut. let me try that implementation and come back, just want to sure if rtic has done anything during the api change... | 09:39:46 |
| AfoHT | In reply to @bradleyharden:matrix.org
AfoHT, there's no way to create a late static resource in init, right? If memory serves then yes, I think atm that isn't doable. Looking at the examples/static.rs, we have what you describe as the early static resource as a local resource | 09:48:56 |
| cnnblike | emmm, that example actually works, let me further check whether it's possible to make the API migrated to rtic-v0.6.0-alpha5 | 09:55:56 |
| cnnblike | ok, I get it, this is why: https://github.com/nrf-rs/nrf-usbd/commit/4208283bb23d2def354cd03e4fb865c88759acd9 | 10:16:47 |
| cnnblike | the reference to clock has now been removed from this crate, my bad, the rtic is not the root cause | 10:17:15 |
| cnnblike | 🤣I was wondering how could the problem be easily resolved by adding a vendor folder instead of consuming directly from the master commit of nrf52840_hal | 10:18:44 |
