00:09 <M762spr[m]> Just got some nRF52840 dongles in the mail to play with!

00:09 <M762spr[m]> Is it possible to program them via probe-rs over USB (plugging the dongle into my PC) or does it have to go through SWD and a programmer?

00:10 <i509vcb[m]> If you can setup an image that mcuboot (which is what it ships with) can boot then probably

00:10 <i509vcb[m]> But you'd ideally want a debugger

00:10 <i509vcb[m]> And one that can track the target voltage

00:12 <Noah[m]> M762spr[m]: probe-rs only concerns debuggers :)

00:16 <M762spr[m]> Makes sense. I guess that's what I'm used to anyway but the prospect of just plugging it in and playing with it would be nice. At least they put a TC connector on there

00:17 <M762spr[m]> This is probably a question for a nRF (assuming there is one) but how does the loading of sorter ices work in the rust ecosystem? De we just load them the normal way with nRF tools and then make sure to flash past that with memory.x?

00:18 <M762spr[m]> s/sorter/softdevices/, s/ices//

00:18 <i509vcb[m]> There is also room on the bottom for soldering a 1.27mm IDC socket if you have the room there (and don't want the other pins)

00:19 <i509vcb[m]> s/socket/header/

00:23 <M762spr[m]> Thanks! That may be worth doing since the little retainer sockets for the tag connects never stay on...

00:23 <i509vcb[m]> I think it conflicts with the headers if you want it on a breadboard though

00:23 <i509vcb[m]> Actually a second

00:24 <i509vcb[m]> Those two are also SWD if you want to solder on headers on the bottom and then just dupont wire to it

00:28 <M762spr[m]> Thanks!

00:29 <M762spr[m]> For now I only need it to send some BLE messages so having it dangle on a programming cable won't be too bad but eventually I know I'll want to hook some stuff up to it.

00:30 <M762spr[m]> Looks like embassy has a nrf-softdevice repo. Shout out to the Embassy guys that make things so easy for the rest of us! 🫡

06:05 <thejpster[m]> I just use nrfdfu-rs with my dongle

08:09 <RobinMueller[m]> cr1901: To be honest, I had a look at the interrupts again, and I saw that almost all of them are disabled by default. So I think this is not a big of a concern I initially thought.. One other issue: I am thinking of introducing a bootloader + main app combo on the FRAM of the MSP430. Do you know if the mspdebug tool erases the full FRAM? There is only one IVT, so I probably need to do some black magic with copying around

08:09 <RobinMueller[m]> reset vectors, for example to ensure that my app only boots to the bootloader

08:10 <RobinMueller[m]> * one IVT and no VTOR offset register like on cortex-m4, so, * the bootloader. do you have experience with something like that?

09:25 <Matt[m]> Hello, I'm trying to write a bare-metal loader for a binary blob and I currently have:... (full message at <https://catircservices.org/_irc/v1/media/download/ATMr04IRiyN95KehQVf6PbQMhA8P8pvWe96Rz5MD8irdxl9W45kss3Qnd1vATN9w03B8TPmG37RK-w2yT0Mq6TS_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9ucHdTSEpWSm9OdHVMU2p2VGpQYmRIWU8>)

09:26 <Matt[m]> s/However, the DEST_ADDR and the data included from `include_bytes!` overlap. `core::ptr::copy` is emitting a `memcpy` intrinsic and so the copy fails. I can hand-roll a reverse copy loop but I'm trying to understand why the compiler is emitting `mempy` rather than `memmove`. My only thought is that `include_bytes!` returns a `& 'static`, so is the compiler assuming I can't write to that location so therefore there would never be any

09:26 <Matt[m]> overlap?/However, the `DEST_ADDR` and the data included from `include_bytes!` overlap. `core::ptr::copy` is emitting a `memcpy` intrinsic and so the copy fails. I can hand-roll a reverse copy loop but I'm trying to understand why the compiler is emitting `memcpy` rather than `memmove`. My only thought is that `include_bytes!` returns a `& 'static`, so is the compiler assuming I can't write to that location so therefore there would

09:26 <Matt[m]> never be any overlap?/

09:26 <Matt[m]> s/DEST_ADDR/`TARGET_ADDR`/, s/mempy/memcpy/

09:31 <Matt[m]> s/However, the DEST_ADDR and the data included from `include_bytes!` overlap. `core::ptr::copy` is emitting a `memcpy` intrinsic and so the copy fails. I can hand-roll a reverse copy loop but I'm trying to understand why the compiler is emitting `mempy` rather than `memmove`. My only thought is that `include_bytes!` returns a `& 'static`, so is the compiler assuming I can't write to that location so therefore there would never be any

09:31 <Matt[m]> overlap?/However, the `TARGET_ADDR` and the data included from `include_bytes!` overlap. According to the docs `core::ptr::copy` should have `memove` semantics but it is emitting a `memcpy` intrinsic and so the copy fails. I can hand-roll a reverse copy loop but I'm trying to understand why the compiler is emitting `memcpy` rather than `memmove`. My only thought is that `include_bytes!` returns a `& 'static`, so is the compiler

09:31 <Matt[m]> assuming I can't write to that location so therefore there would never be any overlap?/

09:31 <Matt[m]> s/However, the DEST_ADDR and the data included from `include_bytes!` overlap. `core::ptr::copy` is emitting a `memcpy` intrinsic and so the copy fails. I can hand-roll a reverse copy loop but I'm trying to understand why the compiler is emitting `mempy` rather than `memmove`. My only thought is that `include_bytes!` returns a `& 'static`, so is the compiler assuming I can't write to that location so therefore there would never be any

09:31 <Matt[m]> overlap?/However, the `TARGET_ADDR` and the data included from `include_bytes!` overlap. According to the docs `core::ptr::copy` should have `memmove` semantics but it is emitting a `memcpy` intrinsic and so the copy fails. I can hand-roll a reverse copy loop but I'm trying to understand why the compiler is emitting `memcpy` rather than `memmove`. My only thought is that `include_bytes!` returns a `& 'static`, so is the compiler

09:31 <Matt[m]> assuming I can't write to that location so therefore there would never be any overlap?/

09:38 <RobinMueller[m]> cr1901: are 20 bit-address read/writes supported in principle? I am trying to access FRAM beyond 0x10000 and encounter weird behaviour...

09:54 <thejpster[m]> @Matt: Plausible. Can you not configure the linker to locate the blob where it needs to be, instead of having to move it?

10:19 <Matt[m]> <thejpster[m]> "@Matt: Plausible. Can you not..." <- I had that same thought, but I don’t think it will make a difference? The compiler has already emitted code before we link, so the address wouldn’t matter?

10:20 <Matt[m]> In any case the address in the linked script is correct, so can statically infer that it is an overlapping copy.

10:21 <Matt[m]> s/linked/linker/

10:21 <Matt[m]> * In any case the address in the linker script is correct, so it can statically infer that it is an overlapping copy.

10:21 <Matt[m]> * In any case the address in the linker script is correct, so it can statically infer that it is an overlapping copy/move.

10:23 <Matt[m]> <thejpster[m]> "@Matt: Plausible. Can you not..." <- I don’t think so, I’m passing the blob eventually as the -kernel parameter to qemu. So I need a small bit of code to place the payload at the correct address in memory.

10:45 <thejpster[m]> Ah. Interesting.

11:34 <jason-kairos[m]> Silly followup question about interfacing with C, and bindgen:... (full message at <https://catircservices.org/_irc/v1/media/download/AWy4dfJF18HmCrQ0NJBU_AqV1ojmRhm-paN-783y0kf3-ulntltOx6wV2t84GbR0wu19BLK4-1FLiz7BS3_UX2i_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9YYUFERVFVV1ZZakFwaU16QXJ2ZVJmbHE>)

11:46 <dirbaio[m]> What do you mean with "doesn't work"?

11:46 <dirbaio[m]> U8's have an align of 1, so the layout of that struct is the same whether it's packed or not.

11:51 <jason-kairos[m]> I'm saying that I (either observed, or fooled myself into thinking) similar enums containing u8 fields having an alignment of 4 on arm cortex m0 with [repr(C)] and an alignment of 1 with [repr(packed)]

11:51 <jason-kairos[m]> * I'm saying that I (either observed, or fooled myself into thinking) similar enums containing u8 fields behaved as if they had an alignment of 4 on arm cortex m0 with \[repr(C)\] and an alignment of 1 with \[repr(packed)\]

11:52 <jason-kairos[m]> * I'm saying that in the past I (either observed, or more likely, fooled myself into thinking) similar enums containing u8 fields behaved as if they had an alignment of 4 on arm cortex m0 with \[repr(C)\] and an alignment of 1 with \[repr(packed)\]

11:53 <jason-kairos[m]> is there some place I can view a table of LLVM's alignment/etc. by target triplet?

11:54 <jason-kairos[m]> * I'm saying that in the past on a ARM Cortex M0+ platform I (either observed, or more likely, fooled myself into thinking) similar enums containing u8 fields behaved as if they had an alignment of 4 on with \[repr(C)\] and an alignment of 1 with \[repr(packed)\]

11:55 <jason-kairos[m]> * I suppose I'm saying that in the past on a ARM Cortex M0+ platform I (either observed, or more likely, fooled myself into thinking) similar enums containing u8 fields behaved as if they had an alignment of 4 on with \[repr(C)\] and an alignment of 1 with \[repr(packed)\]

11:56 <jason-kairos[m]> * I suppose I'm saying that in the past on a ARM Cortex M0+ platform I (either observed, or more likely, fooled myself into thinking) similar enums containing u8 fields behaved as if they had an alignment of something other than 1 (perhap 4?) on with \[repr(C)\] and an alignment of 1 with \[repr(packed)\]

11:58 <jason-kairos[m]> alternatively, is there some easy way to extact struct layout information from elf/object files?

11:59 <JamesMunns[m]> You can use align_of! and offset_of! In your rust code at least

11:59 <JamesMunns[m]> (and size_of!)

12:01 <jason-kairos[m]> suppose I've got a C library lib_something.a from gcc... (full message at <https://catircservices.org/_irc/v1/media/download/AdKj2L3sIwOmghFcx245NLYXrc_IH5z5uWfEn5QmHQWOSANXnjrKp_YD2xi6jHRmqVx4tAcckgWsTqWJ4dnE_je_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9zSGx2WnVmZWhqSnpIaWp3YWF4R1ZNRHQ>)

12:02 <jason-kairos[m]> I think it might be just tough to access than information to compare layouts directly

12:02 <jason-kairos[m]> s/just//

12:02 <jason-kairos[m]> s/just//, s/than/that/

12:04 <vollbrecht[m]> type information alone cannot be enough, for example tage the rust ffi c_char. Its dependend on the platform you are using.

12:04 <vollbrecht[m]> If you know use a dyn lib and call into it, that information how that other thing was made is not available to your types.

12:04 <vollbrecht[m]> s/tage/take/, s/c_char/c\_char/

12:04 <vollbrecht[m]> * type information alone cannot be enough, for example take the rust ffi c_char. Its dependend on the platform you are using.

12:04 <vollbrecht[m]> If you now use a dyn lib and call into it, that information how that other thing was made is not available to your types.

12:11 <jason-kairos[m]> I think gdb might be able to be coaxed into doing it in a statically linked binary (as is normal for embedded)... (full message at <https://catircservices.org/_irc/v1/media/download/AVtdWCu09y___8eOxYRhxgvVARUAPy5uHs-hke-4f1t1t-_l-eZK2BFwSK-rbntIvLloB1HBhucRhwGSadXHbhS_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9DaHZ0VUJGdEtRVmlFTHBia2drVmRad0k>)

12:12 <jason-kairos[m]> * I think gdb might be able to be coaxed into doing it in a statically linked binary (as is normal for embedded)... (full message at <https://catircservices.org/_irc/v1/media/download/AacX8CMNtnzSQI1Km8rv5AlaEJZlFKcOP4gpjlC0wb2qrTORcKpvrHPYPWTyI2qa9oXztwxSuuzvcled2hzcnse_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9TT2ROeVRhY2dpYXhIU2ZuZnFmVWJHTkM>)

12:21 <jason-kairos[m]> the symbols exist (they probably contain all of the layout information), I can tab complete them and search them.

12:21 <jason-kairos[m]> But for some reason it does not allow me print them

13:24 <jason-kairos[m]> okay - got lucky, talked with a gdb maintainer, and it's a bug - wohoo!

14:09 <jason-kairos[m]> Why isn't repr(c) the same as repr(packed)?

14:10 <jason-kairos[m]> I've wrangled the debugger into printing offsets for both C (gcc) and Rust (llvm)

16:37 <cr1901> RobinMueller[m]: 20 bit addresses would require LLVM support, and telling Rust about RAM, ROM, and I/O addrspaces. Tbh, I've never actually seen MSP430X code in the wild, so I don't know how TI's C compiler handles "data ptr len" != "code ptr len".

16:38 <cr1901> With AVR at least, all the addrspaces are the same width (16 bits) _I think_?

16:41 <cr1901> TLDR: Yea it's possible in principle, but I would "do what Rust AVR does and abstract the addrspace stuff away". Not clear to me how TI/other MSP430X users handle your issue of "go beyond 0x10000"

16:50 <RobinMueller[m]> cr1901: I suppose I will have to work with the first 65 kB (or more like 49 kB because of memory map setup) of the FRAM

16:52 <jason-kairos[m]> Has anyone here ever used or made a crate/type/etc. that automatically serializes and deserializes data - and adds/checks a CRC

16:52 <jason-kairos[m]> I currently use BinarySerde for reading and writing settings to and from flash. But often find myself wanting a version and a CRC code. Doing it manually is 'fine' but some day I'd like to automate it (or find a crate that does)

16:52 <jason-kairos[m]> * Has anyone here ever used or made a crate/type/etc. that automatically serializes and deserializes data in a struct - and adds/checks a CRC?

16:52 <jason-kairos[m]> I currently use BinarySerde for reading and writing settings to and from flash. But often find myself wanting a version and a CRC code. Doing it manually is 'fine' but some day I'd like to automate it (or find a crate that does)

16:53 <jason-kairos[m]> * Has anyone here ever used or made a crate/type/etc. that automatically serializes and deserializes data in a struct - and adds/checks a CRC?

16:53 <jason-kairos[m]> I currently use BinarySerde for reading and writing settings to and from flash. But often find myself wanting to attach a version number and a CRC code. Doing it manually is 'fine' but some day I'd like to automate it (or find a crate that does)

16:53 <dngrs[m]> jason-kairos[m]: James Munns and adamgreig have been through this a few times

16:54 <dngrs[m]> at least James is currently at RustWeek tho

16:54 <dngrs[m]> dunno about adam

16:54 <dngrs[m]> * dunno about Adam

16:55 <adamgreig[m]> (I'm also at rustweek)

16:55 <RobinMueller[m]> cr1901: have you ever implemented a multi-app boot, something similar like https://www.ti.com/lit/an/slaa600e/slaa600e.pdf?ts=1747228511901 using Rust?

17:24 <cr1901> RobinMueller[m]: Never implemented it, but I started implementing flash writing for MSP430, saw the crap jannic had to go through for RP2040, and decided its not something I want to do right now: https://github.com/rp-rs/rp-hal/issues/257#issuecomment-1212345394

17:26 <cr1901> Actually, I need to review this code again: https://github.com/jannic/rp2040-flash/blob/master/src/lib.rs There's actually _less_ inline asm than I remember...

17:30 <RobinMueller[m]> cr1901: This FRAM seems to have simple RAM like access for writes as well. I think it is just that only having one single IVT makes everything more tricky. Especially if I still want to use a regular dev workflow which overwrites the IVT (and therefore messes up the bootloader)

17:30 <RobinMueller[m]> s/as well//

17:30 <RobinMueller[m]> s/as/(or/, s/well/is this not the case? It did work like that for information memory)/

17:32 <RobinMueller[m]> * cr1901: This FRAM seems to have simple RAM like access for writes (or is this not the case? It did work like that for information memory). I think it is just that only having one single IVT makes everything more tricky. Especially if I still want to use a regular dev workflow which overwrites the IVT (and therefore messes up the bootloader). There is the option to remap the IVT to RAM, but that basically makes application

17:32 <RobinMueller[m]> compiled for app slot A/B unusable because those would have their IVT at a different location, for the bootloader to be copied to RAM..

17:32 <RobinMueller[m]> * cr1901: This FRAM seems to have simple RAM like access for writes (or is this not the case? It did work like that for information memory). I think it is just that only having one single IVT makes everything more tricky. Especially if I still want to use a regular dev workflow which overwrites the IVT (and therefore messes up the bootloader). There is the option to remap the IVT to RAM, but that basically makes application

17:32 <RobinMueller[m]> compiled for app slot A/B unusable for regular flashing because those would have their IVT at a different location, for the bootloader to be copied to RAM..

17:33 <cr1901> slot A/B?

17:34 <jason-kairos[m]> Do both x86 and ARM cortex M0 (eg. STM32) represent integers the same in memory?

17:34 <jason-kairos[m]> * in memory? (did some serialization stuff, and have backwards integers)

17:34 <ithinuel[m]> Cortex-M0 are typically using little endian.

17:35 <ithinuel[m]> * Cortex-M0 are typically using little endian.

17:35 <ithinuel[m]> 0x1234_5678 would be in memory as 0x78 at address 0, 0x56 at 1 etc.

17:36 <ithinuel[m]> From a quick google search it seems like x86 are the same.

17:40 <RobinMueller[m]> cr1901: basically, I have a bootloader and 2 applications inside executable FRAM. the bootloader determines which app to boot depending on a parameter in FRAM, and then boots that app

17:41 <cr1901> RobinMueller[m]: To be clear, I've never used the FRAM series.

17:44 <cr1901> From what I'm reading, I think the IVT remapping is explicitly for bootloaders. I think regardless, you will have to flash the IVT-in-flash anyway before you jump to either application A or B.

17:45 <cr1901> (Basically, I'm don't understand your explanation for why mapping the IVT to RAM for the bootloader is not an option)

18:04 <RobinMueller[m]> cr1901: I have to flash the IVT at the regular FRAM address? my plan was (and maybe that does not work?) that I will not touch the bootloader and the FRAM vectors anymore for a regular update process. in the TI bootloader, the bootloader and FRAM vectors are also read-only, but they use a proxy jump table (see p.8 of the docs I sent) to allow this. They suggested that redirection with SYSRIVECT would be an alternative option

18:04 <RobinMueller[m]> with enough RAM available.

18:05 <RobinMueller[m]> * RAM available. I understood this as: Instead of using a proxy-jump table, copy the respective application vectors to the top of RAM, enable the redirection bit, and jump to the app.

18:07 <RobinMueller[m]> * RAM available. I understood this as: Instead of using a proxy-jump table, copy the respective application vectors to the top of RAM, enable the redirection bit

21:43 <cr1901> RobinMueller[m]: Did you send a doc? I don't see any (I'm on the IRC side of the bridge)

21:47 <RobinMueller[m]> cr1901: I sent a link: https://www.ti.com/lit/an/slaa600e/slaa600e.pdf?ts=1747228511901

21:48 <cr1901> oooh that link

21:50 <cr1901> A proxy jump table, presumably with inline asm should work. But I'd have to build my own A/B/bootloader application to know for sure. And right now, I only have the bandwidth to make sure that msp430 isn't breaking in nightly. I also don't have FRAM hardware

21:50 <cr1901> RobinMueller[m]: Basically, what you want to do should be possible, but I don't know how to go about it without building my own and seeing what issues I run into myself.

21:55 <cr1901> Btw, is jannic on the matrix side of the bridge?

22:00 <jannic[m]> Yes, I am

22:02 <cr1901> jannic[m]: Since you did the rp2040 flashing code, is it okay if I pick your brain when I get around to doing a flasher for msp430 :P

22:02 <cr1901> (whenever that is...)

22:09 <jannic[m]> You are welcome to ask, but I fear most of the implementation is very rp2040 specific.

22:09 <RobinMueller[m]> cr1901: I already started implementing a bootloader, let's see if I can make it work :) I'll go with the re-direct route first though. In my case, I do not want a download slot / application slot distinction, but two active images where a preferred one can be selected via persistent parameter, and the redirect is more suitable for that I think. The proxy table example assumes just one active slot if I understand correctly

22:12 <cr1901> RobinMueller[m]: Ack, that works. I can also take a peek and then cross-ref with jannic[m] or other ppl who built a bootloader (i.e. "is it UB to copy a function to RAM and jump to it?")