<PedroFerreira[m]>
Hm... When a program panics, how does `panic!` find out in which file it originated (location)? Does the compiler keep the file names in .rodata or something?
d3zd3z[m] has joined #rust-embedded
<d3zd3z[m]>
Any embedded Rustacians going to Rustconf this year.
dygear[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
<PedroFerreira[m]> "Hm... When a program panics, how..." <- Yep, check out the PanicInfo struct
<JamesMunns[m]>
JamesMunns[m]: Or the file!() Or line!() Macros
Kat[m] has quit [Quit: Idle timeout reached: 172800s]
KevinClark[m] has quit [Quit: Idle timeout reached: 172800s]
TeXitoi[m] has quit [Quit: Idle timeout reached: 172800s]
korken89[m] has joined #rust-embedded
<korken89[m]>
I'm looking at writing a "NOR flash mock" for testing, where the normal read/write parts of it are done. However I want to add tests to see that the storage library correctly handles flash corruption when one has exhausted the number of write/erase cycles.
<korken89[m]>
So I'm thinking about add above some number of writes random bit flips are introduced and maybe even general random failures from the flash controller saying a write failed. Is there something else anyone here would add to get "a good model of a flash"?
<korken89[m]>
My googling points me to the things I'm planning to add already.
<ryan-summers[m]>
<korken89[m]> "I'm looking at writing a "NOR..." <- > <@korken89:matrix.org> I'm looking at writing a "NOR flash mock" for testing, where the normal read/write parts of it are done. However I want to add tests to see that the storage library correctly handles flash corruption when one has exhausted the... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/hUuPJwNrcIEgJOMSabKycdWd>)
<ryan-summers[m]>
It handles multiple write checks and such too to handle only setting bits and whatnot. Might be a nice base
<korken89[m]>
ryan-summers[m]: I have given it a look, but it looks like it only handles random power-off events and none of the longevity errors.
<ryan-summers[m]>
Hmm gotcha, yeah don't think it tracks how many writes in a single area you've done. I think the mechanism of flash wear out might be partial or marginal cell writes? Not sure, that's an interesting question
<korken89[m]>
It felt like the final part for a good "fuzz test" :)
<korken89[m]>
I was playing with an old flash writer I had made long ago that used CRC8s for corruption. Turns out CRC8 is a bad idea because random bit flips can still generate correct CRCs xD
<korken89[m]>
* for corruption detection. Turns
<korken89[m]>
This is what caused me to want to try to add corruption to my flash testing of the current project
<korken89[m]>
But of-course try to add a good model for corruptions then :)
<ryan-summers[m]>
Yeah because the failure mode _might_ be a marginal write, where the cell has differing values every time you read it
BenoitLIETAER[m] has quit [Quit: Idle timeout reached: 172800s]
<dngrs[m]>
Just put your test harness in high earth orbit, should get enough bit flips that way
diondokter[m] has joined #rust-embedded
<diondokter[m]>
<korken89[m]> "I have given it a look, but it..." <- Ooohh, that could be cool to add!
<diondokter[m]>
Maybe I should also make that mock into its own crate... idk
<diondokter[m]>
<korken89[m]> "I was playing with an old..." <- Yeah, I even went from 16-bit to 32-bit because the fuzzer was able to find 16-bit collisions 🙈
<korken89[m]>
The mock you have in there is really good, I'd love to build on-top of it
<diondokter[m]>
The code iteself is a mess though haha. "It's only a mock, let's just bolt on another feature, no one will care"
<korken89[m]>
Haha that's how all great things start 🚀
<PedroFerreira[m]>
<JamesMunns[m]> "Or the file!() Or line!() Macros" <- Thanks. But those are compiler built-ins, right?
mkj[m] has joined #rust-embedded
<mkj[m]>
Pedro Ferreira: yep, built-ins. do you want to customise the location? would `#[track_caller]` help?
<PedroFerreira[m]>
No, I don't want to. It's just that I am using my own panic handler in a program which I launch on the second core, loaded from the ROM, and somehow when there is a panic, the location info is corrupted.
<PedroFerreira[m]>
I think I am loading .rodata to the right place in RAM, as e.g. static strs seem to work fine
<PedroFerreira[m]>
So, I was trying to figure out what to look for
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
Vicente[m] has quit [Quit: Idle timeout reached: 172800s]
pacarito[m] has quit [Quit: Idle timeout reached: 172800s]
lehmrob has joined #rust-embedded
geky[m] has joined #rust-embedded
<geky[m]>
@korkThe way bit errors are usually modeled is fewer bit errors is more common than more bit errors. If you test with single bit-errors, two bit-errors, etc, you can prove some interesting properties in addition to general fuzz testing. A "good" CRC can detect all 1,2,3,etc bit errors up to a certain size for example.
<geky[m]>
* @korken89:matrix.org @diondokter:matrix.org The way bit errors are usually modeled is fewer bit errors is more common than more bit errors. If you test with single bit-errors, two bit-errors, etc, you can prove some interesting properties in addition to general fuzz testing. A "good" CRC can detect all 1,2,3,etc bit errors up to a certain size for example.
<geky[m]>
<ryan-summers[m]> "Yeah because the failure mode..." <- I've hear this called metastability before and it's particularly tricky. Depending on the flash it can also be caused by powerloss during writes. I think you basically need ECC correcting reads to keep a system stable if this happens...
<geky[m]>
<diondokter[m]> "Yeah, I even went from 16-bit to..." <- On NAND I want to go up to 64-bit CRCs, but as far as I can tell there are no known "good" 64-bit CRCs (even-parity + product of a 64-bit irreducible) :/
andar1an[m] has joined #rust-embedded
<andar1an[m]>
Are there any relationships between embedded rust wg, and embedded wasm work, projects, or groups?
<andar1an[m]>
Seems embassy provides a time driver for wasm. Dk what that means yet related to flow for rust+wasm on embedded, but seems worth digging in
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
that's for running embassy on browser wasm
<andar1an[m]>
I guess for wasm runtime, could one just use embassy executor to start a wasm runtime?
<andar1an[m]>
Nvm, I didn't realize embassy was select on hardware. My bad
lehmrob has quit [Remote host closed the connection]
Dherse[m] has joined #rust-embedded
<Dherse[m]>
Hello, I've hit a strange issue: I am using heapless to allocate stuff in my external SRAM, when MPU is off, I get no errors, but when MPU is on, I get a HardFault caused by an unaligned access in heapless at hole.rs:69 (nice). Has anybody encountered such issues previously, and what fixed it for you? (the base address I am giving heapless is aligned)