10:28 <re_irc> < (@anand21:matrix.org)> Hi, I am working on TrustZone-M on NRF9160 board.

10:28 <re_irc> I have defmt setup for my Bootloader as well as Firmware.

10:28 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/rlf3QWnaXDwkwAy9BLrreBhE0xKn9Ynn (6 lines)

10:28 <re_irc> Isn't it possible to get the defmt working after we jump to the Firmware.

10:28 <re_irc> I am not able to get the defmt (deferred formatting) work for my Firmware.

12:15 <re_irc> < (@chemicstry:matrix.org)> : I'm not sure if trustzone causes you additional issues, but it could be that you are reinitializing RTT block from firmware, which throws off the debugger. You have to initialize RTT manually in that case, because defmt/rtt_target libs do not support reusing already initialized block. Here is what I did: https://gist.github.com/chemicstry/939293905c7766330c73f39efaee2ebd You then wire up...

12:16 <re_irc> ... "TERMINAL_CHANNEL" as defmt sink

12:17 <re_irc> < (@chemicstry:matrix.org)> I'm not sure if trustzone causes you additional issues, but it could be that you are reinitializing RTT block from firmware, which throws off the debugger. You have to initialize RTT manually in that case, because defmt/rtt_target libs do not support reusing already initialized block. Here is what I did: https://gist.github.com/chemicstry/939293905c7766330c73f39efaee2ebd You then wire up returned...

12:17 <re_irc> ... "UpChannel" as defmt sink

12:18 <re_irc> < (@chemicstry:matrix.org)> oh and you also need to define rtt block section in linker so that it is always in the same RAM location

12:18 <re_irc> < (@chemicstry:matrix.org)> for both bootloader and firmware

14:41 <re_irc> <riskable> Anyone have any ideas why this single bit of code would cause my firmware to hang?

14:41 <re_irc> .product("Riskeyboard 70")

14:41 <re_irc> .manufacturer("Riskable")

14:41 <re_irc> let usb_key_dev = UsbDeviceBuilder::new(usb_bus, UsbVidPid(VID, PID))

14:41 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/hUEZGc0lUKhsPlLyMLinf2lwciQwnzJY (8 lines)

14:42 <re_irc> <riskable> It's an old stm32f4xx_hal (stm32f411) project that I resurrected recently to make a very minor change. It compiles fine after making the change but when I flash and run it it just hangs. I put in a zillion debug statements to figure out that's where it hangs 🤷

14:42 <re_irc> <riskable> The thing that baffles me: This isn't part of the code that changed! haha

14:42 <re_irc> <Félix | Totem> riskable: There is a precise order in which you are supposed to create the various USB stuff. You can try to tweak that. In my project, I need to create first the bus, then the class, then the device.

14:42 <re_irc> <Félix | Totem> Before I used that order, I was in the same situation as you

14:43 <re_irc> <riskable> Félix | Totem: Yeah I tried moving it all around... Didn't make any difference. It still hangs on that line

14:43 <re_irc> <riskable> I even tried getting rid of basically everything else the code does. It's an RTIC (0.5) project and I basically reduced it to a bare bones thing to narrow this down

14:43 <re_irc> < (@dirbaio:matrix.org)> maybe it's panicking. Maybe add a "panic!("foo");" to check that your panic message printing is working

14:44 <re_irc> <riskable> : Good idea! I'll try that

14:44 <re_irc> <Félix | Totem> riskable: Isn't that an old version of RTIC?

14:44 <re_irc> <Félix | Totem> Are you talking about "cortex-m-rtic"

14:44 <re_irc> <riskable> Félix | Totem: Oh yes. very!

14:45 <re_irc> <riskable> Like, I _can_ spend a ton of time porting this to the latest & greatest everything but _I don't wanna!_ hahaha

14:45 <re_irc> <riskable> That's a lot of work for what should be a trivial change

14:45 <re_irc> <Félix | Totem> Yeah, right, it depends of the amount of lines to update

14:45 <re_irc> <Félix | Totem> * on

14:46 <re_irc> <riskable> : I put "panic!("Testing panics");" in the code just above that USB initialization line and it panicked like it should...

14:46 <re_irc> stack backtrace:

14:46 <re_irc> <exception entry>

14:46 <re_irc> 0: HardFaultTrampoline

14:46 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/exxwjxEFr615XDEvEnpyWfxdJfHCPRpR (14 lines)

14:46 <re_irc> <riskable> Though the panic _message_ is nowhere to be found which is... Interesting

14:47 <re_irc> < (@dirbaio:matrix.org)> if you're using "panic-probe" enable feature "print-defmt"

14:47 <re_irc> < (@dirbaio:matrix.org)> but yea if this one hardfaults and the other doesn't it's maybe not a panic...

14:48 <re_irc> < (@dirbaio:matrix.org)> stack overflow maybe?

14:48 <re_irc> <riskable> To enable the debugging (the old "rtt-target" stuff wasn't working) I switched it over to:

14:48 <re_irc> panic-probe = { version = "0.3", features = ["print-defmt"] }

14:48 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/Vxk49Qi7oq63cdeKky3nYSyteQEw5jv2 (6 lines)

14:48 <re_irc> defmt = "0.3"

14:48 <re_irc> defmt-rtt = "0.4.0"

14:50 <re_irc> < (@dirbaio:matrix.org)> that looksok, it should print the panic message...

14:50 <re_irc> <riskable> For reference, I suspect this _could_ be a bug that was introduced in some version of "stm32f4xx-hal" version 0.9.X but since that package went through a pretty rapid and regular evolution no one noticed (it's now on 0.14.X). Right now I'm thinking I'll try various older versions of the 0.9 series to see if that fixes it and if not probably start porting this to the latest & greatest RTIC stuff

14:51 <re_irc> < (@anand21:matrix.org)> : Thank you for the response. so what i understood is We need to add this code in the firmware, and avoid re initialisation of rtt.

14:51 <re_irc> is this correct?

14:55 <re_irc> < (@chemicstry:matrix.org)> : well it's a snippet from a "startup" code so it has a lot of hacks and might need massaging to get working. But the general idea is that you have to do same initialization as those libs do (defmt/rtt), but omit overwriting RTT block if it's already there

14:56 <re_irc> < (@chemicstry:matrix.org)> I guess you could also modify the libs and submit a PR for such use case

14:58 <re_irc> < (@anand21:matrix.org)> : Ok thank you for the clarification. Will try to raise a PR.

14:59 <re_irc> <riskable> OK nothing I've tried works so *I guess I'm porting this code to RTIC 1.1! This is going to take _hours_... Sigh

15:00 <re_irc> < (@datdenkikniet:matrix.org)> can you see any useful information when you break the program at the point where it hangs?

15:00 <re_irc> < (@datdenkikniet:matrix.org)> (defmt-rtt has support for backtraces, I believe)

15:01 <re_irc> < (@datdenkikniet:matrix.org)> * believe, but not sure if/what kind of changes it would require to activate it if you haven't, yet)

15:02 <re_irc> < (@datdenkikniet:matrix.org)> maybe can you find some useful information in the backtrace when you break the program at the point where it hangs?

15:02 <re_irc> < (@datdenkikniet:matrix.org)> maybe can you find some useful information in the backtrace if you interrupt the program at the point where it hangs?

15:05 <re_irc> < (@datdenkikniet:matrix.org)> as in: is it "just" that line with the UsbDeviceBuilder, or does the point at which "build" hangs give some useful feedback?

15:05 <re_irc> < (@datdenkikniet:matrix.org)> +(assuming that it's "build")

17:05 <re_irc> <riskable> OK so I just updated everything to the latest & greatest RTIC, stmf4xx_hal, and others and... Wow, I wish the borrow checker could've told me this _before_ haha:

17:05 <re_irc> ERROR panicked at 'already borrowed: BorrowMutError', /home/riskable/.cargo/registry/src/github.com-1ecc6299db9ec823/usb-device-0.2.9/src/bus.rs:194:36

17:05 <re_irc> └─ panic_probe::print_defmt::print @ /home/riskable/.cargo/registry/src/github.com-1ecc6299db9ec823/panic-probe-0.3.0/src/lib.rs:91

17:05 <re_irc> So apparently I'm just borrowing the USB_BUS in more than one place or some way that's not appropriate.

17:06 <re_irc> < (@ryan-summers:matrix.org)> That's usually the case when someone is using some internal "RefCell"

17:06 <re_irc> < (@ryan-summers:matrix.org)> * "RefCell", which implies run-time borrow-checking rules

17:07 <re_irc> < (@ryan-summers:matrix.org)> And yeah, it seems like you may be using the USB bus peripheral in multiple contexts?

17:09 <re_irc> <riskable> : I'm not using anything fancy like "RefCell"

17:11 <re_irc> < (@ryan-summers:matrix.org)> usb-device uses it internally

17:12 <re_irc> < (@ryan-summers:matrix.org)> * internally, see https://docs.rs/usb-device/0.2.9/src/usb_device/bus.rs.html#150

18:05 <re_irc> <riskable> For reference, if you're getting a similar 'already borrowed' error when trying to use "UsbDeviceBuilder" it's because you need to create your other USB devices _before_ that in the code. For example, I'm creating a USB mouse and a keyboard. I had the mouse code after I was calling "UsbDeviceBuilder" which was causing that error.

18:28 <re_irc> <Félix | Totem> There sometimes are really weird side effects. If I set a led to on inside a loop, everything works, if I remove that line, the initialization crashes (I think it crashes there).

18:28 <re_irc> That looks like what would happen when there is an UB 🤔

18:29 <re_irc> <Félix | Totem> The code looks like that:

18:29 <re_irc> #[task(local = [matrix, leds], shared = [usb_class])]

18:29 <re_irc> fn matrix_scan(mut cx: matrix_scan::Context) {

18:29 <re_irc> let keys = cx.local.matrix.scan();

18:29 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/AqhSPeVlXvkvGEoBKFumioDUmmvRsjwm (24 lines)

18:50 <re_irc> <Félix | Totem> I think it's due to the fact I use a local data inside a lock block

18:51 <re_irc> < (@korken89:matrix.org)> Félix | Totem: That does not matter in RTIC, locals are simply "&mut" references to static memory

18:51 <re_irc> < (@korken89:matrix.org)> They do not interact with locks

18:52 <re_irc> < (@korken89:matrix.org)> That does not matter in RTIC, locals are simply "&mut" references to static memory with appropriate imposed lifetime

18:53 <re_irc> < (@korken89:matrix.org)> The side effect must be from optimization happening in a different way

18:55 <re_irc> <henrik_alser> Félix | Totem: Are you running in —release?

19:26 <re_irc> <Félix | Totem> henrik_alser: Yes. I think the bin wouldn't fit in the board otherwise

19:27 <re_irc> <Félix | Totem> : This shouldn't happen, right?

19:33 <re_irc> < (@korken89:matrix.org)> Sounds weird to me

19:35 <re_irc> <henrik_alser> Félix | Totem: how do you do the poll?

19:39 <re_irc> <Félix | Totem> henrik_alser: #[task(binds = USB_LP, shared = [usb_device, usb_class])]

19:39 <re_irc> fn usb_poll(cx: usb_poll::Context) {

19:39 <re_irc> usb_device.poll(&mut [usb_class]); // Dispatches to the class

19:39 <re_irc> (cx.shared.usb_device, cx.shared.usb_class).lock(|usb_device, usb_class| {

19:39 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/UoNESd44y8cN856EUEf8s7s1VTIEYnnv (6 lines)

19:39 <re_irc> <Félix | Totem> LP means low priority. There also is a USB_HP