<barafael[m]>
Can you say which dependency it is? Have you tried up-/downgrading other dependencies? It could be unrelated
<MathiasKoch[m]>
Its a wifi driver library, and judging from the diff of the commit it seems super unrelated indeed!
<barafael[m]>
Have you twiddled with optimization flags already? Just guessing... It sounds like a fascinating bug.
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 272 seconds]
richardeoin has quit [Ping timeout: 252 seconds]
zachariasfrings[ has quit [Quit: Idle timeout reached: 172800s]
wassasin[m] has joined #rust-embedded
<wassasin[m]>
@MathiasKoch: the path of the dependency on your filesystem is a factor in what symbol names are generated, which can determine ordering in various stages of the compile process. Seems like you have some memory corruption somewhere and depending on layout and how the codegen happens to run its course the memory corruption breaks something relevant or not
<MathiasKoch[m]>
> the path of the dependency on your filesystem is a factor in what symbol names are generated
<MathiasKoch[m]>
Does this matter on a stripped bin version
<MathiasKoch[m]>
* bin version?, * I get it in the ELF with debug info
<wassasin[m]>
LLVM still uses mangled symbol names, regardless of whether you strip it or not generate debug symbols
<MathiasKoch[m]>
Ahh, fair enough. Guess that explains the binary size diff then..
<wassasin[m]>
I am investigating something not completely similar right at this moment
<wassasin[m]>
Yeah, the compiler might decide to inline or not depending on how the ordering pans out
<wassasin[m]>
It's not at all deterministic
<wassasin[m]>
It's a tricky problem because as soon as you add something to your code, the compiler might take some other path and not generate assembly that triggers the problem
<wassasin[m]>
So you have the same dependency, exact same dependency code, but one included via git= rev= and one included with path=, right? I would suggest looking into the generated assembly and/or LLVM to see what has changed to infer what kind of corruption is going on
<wassasin[m]>
Diffing LLVM is a pain though, as I've found out the past week
<MathiasKoch[m]>
Damn.. Firmware size in 500kb :/
<MathiasKoch[m]>
* 500kb :/ ASM/LLVM diffing is going to terrible
<wassasin[m]>
I am going on vacation for a week otherwise I could help you do it
badyjoke[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]1>
The other note is that there could be unrelated changes that are causing opt differences (maybe make sure you aren't using an older compiler version with the outlining miscompilation if you use opt-level=z), and sometimes using path deps also increases the size of panic paths as well.
<JamesMunns[m]1>
It could also be unrelated undefined behavior, sometimes totally unrelated changes will impact whether UB will be misoptimized or not.
<JamesMunns[m]1>
My only other thought: you've confirmed that the larger code didn't leak into the flash region that you are erasing, and this is causing problems as you end up erasing some load-bearing code?
<MathiasKoch[m]>
> My only other thought: you've confirmed that the larger code didn't leak into the flash region that you are erasing, and this is causing problems as you end up erasing some load-bearing code?
<JamesMunns[m]1>
I'm not sure what you are doing in the flash update process, but the other usual thing to chase for "bizzarely doesn't work when it should" is a stack overflow, it might be useful to enable flip-link if you can (and aren't already)
<JamesMunns[m]1>
Then maybe check the reference manual (and errata!) for your chip to ensure that the way you are writing and erasing flash is consistent with what they recommend, and see if there are any bugs in the flash procedure, or if the HAL has correct metadata for things like sector sizes.
<MathiasKoch[m]>
Thanks for the pointers!
<MathiasKoch[m]>
> Particularly note if you cross important flash addresses like sectors in the flash.
<MathiasKoch[m]>
We have a 1MB dual bank flash setup with uniform 2K pages, and the page we are erasing is always page 8 (page 0-8) contains a bootloader. So our `FIRMWARE` points to page 9, and we have a firmware header with some image flags before that, so there shouldn't be any crossings of sections etc, and it is page aligned and sized
<JamesMunns[m]1>
JamesMunns[m]1: (re: stack overflow, it's possible that you were JUST at some limit and the different optimization outcome pushed you over, OR that you were already corrupting statics, and now the statics have just be re-organized and you corrupted a more immediately important value)
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
<MathiasKoch[m]>
And we tried drastically reducing our statics for debugging purposes, with the same result :( So we kinda ruled out stack overflow, unless its a very big one
<JamesMunns[m]1>
Maybe check what those values are with nm to make sure they are working the way you expect, and maybe write a small on-target test that manually poking that range correctly causes an access violation (read/write)
<MathiasKoch[m]>
Obviously the MPU wouldnt catch a very big SO either :/
<JamesMunns[m]1>
yep, if you are copying a chunk of the flash to ram, maybe make sure your guard page is a little larger than the copy you are making? e.g. if you copy 2K to RAM, make sure you have a 4K guard page
<JamesMunns[m]1>
otherwise if you have a 1K guard page, but then try to copy 2K to a stack that overflows, you could jump over the guard entirely
<JamesMunns[m]1>
might be worth flip link still if you can swing it though, that gives you a way larger "guard page" (at LEAST 1MiB, generally much much larger)
<JamesMunns[m]1>
Otherwise, if you can single-step through the RMW of the flash, that might be illuminating, though I know some chips are hard to step through when doing flash ops
<JamesMunns[m]1>
(and keep an eye on the PC and SP while doing it)
dreamcat4 has joined #rust-embedded
<MathiasKoch[m]>
Yeah, we tried that but the debugger kicks us just before the issue occurs (likely due to flash operations)
<JamesMunns[m]1>
yep, happens. if you can use something like a UART, ITM, or GPIO debugging (with a logic analyzer or even LEDs) to bisect where it is halting, that might be worth doing too.
<JamesMunns[m]1>
this won't help much if it is UB, but might give you an idea of where to start digging in the asm or code.
AtleoS has quit [Ping timeout: 268 seconds]
AtleoS has joined #rust-embedded
Mathias[m] has quit [Quit: Idle timeout reached: 172800s]
zachariasfrings[ has joined #rust-embedded
<zachariasfrings[>
Heyho, are there any implemented drivers for 1602 LCD Displays?
<zachariasfrings[>
I am currently onfly finding 1306 LCD drivers
<zachariasfrings[>
* Heyho, are there any implemented drivers for 1602 LCD Displays?
<zachariasfrings[>
I am currently onfly finding 1306 LCD drivers.
<zachariasfrings[>
Ord could i skip the driver and talk to my display directly via i2c?
<M9names[m]>
assuming you mean a 16 column, 2 row display? maybe link to an image of what you're talking about
<M9names[m]>
* 2 row character display? maybe
<zachariasfrings[>
Sorry yes. 16 columns 2 rows it is. I am also using the rp-pico hal. Does ist already implement this driver or do I need to add it to my project?
<zachariasfrings[>
I just started using rust for embedded stuff so this is all quite new to me
<PinballWIzard[m]>
Hi James Munns still here to bother you with my questions on postcard with UART, i am studying V 4.1 and V 4.2 as you pointed out, looks more clear now I can see the flow better and I am trying to import the code in my application. Just one probably stupid question, both example on firmware crate use a configure_usb function like here:
<PinballWIzard[m]>
my silly question is...can I simply use UART peripheral to retrieve messages ( i am using a Nordic Nrf52 chip ). Thanks for your support boss!
<PinballWIzard[m]>
<JamesMunns[m]1> "> <@9names:matrix.org> the hal..." <- Great will dig in this, so if I understood the big picture i can remove from firmware crate setup of USB and using v 0.4.1 i have to modify probably something inside this fn:
<PinballWIzard[m]>
<JamesMunns[m]1> "> <@pinballwizard:matrix.org..." <- > <@jamesmunns:beeper.com> Yes, and I know I am repeating myself, but if you use Dispatch/CobsDispatch like v0.4.1, you *can't* use it to dispatch async handlers. It only works with blocking functions, or spawning a whole task in the blocking function. I... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/yzekuAUALQiKCaCfEUEGTvHX>)
<PinballWIzard[m]>
will go on with my develop
pronvis_ has joined #rust-embedded
pronvis has quit [Read error: Connection reset by peer]
sirhcel[m] has quit [Quit: Idle timeout reached: 172800s]
pronvis_ has quit [Remote host closed the connection]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 272 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 252 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 260 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 264 seconds]
Makarov has joined #rust-embedded
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 256 seconds]
embassy-learner[ has quit [Quit: Idle timeout reached: 172800s]
pronvis has joined #rust-embedded
AtleoS has quit [Ping timeout: 268 seconds]
AtleoS has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
Makarov has quit [Quit: Client closed]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 272 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 260 seconds]
pronvis has joined #rust-embedded
Amnesia has left #rust-embedded [#rust-embedded]
pronvis has quit [Ping timeout: 240 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 260 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 240 seconds]
IlPalazzo-ojiis1 has joined #rust-embedded
IlPalazzo-ojiis1 has quit [Read error: Connection reset by peer]
IlPalazzo-ojiis1 has joined #rust-embedded
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 252 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
IlPalazzo-ojiis1 has quit [Remote host closed the connection]