ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<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.
<re_irc> <James Munns> Does it panic and the probe-run just keeps running? or does it exit silently?
<re_irc> <Phil Markgraf> probe-run just keeps on running
<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.
<re_irc> <James Munns> (it only catches things like a halt due to a "UDF" instruction)
<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.
<re_irc> <Phil Markgraf> It looks like panic-halt; the profile has panic="abort" set
<re_irc> <James Munns> hmmm
<re_irc> <James Munns> yeah, that makes sense
<re_irc> <James Munns> panic halt just spins in a loop, IIRC
<re_irc> <James Munns> Try replacing that with:
<re_irc> panic-probe = { version = "0.3.0", features = ["print-defmt"] }
<re_irc> <James Munns> Because with "panic-halt", your program never ends :)
<re_irc> <James Munns> (panic = abort/unwind specifies what happens AFTER the panic handler)
<re_irc> <James Munns> unless you're using the unstable panic_immediately_abort, which replaces the panic handler with a UDF instruction.
<re_irc> <Phil Markgraf> Thank you, James! (Now I need to wrangle the linker error that resulted from the change. Sigh. Maybe Monday...)
<re_irc> <James Munns> What'd you get? If you weren't using defmt before, you'll be missing defmt's linker section
<re_irc> <James Munns> you could instead omit a panic handler crate entirely, and replace it with:
<re_irc> use core::panic::PanicInfo;
<re_irc> #[inline(never)]
<re_irc> #[panic_handler]
<re_irc> <James Munns> which is more or less what panic probe does (+ printing panic information, but that halts the process for probe-run).
<re_irc> <James Munns> btw, if you aren't using the "app-template" with defmt, I highly recommend it!
<re_irc> <James Munns> I think RTIC also provides a similar version.
fabic has joined #rust-embedded
<re_irc> <James Munns> This might be the fix to your linker issue:
<re_irc> <9names (> 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 ( if you just want to check if it's possible and how difficult it will be.
cr1901__ has joined #rust-embedded
cr1901_ has quit [Ping timeout: 240 seconds]
cr1901__ is now known as cr1901
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
fabic has quit [Ping timeout: 276 seconds]
explore has quit [Quit: Connection closed for inactivity]
fabic has joined #rust-embedded
fabic has quit [Client Quit]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 276 seconds]
explore has joined #rust-embedded
neceve has joined #rust-embedded
fabic has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <James Munns> Crossposting here, but im gunna be focusing on Postcard in May, to get it to 1.0:
<re_irc> <James Munns> Hit me up if you have thoughts or feelings about that :D
<re_irc> <newam> Feelings: yay! I love postcard.
neceve has quit [Ping timeout: 240 seconds]
neceve has joined #rust-embedded
<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?
<re_irc> <korken89> For when custom logging defmt of course, not when using probe run
<re_irc> <korken89> I wonder if defmt_decoder will accept an elf with only the .defmt header...
<re_irc> <newam> Someone made an offline defmt logger that writes to non-volatile memory for later retrieval, I can't find it though :|
<re_irc> <newam> if that's what you're looking for
<re_irc> <korken89> I've made a few of those
<re_irc> <korken89> I just don't want to store the entire elf for decoding logs
<re_irc> <newam> ah gotcha
<re_irc> <korken89> We automatically save every build we do, and it starts to get quite big
<re_irc> <newam> In theory you could just do that with objdump I think
<re_irc> <newam> then reconstitute it into an ELF later
<re_irc> <newam> with objcopy or something
<re_irc> <korken89> Yeah
<re_irc> <korken89> I think I need to give this a try, would be nice to get working
<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
<re_irc> <GrantM11235> Can anyone tell what is going on with this PR?
<re_irc> <GrantM11235> I think it is supposed to fix the defmt "debug info not found" bug, but the PR is stalled or something
starblue has quit [Ping timeout: 276 seconds]
<re_irc> <newam> bors tagged it "waiting-on-author" so I assume someone just needs to bors it again, probably without a rollup?
fabic has quit [Ping timeout: 246 seconds]
<re_irc> <James Munns> newam: I have one for volatile mem, though you could drain it into nonvol mem:
<re_irc> <James Munns> but yeah, I've also been interested in a lighter "defmt decoder" without the elf.
<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
<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.
<re_irc> <James Munns> (I'm thinking like database rows of defmt data, with a reference to a row containing the decoding info).
<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.
<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.
<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.
<re_irc> <kelleyk> Does that ring any bells?
<re_irc> <kelleyk> Or are people approaching things differently these days?
<re_irc> <newam> There is a lot of that sort or work floating around, I have done similar things at work.
<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.
<re_irc> - Xilinx has a fork for their PCIe SoC that forwards PCIe traffic between two QEMUs (good for reference)
<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.
<re_irc> <newam> * e.g. if
<re_irc> <kelleyk> Hm, thanks for the links/references. Wondering if what I'm remembering is something that we hacked together.
<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
<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.
<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.
<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.
<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.
<re_irc> if you can export a C function then it is pretty easy
<re_irc> <newam> kelleyk: I did something like this for an Ethernet device:
<re_irc> Wrote a register-level simulation that uses "std::net"
<re_irc> <kelleyk> Very interesting, thanks for the link... I'll take a look!
<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?
<re_irc> <newam> I didn't go that far, I only used it as a building block for building libraries ontop of the W5500.
<re_irc> For simulating an entire application I would use QEMU, interrupts are really difficult to simulate accurately otherwise.
<re_irc> <newam> QEMU could be anywhere from a small to large task depending on how many of your peripherals are implemented
<re_irc> <newam> synopsys designware, xilinx, and intel IP usually have good representation, not sure about other vendors
<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.
<re_irc> <kelleyk> This is just an STM32H7, so hopefully it'll be less of an adventure ;). Famous last words, though.
<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)
<re_irc> <newam> ST peripherals would be pretty straightforward to implement though
crabbedhaloablut has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #rust-embedded
starblue has joined #rust-embedded
neceve has quit [Ping timeout: 256 seconds]
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
<re_irc> <Tom> are there any hal's for something like litex + vexrisc or neorv32
<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 #
<re_irc> <Tom> * $ it seems)
<re_irc> <James Munns> CC adamgreig disasm, I know y'all are doing this
<re_irc> <adamgreig> I've not used it but might be of interest
dequbed has joined #rust-embedded
<re_irc> <sajattack> I have an unfinished litepcie crate
<re_irc> <sajattack> if anyone has a desire for that I could potentially be motivated to finish it
<re_irc> <sajattack> in terms of generating a pac for vexriscv, you can convince litex to spit out an svd
<re_irc> <sajattack> esden has done some work with this
<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.
<re_irc> <sajattack> too humble :P
<re_irc> <esden> Credit due where credit is due. 😅
<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.
<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)