crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
ka80 has joined #rust-embedded
starblue has joined #rust-embedded
ka80 has quit [Remote host closed the connection]
ka80 has joined #rust-embedded
creich_ has quit [Quit: Leaving]
creich has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
< (@thejpster:matrix.org)> Is there a threaded place for embedded rust chat? Things in matrix can scroll past and get missed, and Twitter … well, yeah.
<re_irc>
Is there a subreddit or forum or somewhere I should check out?
<re_irc>
(@thejpster@hachyderm.io if you want to follow more Neotron stuff)
IlPalazzo-ojiisa has quit [Remote host closed the connection]
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
< (@9names:matrix.org)> Maybe we should set up shop in the rust zulip?
dc740 has joined #rust-embedded
crabbedhaloablut has quit [Write error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
conplan1 has quit [Remote host closed the connection]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
causal has quit [Quit: WeeChat 3.7.1]
dc_740 has joined #rust-embedded
dc740 has quit [Ping timeout: 248 seconds]
<re_irc>
< (@adamgreig:matrix.org)> matrix does have threads! but they haven't been used much in this room
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> I've floated the idea of forums before, the response was kinda meh
<re_irc>
< (@firefrommoonlight:matrix.org)> Anyone have recs for a mat client? Element is bloated/slow
<re_irc>
< (@firefrommoonlight:matrix.org)> Likely some combo of Electron and the design philosophy of someone who would choose Electron
<re_irc>
< (@firefrommoonlight:matrix.org)> Btw, I don't know if anyone here has been watching the rust GUI space, but EGUI is outstanding
<re_irc>
< (@firefrommoonlight:matrix.org)> Flexible, great API and docs
<re_irc>
< (@firefrommoonlight:matrix.org)> Although it's immediate mode, which has a performance penalty if not using with a game or 3D
<re_irc>
<fsidel> you could use the webapp
<re_irc>
<fsidel> it's pretty fast on chromium based web browsers
ka80 has quit [Quit: Leaving]
crabbedhaloablut has quit [Write error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<|cos|> firefrommoonlight: I believe https://matrix.org/clients pretty much lists all usable clients. The list isn't longer than that you could try all which seems promising to your needs.
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<rjmp> Is there any ongoing work on IRQ-driven, buffered UART (or other byte-io interface) drivers? Something which can be easily pulled into a project with minimal boilerplate? One of the most common attributes of applications I work on is buffered IO, where calling write just fills a queue, and data is moved between HW and tx/rx queue in IRQs. So one thing I'm missing in Rust is that HALs don't generally support this (I...
<re_irc>
... haven't seen one yet, anyway). I would love to figure out how to do this with less boilerplate, and I'm curious if anyone else has thought about it?
<re_irc>
< (@adamgreig:matrix.org)> depending on the application, using DMA can be even better, and some HALs do support that in a few different ways
<re_irc>
< (@adamgreig:matrix.org)> (you could end up using dma to implement exactly the buffered situation you describe though, so...)
<re_irc>
<rjmp> : "Because the registers are memory-mapped, accesses to them are treated the same as memory accesses by Rust and LLVM, so we have to avoid UB the same way. If it were the case that any register access is UB we'd be in deep trouble!" Can I trouble you more to pursue this, because it seems like you have some specific meaning ascribed to UB that I don't understand. Like, I would think that register access are UB because the...
<re_irc>
... compiler cannot know how a write will affect later reads. For example, there are many cases in peripherals where writing one register will change the state of another. Also, there are registers which do not read back the last value written of course. Is this not an undefined behaviour?
<re_irc>
<rjmp> And of course there are peripherals which are also memory masters, and writing them can corrupt any real memory location so....
<re_irc>
< (@adamgreig:matrix.org)> UB here is a specific technical thing for Rust (and generally by extension LLVM), the full extent of "what's UB" and "how does MMIO interact with rust" are not fully defined though there's some more details here: https://doc.rust-lang.org/reference/behavior-considered-undefined.html
<re_irc>
< (@adamgreig:matrix.org)> but in general it's perfectly allowed to read back something you didn't write, because for example that's the same as memory shared between a process, or a memory-mapped file on disk, or memory the kernel of your OS has written to (like with io_uring or other kernel DMA)
<re_irc>
< (@adamgreig:matrix.org)> so it's not UB just because you can read back something different or the write might cause other system behaviour like changing a different register
<re_irc>
< (@adamgreig:matrix.org)> buttttt it certainly is playing very close to the line wrt what actually is UB, and in ways that are unfortunately still being hammered out
<re_irc>
< (@adamgreig:matrix.org)> for example, we say all the accesses to MMIO must be done through the "read_volatile()" and "write_volatile()" methods on ptrs, because otherwise llvm could often decide to optimise out the write entirely, or move it around in program order, in ways that break your program, and also because sometimes reading a register has a side effect, so you don't want llvm to insert extra reads or e.g. move a read...
<re_irc>
... outside of an if-block
<re_irc>
< (@adamgreig:matrix.org)> however it turns out any &-reference in Rust is(was) marked "dereferencable" to LLVM, which tells llvm it's allowed to dereference (read) it whenever it likes... so the svd2rust pattern of having a struct that it takes a &-reference to that points directly to the MMIO memory could allow LLVM to spuriously read registers that have side effects on read
<re_irc>
< (@adamgreig:matrix.org)> in practice this doesn't seem to have caused a problem yet, but is an argument for not constructing such registers and instead just using raw pointers directly (which is much easier to do today with the modern const fns and const generics than it was in 2017 when svd2rust was getting started)
<re_irc>
< (@adamgreig:matrix.org)> registers which control DMA peripherals are a whole other world of potential for problems of course, so the PAC shouldn't allow you to safely write a memory address to those (and typically won't)
<re_irc>
< (@adamgreig:matrix.org)> but again your program has to avoid UB - in the DMA case, by ensuring it cannot race any program access to memory and doesn't violate Rust's requirements around aliasing references
<re_irc>
< (@adamgreig:matrix.org)> the important thing here is that you have to avoid UB or your whole program is incorrect and may completely miscompile, it's not UB just to use MMIO registers or even DMA controllers, but you have to use them carefully to avoid UB
<re_irc>
< (@adamgreig:matrix.org)> and because "what's UB" isn't perfectly defined, and in many ways is harder to pin down than in C, that can be tricky
<re_irc>
<rjmp> So am I right to assume when you say multiple register references accesses are UB, you mean because of the "Data races" bullet point? And I guess this really only applies to some subset of registers bits that work like memory right? For example, having multiple references to a write register for a hardware FIFO isn't a data race?
<re_irc>
<rjmp> -accesses
<re_irc>
< (@adamgreig:matrix.org)> yea, you can't cause a data race if you only ever write
<re_irc>
< (@adamgreig:matrix.org)> well.... assuming your writes are atomic, i.e. your 32 bit write can't ever tear
<re_irc>
< (@adamgreig:matrix.org)> but that's usually the case
<re_irc>
< (@adamgreig:matrix.org)> I think on most platforms the MMIO words are cpu-word-sized or smaller so you hopefully don't expect to have to worry about it, heh
<re_irc>
<rjmp> Yeah, there are cases where you write the HIGH word register, then write the LOW word register, and the low word register triggers both to be consumed or similar. So I guess there are write only race conditions...but I'm not sure if this is strictly speaking a _data_ race?
<re_irc>
< (@adamgreig:matrix.org)> the usual and obvious UB threat is indeed that the main thread does a read-modify-write on some register, but an interrupt fires before the write and does its own r-m-w, and when the main thread writes it back it's ignored the change made by the interrupt
<re_irc>
< (@adamgreig:matrix.org)> rjmp: I think this could still be a "data race" if both threads are trying to write to high at the same time without synchronisation, sure
<re_irc>
< (@grantm11235:matrix.org)> : I don't think that's technically UB, just a bug. (of course a bug like that could cause UB if it happened to dma registers, etc)
<re_irc>
< (@adamgreig:matrix.org)> rust says that data races are definitely UB, so the question is just whether that's a data race, and usually unsynchronised access to the same piece of memory from two threads of execution counts as a data race, but
<re_irc>
< (@adamgreig:matrix.org)> when the platform ensures the write is atomic, is it a data race for one thread to read-modify, another thread to jump in and read-modify-write, and the first thread to then finish the write?
<re_irc>
< (@adamgreig:matrix.org)> it's not the same as two cores trying to write to the same address on the same clock cycle, for sure
<re_irc>
< (@grantm11235:matrix.org)> You can do the same thing in safe rust with atomics, so that type of race is definitely not UB
<re_irc>
<rjmp> This seems highly ....theoretical and subjective to me.
<re_irc>
< (@grantm11235:matrix.org)> (we are all assuming that volatile reads/writes of u32s are atomic, but that is technically not guaranteed)
<re_irc>
< (@adamgreig:matrix.org)> rjmp: yes, it's a pain to really nail anything down because it surprisingly quickly becomes surprisingly technical and also currently poorly defined, though people are working hard on this over at the unsafe-code-guidelines repo
<re_irc>
< (@grantm11235:matrix.org)> If they aren't atomic, we have some big problems on our hands
<re_irc>
<rjmp> It it's undefined, it also must be arbitrary, and so somewhat detached from my real problem of ensuring my program does what I want
<re_irc>
<rjmp> Like, I'm just not very motivated by meeting someone's definition of UB
<re_irc>
< (@adamgreig:matrix.org)> sure, that's fair, the problem is that Rust+LLVM cares about its own definition of UB, and if you violate it it's free to miscompile your code to do something surprising
<re_irc>
<rjmp> Unless meeting that definition is also achieving my desired function someway :)
<re_irc>
< (@adamgreig:matrix.org)> and if it doesn't miscompile it today, it might tomorrow
<re_irc>
<rjmp> Yeah so there's UB from the standpoint of "the behavior of the compiler isn't defined here", and that seems to me to be a very clear and valuable thing to achieve. But I dont know how to relate that to register accesses being UB.
<re_irc>
<rjmp> Because while I can certainly see how sharing access to registers can cause race conditions and my program not functioning correctly, I don't see how it leads to the UB in the "I can't say what the compiler will generate here" sense.
<re_irc>
<rjmp> Especially if they are volatile so writes can't be elided?
<re_irc>
<rjmp> (or reads, for that matter)
<re_irc>
< (@dirbaio:matrix.org)> rjmp: embassy's HALs have exactly this! Called "BufferedUart". For nrf, stm32, rp2040
<re_irc>
<rjmp> : Thank you for all the discussion on this. I hope I am not coming off too much as the new outsider coming in to complain about the hard work of others! I'm just trying to work through some of the practical frustrations I've run into of re-tooling myself from C++ to Rust :)
<re_irc>
< (@adamgreig:matrix.org)> rjmp: in practice I tend to agree and I don't think we've seen many/any practical problems as a consequence yet, though I think we would get an awful lot of people having interrupts stomp on their mmio if it wasn't for using rust's ownership system to model exclusive access to peripherals
<re_irc>
<rjmp> : Oh cool I will have to look into this!
<re_irc>
< (@adamgreig:matrix.org)> not at all, it's a totally fair thing to complain about, and a lot of your specific objections are really about a particular choice in svd2rust and not so much Rust itself, I think
<re_irc>
<rjmp> Yeah for sure it's svd2rust. But I like leveraging all those published PACs :)
<re_irc>
< (@adamgreig:matrix.org)> "how to best model mmio for no-std bare-metal embedded" is definitely something that has evolved over the years
<re_irc>
< (@dirbaio:matrix.org)> I think this has been discussed before, so I might be beating a dead horse, but
<re_irc>
< (@dirbaio:matrix.org)> I don't think unsynchronized MMIO is UB
<re_irc>
< (@dirbaio:matrix.org)> like
<re_irc>
< (@dirbaio:matrix.org)> it's true volatile load/store _in general_ is not enough to avoid data race UB
<re_irc>
<rjmp> : I am not so sure. There aren't a ton of cases where IRQ access conflict with main thread access IME? I regularly unsafely steal registers in IRQs anyway!
<re_irc>
< (@dirbaio:matrix.org)> but volatile load/store of u8/u16/u32 _is_ guaranteed to compile to a single LDRx/STRx instruction
<re_irc>
<rjmp> But I also have a pretty good understanding of what is/isn't functionally safe to do. I mean I used to do it with C and made it work there...
<re_irc>
< (@adamgreig:matrix.org)> if only we had "atomic volatile"
<re_irc>
< (@dirbaio:matrix.org)> and the hardware guarantees that's atomic
<re_irc>
< (@adamgreig:matrix.org)> then it really would be guaranteed
<re_irc>
< (@grantm11235:matrix.org)> : I don't think that is true, is it?
<re_irc>
< (@dirbaio:matrix.org)> : it has to be guaranteed, otherwise the PACs are broken
<re_irc>
< (@adamgreig:matrix.org)> I can't remember when we last discussed it but I think you're probably right, or at least the concept that the data race comes from an interrupt r-m-w isn't correct and the race is from the unsynchronised write alone
<re_irc>
< (@grantm11235:matrix.org)> Where is it guaranteed?
<re_irc>
< (@adamgreig:matrix.org)> but without atomic volatiles I don't think it is guaranteed, it's just the current behaviour and seems unlikely to ever change
<re_irc>
< (@dirbaio:matrix.org)> many peripherals misbehave if you do reads/writes of the wrong width
<re_irc>
< (@grantm11235:matrix.org)> : I agree with this btw, which is why I think that PACs are technically broken lol
<re_irc>
< (@dirbaio:matrix.org)> like, if a u32 volatile store compiles to 2x STRH instead of 1x STR
<re_irc>
< (@dirbaio:matrix.org)> the peripheral might do wrong things
<re_irc>
< (@adamgreig:matrix.org)> especially around changing gpio modes where the register is shared by maybe 32 distinct and unrelated processes that all want to operate one gpio pin, or something like that... (a sufficiently good mcu would have separate registers for each pin, a sufficiently good HAL will use platform atomics to only modify a single bit, but...)
<re_irc>
< (@adamgreig:matrix.org)> I guess PACs could do inline asm for all mmio and thus guarantee volatile atomic semantics "lol"
<re_irc>
< (@adamgreig:matrix.org)> gotta run for a bit, bbl
<re_irc>
< (@grantm11235:matrix.org)> : Hmm, that's not a terrible idea...
<re_irc>
< (@adamgreig:matrix.org)> It's pretty annoying but I guess since inline asm is stable now it wouldn't actually be awful
<re_irc>
< (@adamgreig:matrix.org)> Kinda silly since write_volatile almost certainly will compile to same thing and have smaller clobbers
<re_irc>
< (@adamgreig:matrix.org)> The inline asm would perhaps disrupt some optimisations
<re_irc>
< (@adamgreig:matrix.org)> (you'd have a whole-memory clobber at least, right?)
<re_irc>
<rjmp> : I'd argue this is a problem for the HAL. PAC should just make the registers available. And HALs can require a critical section as needed where they can't ensure atomic r-m-w (like changing GPIO modes)
<re_irc>
< (@grantm11235:matrix.org)> Could you mark it as "nomem" as long as you only use it on mimo registers and never on "normal" memory?
<re_irc>
< (@adamgreig:matrix.org)> I don't think that would fly, it still accesses memory
<re_irc>
< (@grantm11235:matrix.org)> Actually, I think the memory clobbering could be useful and necessary for dma stuff
<re_irc>
< (@adamgreig:matrix.org)> The problem of how to synchronise a bunch of writes to always happen before triggering DMA that is configured by or reads them is also an ongoing discussion
<re_irc>
< (@dirbaio:matrix.org)> in general it's nice that normal and MMIO mem can stay unsynchronized, allows for better optimizations
<re_irc>
< (@adamgreig:matrix.org)> It turns out a compiler fence probably isn't enough because they probably only synchronise atomic accesses?
<re_irc>
< (@grantm11235:matrix.org)> Which would solve the current problem where we use compiler fences that aren't actually specified to do anything
<re_irc>
< (@dirbaio:matrix.org)> so you only explicitly sync it when you need to
<re_irc>
< (@adamgreig:matrix.org)> Yea
<re_irc>
< (@adamgreig:matrix.org)> I feel like using volatile for now in the knowledge it's almost certainly right for u32 and smaller but in the future we'd ideally move to some sort of volatile atomic or speciality mmio type is probably the best option?
<re_irc>
< (@dirbaio:matrix.org)> : lalalala I cant't hear you 🙉
<re_irc>
< (@dirbaio:matrix.org)> too cursed
<re_irc>
< (@dirbaio:matrix.org)> 🤣
<re_irc>
< (@dirbaio:matrix.org)> I'll keep pretending a volatile write compiles to a single STR, and that fences do fence :D
<re_irc>
< (@grantm11235:matrix.org)> If you give a pointer to inline asm, can you specify that it only accesses that pointer, and that it doesn't clobber any other memory?
<re_irc>
< (@adamgreig:matrix.org)> I don't think so, the default is all accessible memory might be accessed unless you pass nomem to say no memory is accessed, but then maybe it gets complicated with the pointer provenance and escape analysis stuff ("accessible"?)
<re_irc>
< (@grantm11235:matrix.org)> : I still think this might work, as long as nothing else in the program treats the location as "memory" (no reads/writes, even even if they are volatile)
<re_irc>
< (@grantm11235:matrix.org)> I still think this might work, as long as nothing else in the program treats the location as "memory" (no reads/writes, even if they are volatile)
<re_irc>
< (@grantm11235:matrix.org)> The reference says
<re_irc>
> The set of memory locations that assembly code is allowed to read and write are the same as those allowed for an FFI function.
<re_irc>
< (@grantm11235:matrix.org)> So maybe it's not a full clobber?
<re_irc>
< (@adamgreig:matrix.org)> And just depends on what you pass in? Yea maybe 🤔
<re_irc>
< (@dirbaio:matrix.org)> that sounds like it might reorder two mmio accesses to separate regs
<re_irc>
< (@dirbaio:matrix.org)> but we do do want to prevent that reordering, only between mmio regs, not between mmio and normal RAM
<re_irc>
< (@adamgreig:matrix.org)> I don't think it will reorder asm calls?
<re_irc>
< (@dirbaio:matrix.org)> if you tell it they only touch disjoint mem, can't see why it wouldnt
<re_irc>
< (@dirbaio:matrix.org)> or is there some "asm is never reordered" guarantee?
<re_irc>
< (@grantm11235:matrix.org)> : Is that just another "fences don't do what you think they do"?
<re_irc>
< (@dirbaio:matrix.org)> that code is wrong isn't it
<re_irc>
< (@dirbaio:matrix.org)> it should be "out("r0") r0,", not "out("r0") _,"
<re_irc>
< (@grantm11235:matrix.org)> : I think there is, at least implicitly. For example, inside your asm you could call a function that does atomic stuff that can't be reordered, also the compiler doesn't look inside your asm to find out whether that is the case or not. Therefor the compiler can't assume it is allowed to reorder any inline asm
<re_irc>
< (@grantm11235:matrix.org)> (That is a half-remembered explanation that I think I saw in one of the github issues)
<re_irc>
< (@dirbaio:matrix.org)> perhaps you're supposed to set some clobber in that case (?)
<re_irc>
< (@dirbaio:matrix.org)> ah or perhaps it does that by default
<re_irc>
< (@dirbaio:matrix.org)> and you opt out by setting nomem / pure / readonly
<re_irc>
< (@adamgreig:matrix.org)> I think the asm can be ordered around other code and other code inserted between successive asm calls but I wouldn't think it could relatively reorder asm calls... but also can't find this promised anywhere
<re_irc>
< (@jannic:matrix.org)> : Eg on rp2040 that would break all register writes: iirc all writes are treated as 32 bit writes. If the CPU does issue a 16 bit write to an mmio register, those 16 bits will be written to both the upper and the lower half of the register.
<re_irc>
< (@dirbaio:matrix.org)> stm32 too I believe, not sure about nrf
<re_irc>
< (@dirbaio:matrix.org)> but yea I wouldn't be surprised most chips break.. handling narrow reg writes is a waste of silicon
<re_irc>
< (@jamesmunns:beeper.com)> > iirc all writes are treated as 32 bit writes
<re_irc>
I don't _think_ that's true?
<re_irc>
< (@jamesmunns:beeper.com)> There's definitely stm32g0 parts that have different behavior if you do an 8-bit or 16-bit write to registers
<re_irc>
< (@jamesmunns:beeper.com)> like, an 8-bit write will push one byte into a fifo, and a 16-bit write will push two bytes into a fifo
<re_irc>
< (@jamesmunns:beeper.com)> (STRB instead of STRH)
<re_irc>
< (@grantm11235:matrix.org)> Yeah, I think I have seen FIFOs like that too
<re_irc>
< (@dirbaio:matrix.org)> yea
<re_irc>
< (@dirbaio:matrix.org)> depends on the bus I think
<re_irc>
< (@dirbaio:matrix.org)> but for registers where you're _not_ supposed to do narrow writes, I bet the silicon has no gates to handle it
<re_irc>
< (@jamesmunns:beeper.com)> That I could probably see!
<re_irc>
< (@dirbaio:matrix.org)> and writes garbage or ignores it or whatever
<re_irc>
< (@dirbaio:matrix.org)> so
<re_irc>
< (@dirbaio:matrix.org)> if "u32" volatile write is _not_ guaranteed to compile to a single STR, then our PACs are broken! :D
<re_irc>
< (@jamesmunns:beeper.com)> I dunno about guaranteed, but at least for cortex-m, STR must be to an aligned address
<re_irc>
< (@jamesmunns:beeper.com)> I guess you could codegen two STRH instead, but like, that would be bad
<re_irc>
<rjmp> I can't think of a reason to take a 32bit aligned write and break it up
<re_irc>
< (@dirbaio:matrix.org)> > Rust does not currently have a rigorously and formally defined memory model, so the precise semantics of what “volatile” means here is subject to change over time. That being said, the semantics will almost always end up pretty similar to [C11’s definition of volatile.] (link to giant PDF)
<re_irc>
< (@dirbaio:matrix.org)> 😵
<re_irc>
< (@grantm11235:matrix.org)> : I think this is one of those things where it isn't guaranteed, but it works in practice (for now at least) because what else is the compiler going to do?
<re_irc>
< (@jannic:matrix.org)> : Found it in the datasheet: " Memory-mapped IO registers on RP2040 ignore the width of bus read/write accesses. They treat all writes as though
<re_irc>
they were 32 bits in size. This means software can not use byte or halfword writes to modify part of an IO register: any
<re_irc>
write to an address where the 30 address MSBs match the register address will affect the contents of the entire
<re_irc>
register."
<re_irc>
< (@jamesmunns:beeper.com)> Ah! I missed that you were speaking _specifically_ about the rp2040, rather than in general
<re_irc>
< (@jamesmunns:beeper.com)> Thanks for explaining :)
<re_irc>
< (@dirbaio:matrix.org)> any idea why would a blob would crash _only_ when doing a defmt-print in one particular place? 🤔
<re_irc>
< (@dirbaio:matrix.org)> (Nordic's new BLE stack blob)
<re_irc>
< (@dirbaio:matrix.org)> it's not timing, I can replace it with a super long "cortex_m::asm::delay" and it doesn't crash
<re_irc>
< (@dirbaio:matrix.org)> and it's not disabling irqs, i've replaced critical-section impl with a noop and it still crashes :D
<re_irc>
< (@jamesmunns:beeper.com)> does the defmt code touch any of the debug core settings or whatever there?
<re_irc>
< (@dirbaio:matrix.org)> no... it's just RTT
<re_irc>
< (@dirbaio:matrix.org)> I mean, it works with defmt just fine in general
<re_irc>
< (@jamesmunns:beeper.com)> I just know nordic code gets ANGERY when it thinks you're using the debugger
<re_irc>
< (@dirbaio:matrix.org)> only if I print something in one particular place
<re_irc>
< (@dirbaio:matrix.org)> and only if I print a big array (256 bytes)
<re_irc>
< (@dirbaio:matrix.org)> then it gets angery
<re_irc>
< (@jamesmunns:beeper.com)> what is the actual crash reason?
<re_irc>
< (@jamesmunns:beeper.com)> like do you get a hardfault or something?
<re_irc>
< (@dirbaio:matrix.org)> "SDC assertion failed at file 62 line 2106"
<re_irc>
< (@dirbaio:matrix.org)> it has a callback for assertion failed
<re_irc>
< (@dirbaio:matrix.org)> but they replaced all the filenames with numbers :D
<re_irc>
< (@jamesmunns:beeper.com)> ghidra to figure out what has that string? :p
<re_irc>
< (@dirbaio:matrix.org)> that string is mine
<re_irc>
let file = core::ffi::CStr::from_ptr(file as _).to_str().unwrap();
<re_irc>
panic!("SDC assertion failed at file {} line {}", file, line);
<re_irc>
}
<re_irc>
< (@dirbaio:matrix.org)> 🤷
<re_irc>
< (@jamesmunns:beeper.com)> oh
<re_irc>
< (@dirbaio:matrix.org)> all asserts go there
<re_irc>
< (@dirbaio:matrix.org)> the old softdevice had an assert callback like this, but it gave you a PC value
<re_irc>
< (@jannic:matrix.org)> Memory bus contention? What if you just do some memcpy at that place?
<re_irc>
< (@dirbaio:matrix.org)> the new one gives you file:line but they replaced all the filenames with numbers
<re_irc>
< (@jamesmunns:beeper.com)> backtace in the assert handler?
<re_irc>
< (@jamesmunns:beeper.com)> * backtrace
<re_irc>
< (@dirbaio:matrix.org)> like, the "file" C string is the string "62"
<re_irc>
< (@dirbaio:matrix.org)> symbols in the .a are all random hex strings
<re_irc>
< (@dirbaio:matrix.org)> gotta love blobs
<re_irc>
< (@dirbaio:matrix.org)> oh well
<re_irc>
< (@jamesmunns:beeper.com)> guess they could GOTO instead of call, maybe they got lazy
<re_irc>
< (@dirbaio:matrix.org)> it's so odd
<re_irc>
< (@dirbaio:matrix.org)> like, maybe the SWD bus has priority over the core... and just reading 256 bytes makes the CPU stall long enough that it crashes? :S
<re_irc>
< (@dirbaio:matrix.org)> I did big prints like that all the time with the old softdevice though, and it was always fine
<re_irc>
< (@dirbaio:matrix.org)> also when I ctrl+c I get this
<re_irc>
> (HOST) WARN program has used at least 1048772.71/184.68 KiB (567899.4%) of stack space
<re_irc>
< (@dirbaio:matrix.org)> wat =D
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, my three wild guesses in no order:
<re_irc>
- It's noticing the debug bus is active somehow (does the debug core have a flag for "host is doing something to me"?), and as attempting to prevent reverse engineering
<re_irc>
- It's a timing thing - you might try moving the defmt block to another memory region
<re_irc>
- The blob is doing something evil, and not restoring regs properly, causing defmt to go crazy
<re_irc>
why they'd do that? :C
<re_irc>
< (@dirbaio:matrix.org)> > attempting to prevent reverse engineering
<re_irc>
< (@dirbaio:matrix.org)> they do support debugging and RTT under Zephyr just fine
<re_irc>
< (@jamesmunns:beeper.com)> Just wild guesses :p
<re_irc>
< (@dirbaio:matrix.org)> expanded the defmt macro, removed the acquire/release calls, no longer crashes
<re_irc>
< (@dirbaio:matrix.org)> but wtf, that just does critical-section acquire/release which I have nop'd out
<re_irc>
< (@grantm11235:matrix.org)> Maybe it's a cursed caching problem? Did you try "cargo clean"?
<re_irc>
< (@dirbaio:matrix.org)> yeah, it's just broken
<re_irc>
< (@dirbaio:matrix.org)> oh I was using "defmt-rtt 0.3" which uses "critical-section 0.2"instead of"1.0` 🤦♂️
<re_irc>
< (@dirbaio:matrix.org)> * 0.2" instead of "1.0"
<re_irc>
< (@dirbaio:matrix.org)> it was disabling irqs
<re_irc>
< (@dirbaio:matrix.org)> goddamnit
conplan has joined #rust-embedded
<re_irc>
< (@dirbaio:matrix.org)> should we yank "critical-section 0.2"?
<re_irc>
< (@dirbaio:matrix.org)> * 0.2.x"?
<re_irc>
< (@dirbaio:matrix.org)> yep the crash is gone
<re_irc>
< (@jamesmunns:beeper.com)> lol
<re_irc>
< (@dirbaio:matrix.org)> I had supplied a custom impl for 1.0, but 0.2 was doing the "disable all irqs" by default
<re_irc>
< (@dirbaio:matrix.org)> * still doing the "disable all irqs"
<re_irc>
< (@dirbaio:matrix.org)> so glad we got rid of the default in 1.0
<re_irc>
< (@dirbaio:matrix.org)> it was the right call
<re_irc>
< (@dirbaio:matrix.org)> but now we have to kill 0.2
<re_irc>
< (@dirbaio:matrix.org)> to completely eliminate the footgun...
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> any magic dance I need to perform for macos Ventura to recognize usb uarts?
<re_irc>
< (@dirbaio:matrix.org)> yay I get raw bluetooth LL packets
<re_irc>
< (@dirbaio:matrix.org)> now just gotta draw the rest of the owl (write a BLE stack 😰)
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> I've found something about USB restrictions in the release notes, but the system settings mentioned there don't exist on my machine
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> ah, they maybe just changed the naming conventions
<re_irc>
< (@dirbaio:matrix.org)> Is this the right way to use BASEPRI?
<re_irc>
unsafe fn acquire() -> u8 {
<re_irc>
unsafe impl critical_section::Impl for MyCriticalSection {
<re_irc>
let old = cortex_m::register::basepri::read();
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> hmm, it does seem something about usb device enumeration has changed, the stm32f1 hal usb uart example crashes
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> I'm observing unusual tty device names in /dev as well, they do get created when the firmware starts, but I can't communicate with the device it seems
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> they seem to be "ttys0xx" with "xx" being a sequential number increased on every firmware startup
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> searching for vid/pid in the system logs yields
<re_irc>
default22:51:49.260622+0100kernel154296.830944 AppleUSB20HubPort@01131100: AppleUSBHostPort::enumerateDeviceComplete_block_invoke: enumerated 0x16c0/27dd/0010 (PB) at 12 Mbps
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> I think that was the one time I conntected the f411 instead of the f103, let's see if it shows up again
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> huh? just trying on my other mac which is still on Monterey and getting the same problem, great
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> it's literally hal example code¿ what's going on
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> ok, the espc3 does show up so it's not strictly a permissions problem, maybe macos just doesn't like the example vid/pid anymore. Let's try impersonating the esp.
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> it gets funnier, now the esp uart device doesn't show up anymore either.
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> definitely some fishy business
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> ok so the older esp board which uses a dedicated cp2102n as uart seems stable.
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> eeh, so does the new esp board, I just connected the wrong mcu lol.
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> back to impersonating!
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> but I never had to modify f1xx hal code for this one here either, so I don't think it's the pins
<re_irc>
< (@dirbaio:matrix.org)> it's odd because yours doesn't even begin to enumerate
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> right? super strange
<re_irc>
< (@dirbaio:matrix.org)> and if you were seeing the serial port before it was at least enumerating somewhat
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> to be clear, I've not seen any rust usb serial mcu working on the new Ventura machine, just the espressif c3 ones did show up
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> I'll test the embassy mcu on the old machine now
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> doesn't show up either, so it's not a ventura only problem, maybe a security update that also got backported
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> (haven't done usb-serial stuff in the last 2 or 3 months)
<re_irc>
< (@dirbaio:matrix.org)> could it be the probe?
<re_irc>
< (@dirbaio:matrix.org)> try: flash, unplug everything, plug in only the target and not the probe
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> hm, unlikely - I can see RTT logs just fine; I've also connected the mcu without probe attached, no serial there either
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> yeah, did "only target" already
<re_irc>
< (@dirbaio:matrix.org)> :S
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> no luck
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> I keep stumbling on this (https://direct.ilink.de/en/usb.html) when trying to google for the problem
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> none of the points on the page really apply, but I have the feeling _something_ has recently been changed
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> (you don't need drivers for CDC serial devices)
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> gonna restart and see if I get some interesting security approval UI popups, maybe it's a state issue
dc_740 has quit [Remote host closed the connection]
<re_irc>
<the tab openoor (spookyvision@{github,cohost})> (side note, I'm a dummy, the new machine isn't on Ventura either. Doesn't change my suspicion that it's an OS related problem)
<re_irc>
< (@firefrommoonlight:matrix.org)> fsidel: Thx - will give it a shot