02:01 <jakmik2[m]> Howdy! I was wondering if someone could help me with `05-meet-your-software` step `5.3 Debug It`. I'm on an M1 Macbook pro and can get as far as `break main` in `gdb`. After running `continue`, I never hit the breakpoint again. Not sure what's gone wrong.

09:10 <M9names[m]> do you set any other breakpoints?

09:10 <M9names[m]> only hitting the breakpoint on main once is intended behaviour, did you expect something else?

10:04 <mameluc[m]> <mameluc[m]> "Frame 0: "HardFault handler..." <- Got reset on panic to work, pretty ugly and idk why it works... (full message at <https://catircservices.org/_irc/v1/media/download/AdhW_NrPgGc1c-WkQnUK8Gd3PjBvAwB0AZs6yB7X3kM3MlqDu6fYrLuhu0bfdEAc0_I9EVc93mqNhLk9wd47-8u_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9QbmVvYkxEalVKamlyblljaWJZbkV1U0g>)

11:06 <dngrs[m]> yo dawg I heard you liked hardfaults so I put hardfaults in your hardfaults

11:12 <JamesMunns[m]> <mameluc[m]> "Frame 0: "HardFault handler..." <- If your stack is bad bad corrupted, the function prelude of entering panic might access the stack and cause a double fault (just a guess)

11:13 <mameluc[m]> well I am just testing out what happens if my fw panics so I put only a led blink and a panic! in main so should not even be corrupted

11:14 <mameluc[m]> Could be corrupted for some other reasons ofc.. I do have a small linker script

11:14 <JamesMunns[m]> yeah, not sure, just thinking of things that could cause a double fault

11:17 <mameluc[m]> JamesMunns[m]: yeah, I am pretty much out of my depths when it comes to understanding this stuff.

11:17 <mameluc[m]> I am just trying to avoid getting stuck in a loop burning battery

11:17 <mameluc[m]> wdt seems to draw power in standby so that doesn't help me either

12:17 <jason-kairos[m]> Is there a crate like `bitfield` or `binary-serde` that allows for validation to be built int?

12:17 <jason-kairos[m]> eg. `foo` must be between `10` and `1000` and has a default value of `100`

12:17 <jason-kairos[m]> * Is there a crate like `bitfield` or `binary-serde` that allows for validation to be built in? (maybe to the type definition)

12:17 <jason-kairos[m]> eg. `foo` must be between `10` and `1000` and has a default value of `100`

13:31 <dngrs[m]> there was a talk about ranged integers recently, I think at RustWeek... and again iirc it mentioned upcoming compiler features that'll be useful for that

13:31 <dngrs[m]> for defaults you can impl Default

13:34 <mameluc[m]> <jason-kairos[m]> "Is there a crate like `bitfield`..." <- Probably not helpful for you but I use zerocopy + bitfield-struct. You don't get min-max validation like that, only validation that some number is 5 bit or something. You can also check that some number corresponds to an enum.

13:36 <mameluc[m]> If you need something to be 10-100 you could probably make a custom type for it and impl try_from

13:42 <jason-kairos[m]> <mameluc[m]> "Probably not helpful for you but..." <- I actually was just looking into zerocopy - looks like it would permit me to write wrapper/newtypes that provided a default value, as well as clamping to min and max via setters/getters

13:43 <jason-kairos[m]> I'd happily drop binary-serde in favor of zerocopy - although I do rely upon the BinarySerialize trait. I think zerocopy provides something equivalent

13:55 <mameluc[m]> Zerocopy is nice for stuff where somebody else decides on the data format (just don't look at the expanded derive macros, there is a lot of stuff there..). For stuff that I can decide over the format I use postcard. With validation I prefer to do it as early as possible so that "invalid states are impossible". When sending data from the server to my device I use the validator crate server side to validate my data is correct before

13:55 <mameluc[m]> sending. On the device side I don't have validation but there is also nothing in the conf that should brick the device.

14:14 <jason-kairos[m]> when stuff gets stored into external memory it can get invalid for various reasons - I cover that with wrapper type. But also wish to guard against programming errors.

14:14 <jason-kairos[m]> * when stuff gets stored into external memory it can get invalid for various reasons - I cover that with low level wrapper type with CRC/etc.. But also wish to guard against programming errors.

17:56 <JamesMunns[m]> (probably won't be here for the meeting this week, hope everyone had/has a good week!)

18:01 <adamgreig[m]> hi @room, meeting time again! thanks James Munns for running last week too. agenda is https://github.com/rust-embedded/wg/discussions/842, please add anything you'd like to discuss or announce and we'll start in a few minutes!

18:04 <adamgreig[m]> let's begin; I haven't had much time to prep an agenda for this week so might be a fairly short meeting

18:04 <adamgreig[m]> we have announcements for esp-hal v1.0.0-beta.1 (https://github.com/esp-rs/esp-hal/releases/tag/esp-hal-v1.0.0-beta.1) and riscv 0.14/0.3/0.15 https://github.com/rust-embedded/riscv/releases/tag/v0.14.0 🎉

18:11 <adamgreig[m]> and besides those announcements I don't think I have anything for this week, no update on the new charter stuff yet

18:11 <adamgreig[m]> any other topics from anyone?

18:11 <balbi[m]> Do you want to discuss panic-never or is that settled?

18:12 <adamgreig[m]> is that from last week? not sure what/if there's any new updates there

18:12 <jannic[m]> I didn't have much time for ticket triage this week, and could only suggest to close https://github.com/rust-embedded/embedded-hal/issues/40 because it was superseded by embedded_io.

18:14 <adamgreig[m]> good call, thanks!

18:18 <adamgreig[m]> well, let's call it there, hopefully I'll have a bit more to talk about next week!

20:09 <KevinPFleming[m]> How challenging is it to get the linker to put the program into a section not named FLASH?

20:10 <thejpster[m]> code goes into an object code section named .text with the line copies to an ELF segment called .text (because the linker script tells it to) which is allocated from a Region called FLASH (because the linker script told it to)

20:11 <thejpster[m]> Do you want to move some of the program or all of the program?

20:11 <thejpster[m]> s/with/which/, s/line/linker/

20:34 <KevinPFleming[m]> All of it

20:34 <i509vcb[m]> iirc some of the embassy tests do run from ram

20:35 <i509vcb[m]> looks like a modification of the cortex-m-rt stuff

20:36 <i509vcb[m]> https://github.com/embassy-rs/embassy/blob/main/tests/link_ram_cortex_m.x

20:37 <KevinPFleming[m]> Ahh, so the real linker script, not the simplified memory.x one.

20:38 <i509vcb[m]> the real linker script is probably in cortex-m

20:38 <i509vcb[m]> * in cortex-m-rt

21:09 <thejpster[m]> cmrt gives you a file called link.x, but you tell the rust compiler which script you want to use. You can just use your own if you like. link.x imports a file called memory.x, which must define the various regions required.

21:09 <thejpster[m]> The interesting question is - how does the code get into RAM after a power cycle?

23:07 <KevinPFleming[m]> OK, thanks for the tips, I think I understand now. `cortex-m-rt` has both `link.x.in` and `build.rs`; the build script reads the linker script input file, writes it out to `link.x`, and potentially adds a few things to the end, but otherwise does not transform the input at all.

23:07 <KevinPFleming[m]> Would there be any willingness to allow the build script to read an optional environment variable, and if it is found, use its contents to *replace* the `FLASH` strings in the linker script input file?

23:07 <KevinPFleming[m]> Motivation is for a project using embassy-boot: the project has a 'bootloader' crate and an 'application' crate, and I want to be able to use the same `memory.x` file for both, to eliminate any need to keep two files in sync. If I can set an environment variable in `.cargo/config.toml` to cause each of those crates to land in its own region, that makes it easy to use.