00:00 <re_irc> <Phil Markgraf> I am using probe-run in my project. This has been successfully running my target program, but I recently realized it is not echoing out when a panic occurs. (I ended up making "panic!()" the first statement in main(), to test this.) -- Is there something I should look for to figure out what is going wrong.

00:01 <re_irc> <James Munns> Does it panic and the probe-run just keeps running? or does it exit silently?

00:02 <re_irc> <Phil Markgraf> probe-run just keeps on running

00:03 <re_irc> <James Munns> If it's the former, what panic handler crate are you using? If you use something like panic-reset, probe-run wont "notice" the reset.

00:03 <re_irc> <James Munns> (it only catches things like a halt due to a "UDF" instruction)

00:04 <re_irc> <James Munns> I've also seen this for things like soft resets, e.g. "SCB::sys_reset()", or even things like watchdog resets.

00:05 <re_irc> <Phil Markgraf> It looks like panic-halt; the profile has panic="abort" set

00:05 <re_irc> <James Munns> hmmm

00:05 <re_irc> <James Munns> yeah, that makes sense

00:05 <re_irc> <James Munns> panic halt just spins in a loop, IIRC

00:06 <re_irc> <James Munns> Try replacing that with:

00:06 <re_irc> panic-probe = { version = "0.3.0", features = ["print-defmt"] }

00:07 <re_irc> <James Munns> Because with "panic-halt", your program never ends :)

00:07 <re_irc> https://github.com/korken89/panic-halt/blob/master/src/lib.rs#L29-L35

00:07 <re_irc> <James Munns> (panic = abort/unwind specifies what happens AFTER the panic handler)

00:08 <re_irc> <James Munns> unless you're using the unstable panic_immediately_abort, which replaces the panic handler with a UDF instruction.

00:11 <re_irc> <Phil Markgraf> Thank you, James! (Now I need to wrangle the linker error that resulted from the change. Sigh. Maybe Monday...)

00:13 <re_irc> <James Munns> What'd you get? If you weren't using defmt before, you'll be missing defmt's linker section

00:15 <re_irc> <James Munns> you could instead omit a panic handler crate entirely, and replace it with:

00:15 <re_irc> use core::panic::PanicInfo;

00:15 <re_irc> #[inline(never)]

00:15 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/bd275fd6b3970c9457607f191f214b4a0f4f4c5ee4a5dd6519a62095cfffb6c9 (7 lines)

00:15 <re_irc> #[panic_handler]

00:15 <re_irc> <James Munns> which is more or less what panic probe does (+ printing panic information, but that halts the process for probe-run).

00:16 <re_irc> <James Munns> btw, if you aren't using the "app-template" with defmt, I highly recommend it!

00:16 <re_irc> https://github.com/knurling-rs/app-template/

00:16 <re_irc> <James Munns> I think RTIC also provides a similar version.

00:16 <re_irc> <James Munns> This might be the fix to your linker issue: https://github.com/knurling-rs/app-template/blob/main/.cargo/config.toml#L7

00:34 <re_irc> <9names (@9names:matrix.org)> Tatu Pesonen: depending on how complex your PoC is, you might be able to do what you want with an ESP32 or ESP32-C3. it would be worth asking in #esp-rs:matrix.org (https://matrix.to/#/#esp-rs:matrix.org) if you just want to check if it's possible and how difficult it will be.

14:03 <re_irc> <James Munns> Crossposting here, but im gunna be focusing on Postcard in May, to get it to 1.0: https://twitter.com/bitshiftmask/status/1520402889394503681

14:03 <re_irc> <James Munns> Hit me up if you have thoughts or feelings about that :D

14:04 <re_irc> <newam> Feelings: yay! I love postcard.

16:12 <re_irc> <korken89> Hmm, has anyone tried extracting only the .defmt section from an elf to generate a "log header file" with minimal size for decoding defmt logs?

16:13 <re_irc> <korken89> For when custom logging defmt of course, not when using probe run

16:13 <re_irc> <korken89> I wonder if defmt_decoder will accept an elf with only the .defmt header...

16:13 <re_irc> <newam> Someone made an offline defmt logger that writes to non-volatile memory for later retrieval, I can't find it though :|

16:13 <re_irc> <newam> if that's what you're looking for

16:14 <re_irc> <korken89> I've made a few of those

16:14 <re_irc> <korken89> I just don't want to store the entire elf for decoding logs

16:14 <re_irc> <newam> ah gotcha

16:14 <re_irc> <korken89> We automatically save every build we do, and it starts to get quite big

16:14 <re_irc> <newam> In theory you could just do that with objdump I think

16:15 <re_irc> <newam> then reconstitute it into an ELF later

16:15 <re_irc> <newam> with objcopy or something

16:16 <re_irc> <korken89> Yeah

16:17 <re_irc> <korken89> I think I need to give this a try, would be nice to get working

16:17 <re_irc> <newam> ELFs also compress quite well if your CI system allows it. At work we generate 2TB a week of binaries, I understand your pain :P

16:22 <re_irc> <GrantM11235> Can anyone tell what is going on with this PR? https://github.com/rust-lang/rust/pull/95685

16:23 <re_irc> <GrantM11235> I think it is supposed to fix the defmt "debug info not found" bug, but the PR is stalled or something

16:24 <re_irc> <newam> bors tagged it "waiting-on-author" so I assume someone just needs to bors it again, probably without a rollup?

16:43 <re_irc> <James Munns> newam: I have one for volatile mem, though you could drain it into nonvol mem: https://github.com/jamesmunns/defmt-bbq/

16:43 <re_irc> <James Munns> but yeah, I've also been interested in a lighter "defmt decoder" without the elf.

16:43 <re_irc> <James Munns> I think there's two parts: The interned symbols, and the additional (debuginfo?) data that's used for line tracking and backtraces

16:44 <re_irc> <James Munns> Ideally, being able to split that out into some kind of plaintext (or even binary file) that some defmt-decoder tool could take would be pretty cool.

16:45 <re_irc> <James Munns> (I'm thinking like database rows of defmt data, with a reference to a row containing the decoding info).

17:00 <re_irc> <kelleyk> Is anyone testing in QEMU with emulated I2C devices? (Simulated integration testing, basically?) Would love to peek at how folks have that set up but I can't find much.

17:02 <re_irc> <newam> I don't have any code I can share, but I have done lots of QEMU at work, happy to answer questions.

17:11 <re_irc> <kelleyk> I remember there being a thing (maybe in one of the embedded-focused QEMU forks?) that did bus-level I2C stuff rather than device-level (like my impression is that mainline QEMU likes to do). I think that it basically forwarded I2C bus traffic to a socket, and then we had a program that emulated whatever devices and sent traffic back to QEMU over the socket.

17:11 <re_irc> <kelleyk> Does that ring any bells?

17:12 <re_irc> <kelleyk> Or are people approaching things differently these days?

17:16 <re_irc> <newam> There is a lot of that sort or work floating around, I have done similar things at work.

17:16 <re_irc> One of the big limitations of QEMU is that it can only simulate heterogeneous CPUs. If you want to simulate an x86_64 USB host and a Cortex-M USB device you need two QEMUs.

17:16 <re_irc> - Xilinx has a fork for their PCIe SoC that forwards PCIe traffic between two QEMUs (good for reference)

17:16 <re_irc> - QEMU has mp-QEMU, this looks like what you want, but it really isn't, it is designed for encapsulating devices in separate QEMU processes. Lots of the underlying code can be hacked up into what you want.

17:16 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/279c469c16a4d1cf91c8cba4bcf88ef6e790516ff5e1c71fb22fa96fce03c4fa (6 lines)

17:17 <re_irc> <newam> * e.g. if

17:18 <re_irc> <kelleyk> Hm, thanks for the links/references. Wondering if what I'm remembering is something that we hacked together.

17:19 <re_irc> <newam> if your I2C device is simple you can write the model in QEMUs framework pretty easily. You don't _really_ need to start doing multiple QEMU's until you have multiple devices with CPUs + firmware that you need to simulate

17:19 <re_irc> <kelleyk> In this particular case I'm trying to emulate a Cortex-M7F with some I2C-attached sensors/actuators; don't need to simulate a whole army of different CPUs.

17:20 <re_irc> <kelleyk> Right, I don't think that I need multiple QEMUs here... mostly just need to have the integration-test framework be able to (say) feed sensor values.

17:21 <re_irc> <kelleyk> Maybe adding per-device models to QEMU is something to explore. Was also thinking about playing with "embedded-hal-mock", since "embedded-hal" is so lovely... mostly as a way to test higher-level application logic.

17:23 <re_irc> <newam> kelleyk: Ah that part is pretty easy, for I2C devices you just get an array of bytes and what you do from there is up to you.

17:23 <re_irc> if you can export a C function then it is pretty easy

17:23 <re_irc> <newam> kelleyk: I did something like this for an Ethernet device: https://github.com/newAM/w5500-rs/tree/main/regsim

17:24 <re_irc> Wrote a register-level simulation that uses "std::net"

17:24 <re_irc> <kelleyk> Very interesting, thanks for the link... I'll take a look!

17:34 <re_irc> <kelleyk> So with the W5500 register-level sim, did you then build/run the application that was expecting the W5500 on your host machine?

17:35 <re_irc> <newam> I didn't go that far, I only used it as a building block for building libraries ontop of the W5500.

17:35 <re_irc> For simulating an entire application I would use QEMU, interrupts are really difficult to simulate accurately otherwise.

17:36 <re_irc> <newam> QEMU could be anywhere from a small to large task depending on how many of your peripherals are implemented

17:37 <re_irc> <newam> synopsys designware, xilinx, and intel IP usually have good representation, not sure about other vendors

17:38 <re_irc> <kelleyk> Yes, the last time that I did this, there was a bunch of exotic stuff and custom silicon involved. I remember that being a giant pain in the butt.

17:38 <re_irc> <kelleyk> This is just an STM32H7, so hopefully it'll be less of an adventure ;). Famous last words, though.

17:39 <re_irc> <newam> There is some ST stuff in QEMU, but it might be older versions of the peripherals, the H7 is pretty new (relatively)

17:39 <re_irc> <newam> ST peripherals would be pretty straightforward to implement though

22:05 <re_irc> <Tom> are there any hal's for something like litex + vexrisc or neorv32

22:06 <re_irc> <Tom> working on a project where I want a softcore with programmable logic (hard core would be cool too, but the ICs are a lot more #

22:06 <re_irc> <Tom> * $ it seems)

22:17 <re_irc> <James Munns> CC adamgreig disasm, I know y'all are doing this

22:27 <re_irc> <adamgreig> I've not used it but https://github.com/pepijndevos/rust-litex-hal might be of interest

22:28 <re_irc> <adamgreig> (blog post http://pepijndevos.nl/2020/08/04/a-rust-hal-for-your-litex-fpga-soc.html)

23:33 <re_irc> <sajattack> I have an unfinished litepcie crate

23:41 <re_irc> <sajattack> if anyone has a desire for that I could potentially be motivated to finish it

23:44 <re_irc> <sajattack> in terms of generating a pac for vexriscv, you can convince litex to spit out an svd

23:44 <re_irc> <sajattack> esden has done some work with this

23:45 <re_irc> <sajattack> https://github.com/icebreaker-fpga/icebreaker-litex-examples/tree/master/rust/icebesoc-pac

23:49 <re_irc> <esden> To be completely honest, it is mostly based on xobs work though... he extracted and boiled down some of his stuff he used for betrusted. https://github.com/betrusted-io/betrusted-soc

23:49 <re_irc> <sajattack> too humble :P

23:50 <re_irc> <esden> Credit due where credit is due. 😅

23:55 <re_irc> <xobs> Bunnie took the SVD files that are generated and decided he didn't want the PAC approach. Which it turns out didn't work in our OS anyway. But yeah, the SVD files that Litex spits out were designed to feed into svd2pac.

23:58 <re_irc> <xobs> (He designed utra, which is a more C-like approach to register accesses, was easier for him to understand when he was just starting out with Rust, and works if registers are remapped to a different address like what happens when using an MMU)