<JomerDev[m]>
Thank you so much dirbaio for all the help!
sashin has quit [Remote host closed the connection]
blueluna[m] has joined #rust-embedded
<blueluna[m]>
<jessebraham[m]> "I've had a few people ask me now..." <- No. I haven't come across anything. I have a hacky work in progress Zigbee stack that works for nrf52, but I do not have much time to work on it. https://github.com/blueluna/psila/ . Got it working on micro:bit v2 a few weeks ago though (Level light device).
<Ecco>
So I tried implementing a wrapper around AtomicUsize for function pointers
<adamgreig[m]>
<JamesMunns[m]> "Writing through a shared..." <- It is an unsafecell though, through vcell
<JamesMunns[m]>
adamgreig[m]: Fair, tho doing it w/o calling get is... sorta up in the air :D
<JamesMunns[m]>
JamesMunns[m]: (I only learned that part recently)
<adamgreig[m]>
I mean, it's a memory mapped struct that exists basically just to conveniently store an address in mmio memory so I guess it's all a bit up in the air :p
crabbedhaloablut has quit []
<adamgreig[m]>
Since all access to the underlying memory will be volatile ptr ops it seems like the optimiser probably doesn't get a chance to mess this one up?
<JamesMunns[m]>
Yeah, I get it, just passing on that squelching that error is possibly not a great idea
<adamgreig[m]>
Still, it would be better if svd2rust generated an API for doing specific sized accesses to registers...
<JamesMunns[m]>
adamgreig[m]: UB is still UB, even if the optimizer isn't smart enough to exploit it today
<adamgreig[m]>
This problem is because you need to do a u8 access to dr, svd2rust write() API doesn't support it, the compiler warning is new, so people have been independently finding the warning and ways to silence it
crabbedhaloablut has joined #rust-embedded
<JamesMunns[m]>
does svd2rust expose VolatileCell::as_ptr()?
<JamesMunns[m]>
that appropriately uses UnsafeCell::get()
<JamesMunns[m]>
(that code is specifically from the stdlib docs, saying "don't do what firefrommoonlight did")
<adamgreig[m]>
right, the HAL problems recently have all had ownership/&mut for the registerblock and thus for the unsafecell
<adamgreig[m]>
if firefrommoonlight's example had `&mut self.spi.dr as *mut u8` you avoid the issue I guess?
<JamesMunns[m]>
yep!
<JamesMunns[m]>
&mut to *mut: also totally fine.
<JamesMunns[m]>
`& to *const to *mut`: Not fine
<FreeKill[m]>
Sorry to ask again but does anyone have a clue why [profile.dev.package."*"] would produce a binary with 80K more stuff in it than [profile.dev], when my main function is only contributing ~1K
<FreeKill[m]>
I was under the impression they should optimise all the dependency code the same
<adamgreig[m]>
yea, that should work. perhaps you're bringing in code that's being counted as part of your crate instead of a dependency, perhaps due to macros or generic code or otherwise, and so that's all not getting optimised?
<adamgreig[m]>
you could try tools like cargo bloat to see where the 80k is coming from
<FreeKill[m]>
I actually measured it using my own tool, nesiac
<FreeKill[m]>
But it's about the same data
<FreeKill[m]>
And also it failed to compile :P I had to artificially increase the size of the flash beyond what it really has in order to get it to compile and see the memory usage
<adamgreig[m]>
wow, it's really all hiding in "and hundreds of smaller methods" huh
<adamgreig[m]>
maybe if you do -n 1000 you can see if they're all coming from the same place?
<FreeKill[m]>
FYI [profile.dev.package.bitvec] doesnt affect the size of bitvecs code either
IlPalazzo-ojiisa has quit [Quit: Leaving.]
Guest7282 has joined #rust-embedded
<adamgreig[m]>
I guess the issue is that much of the bitvec code is not compiled when the bitvec crate is built but when your crate is built, so it gets your crate's optimisation setting
<adamgreig[m]>
in general it's very common in embedded to keep all parts of the build at least opt-level=1, so maybe it would be worth having opt-level=z for all packages and opt-level=1 for your crate and see if that gets your memory usage low enough?
<FreeKill[m]>
i assume the later entry in cargo.toml is the one to pick?
<FreeKill[m]>
I feel like that would be useful to mention in the optimisation part of the book tbh
<Ecco>
Why does NVIC.set_priority require and instance and NVIC::unmask does not?
<Ecco>
In other words, why can't I just call NVIC::set_priority(my_int, my_prio)
<adamgreig[m]>
FreeKill[m]: yea, would you like to make a short pr?
<FreeKill[m]>
Aw go on, for the bants
<adamgreig[m]>
Ecco: not sure but I expect it's because on armv6m it's because it has to do a read-modify-write of the relevant IPR register, so it would race concurrent calls to the same method
<adamgreig[m]>
whereas unmask is always a plain write, so can't race
<Ecco>
hmm, ok!
<JamesMunns[m]>
I wonder if all of bitvecs methods are inlined, and inlining defeats optimized deps
<FreeKill[m]>
It's also pretty wild that opt-level 1, 3 and "z" are all basically the same size
<FreeKill[m]>
within about a KB or 2
<FreeKill[m]>
is it generally the case that opt-level 1 is "debug friendly"?
<FreeKill[m]>
Sort of like O1 and Og in GCC are approximately the same
<adamgreig[m]>
Yea, generally. Certainly much more debug friendly than the higher levels anyway! With no optimisations a lot of code ends up really huge and slow, making it infeasible for embedded
<FreeKill[m]>
Fair enough. It feels, then, like my approach should just be to stick everything at 1 until something tells me otherwise
crabbedhaloablut has quit []
Guest7282 has left #rust-embedded [Error from remote client]
crabbedhaloablut has joined #rust-embedded
<FreeKill[m]>
Currently batting a 1 documentation PR per day messing about with embedded rust, gonna have to try and keep that average :P
Guest7282 has joined #rust-embedded
sashin has joined #rust-embedded
AdinAck[m] has joined #rust-embedded
<AdinAck[m]>
i suddenly cannot flash a chip i have absolutely flashed before, it's on a nucleo, i even plugged in my jlink and it couldn't flash it either, is my chip dead somehow?
<adamgreig[m]>
have you tried enabling --connect-under-reset? or asserting boot0 while resetting to reboot into bootloader, then flashing?
<adamgreig[m]>
if it's on a nucleo I guess you're using the onboard stlink, did you reconfigure the jumpers for using an external programmer to try using the jlink?
<AdinAck[m]>
i haven't touched this board at all, and it is even running embassy blinky so i know i have flashed it before
<AdinAck[m]>
adamgreig[m]: i'll give this a go
<AdinAck[m]>
connect under reset: no change
<AdinAck[m]>
boot0: did not enter the bootloader lol
<adamgreig[m]>
is the chip definitely on and receiving power? could you have removed one of the jumpers used for current measurement? did you do anything weird to the chip when it stopped working?
<AdinAck[m]>
it's been sitting on my desk untouched, and it's definitely working since it's running blinky
<AdinAck[m]>
there are only so many jumpers and they all look right to me
<AdinAck[m]>
ugh there's no way it just died sitting on my desk for a few weeks something must have happened
<FreeKill[m]>
You could try the STM programmer utility
<FreeKill[m]>
It will let you connect under hard reset, and it can inspect the chip and diagnose hard failures
<FreeKill[m]>
If you're getting stuck in a hard fault or something, for instance. You can also read all the option bytes
<AdinAck[m]>
ok cool i'll try that, thanks
<AdinAck[m]>
hope it works on apple silicon
<FreeKill[m]>
Ah :c
<FreeKill[m]>
I hope so too 😅
<AdinAck[m]>
what's weird is that boot0 did not work...
<FreeKill[m]>
That's not necessarily weird
<FreeKill[m]>
Option bytes can disable boot0 on some chips for example
<AdinAck[m]>
ah ok
Guest7282 has left #rust-embedded [Error from remote client]
<AdinAck[m]>
stm programmer has no problem reading and writing flash lol
<FreeKill[m]>
I have seen the same sometimes, even just using cortex debug in vscode
<FreeKill[m]>
That the STM programmer is much more reliable at getting the chip back under control. I don't know what it does differently
<AdinAck[m]>
yeah weird
<AdinAck[m]>
do you know how to spit out a .bin or .hex from rust so i can just flash with stm programmer?
<AdinAck[m]>
i imagine it's some use of objdump
<FreeKill[m]>
It will flash an elf
<AdinAck[m]>
oh ok nice
<FreeKill[m]>
I would double check your option bytes, just to see
<FreeKill[m]>
That is the only reason that the boot pins would fail to send you to bootloader (but it's chip dependent)
<AdinAck[m]>
but here's the relevant option bytes i believe
<AdinAck[m]>
i assume these are default
<FreeKill[m]>
Heh no I actually don't think so
<FreeKill[m]>
I could be wrong of course I don't have the manual
<FreeKill[m]>
But nSWBOOT0 = 0 means your boot0 pin is being ignored, wrt boot location
<AdinAck[m]>
yeah ok well i re-enabled it
<AdinAck[m]>
i feel dumb but i can't find the elf file from my rust project :/
<AdinAck[m]>
seems there's only a binary
<FreeKill[m]>
Rust doesn't append "elf"
<AdinAck[m]>
i could have sworn it did in the past
<FreeKill[m]>
It'll just be called <crate name> but it is an elf file
<AdinAck[m]>
nonetheless, adding .elf to the end and uploading it caused a lot of errors
<FreeKill[m]>
If you want to be double sure it's an elf, open it in a hex editor
<AdinAck[m]>
nevermind it worked!
<FreeKill[m]>
The first few bytes are `.ELF`
<AdinAck[m]>
???
<FreeKill[m]>
Yay 😁
<AdinAck[m]>
probe-rs still can't flash to it
<AdinAck[m]>
but after updating that OB i can flash with stm programmer
<AdinAck[m]>
yay...?
<AdinAck[m]>
i wonder if i'll be able to attach with probe-rs
<FreeKill[m]>
Wait wait wait
<FreeKill[m]>
That option byte shouldn't matter for flashing over jlink/swd
<FreeKill[m]>
All it controls is entering the bootloader after reset, your debugger shouldn't care
<AdinAck[m]>
you're right, i disabled it and it still worked
<AdinAck[m]>
...i wonder why it didn't work the first time
<firefrommoonligh>
<AdinAck[m]> "what's weird is that boot0 did..." <- Yea. That's usually the fix
<FreeKill[m]>
Okay. So it is possible that your program disables the debug interface at run time. In which case you need to connect under hardware reset
<AdinAck[m]>
ok well it seems that this works for now, probe-rs can't attach so i can say goodbye to defmt on this board
<firefrommoonligh>
Is it using WFI?
<AdinAck[m]>
i don't know what WFI is
<AdinAck[m]>
but this is the embassy blinky example lol
<FreeKill[m]>
Then yes it is
<FreeKill[m]>
Very likely
<AdinAck[m]>
oh right that's how the default executor works
<firefrommoonligh>
You may need the set bits in the DBGMCU reg and enable DMA
<FreeKill[m]>
WFI puts the device in low power mode and stops the clocks - unless certain bits are set in the debug peripherals, this will break a debug session - and prevent one from starting
<AdinAck[m]>
ok but i flashed this chip a few weeks ago without having to do any of this
<AdinAck[m]>
ooohhh but you're saying the program i flashed is now causing this
<AdinAck[m]>
ok how can i do this lol
<FreeKill[m]>
That is certainly plausible
<FreeKill[m]>
Most debug adapters, when they connect, will also set the relevant debug registers so they can preserve their own existence
<FreeKill[m]>
So! One thing to try is to do a mass erase via STM prog
<AdinAck[m]>
FreeKill[m]: i set `connect_under_reset` to true and the behavior didn't change
<FreeKill[m]>
And then start a fresh debug session with your desired debugger
notgull has joined #rust-embedded
<AdinAck[m]>
FreeKill[m]: i did press the "full chip erase" button
<FreeKill[m]>
Ok. And after that, can probe rs reach the chip?
<FreeKill[m]>
Okay. I'm afraid I no longer have the specific experience to help you
<AdinAck[m]>
LOL thank you so much for trying anyway
<FreeKill[m]>
It is generally the case that attaching to a running core under wfi is hard, but if you launch the debug session you can also set the registers you need to keep yourself alive
<Ecco>
FreeKill[m]: you may want to try with another flashing software
<Ecco>
Possibly the chip's vendor software
<AdinAck[m]>
yes flashing fully works with stm32 programmer
<AdinAck[m]>
it's just probe-rs for some reason cannot connect at all
<FreeKill[m]>
You may want to ask in the probe rs channel
<AdinAck[m]>
that could be the only discrepancy since the first time i flashed it, i may have updated probe-rs, not sure though
<FreeKill[m]>
It is very very strange to not be able to flash an erased chip, though
<FreeKill[m]>
That is suspect
<AdinAck[m]>
i agree
notgull has quit [Ping timeout: 256 seconds]
<FreeKill[m]>
I'd ask the probe rs folks 😅
<AdinAck[m]>
yep, i'll hop over there, thanks again :)
<FreeKill[m]>
No worries, glad your chip lives. Good luck
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
notgull has joined #rust-embedded
notgull has quit [Ping timeout: 268 seconds]
dngrs[m] has joined #rust-embedded
<dngrs[m]>
<AdinAck[m]> "i set `connect_under_reset` to..." <- I definitely ran into this before with some F401/F411s. Solved it by holding down the physical reset button while starting probe-run and letting the button go at the exact right point in time (when flashing was just about to start)
<firefrommoonligh>
<FreeKill[m]> "It is very very strange to not..." <- Yea def. I brought up the WFI hang and DBGMCU/DMA bc you will get a fail to flash (until boot0 erase) if you go into WFI with a debugger connected without
<firefrommoonligh>
(This workaround impacts power consumption, so make sure to turn it off in production)
<AdinAck[m]>
we resolved this in the probe-rs room. it was fixed in probe-rs unreleased, but a new bug was introduced, daniel is fixing it now
<Ecco>
Sweet!
notgull has joined #rust-embedded
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
user1__ has joined #rust-embedded
stuw1 has quit [Ping timeout: 256 seconds]
salsasteve[m] has joined #rust-embedded
<salsasteve[m]>
Hello everyone, I understand that probe-rs only works if you have a physical debugger or an on-board debugger, is that correct? I own a Matrix Portal M4 and, as far as I'm aware, it doesn't have an on-board debugger, and I don't have a physical debugger either. What alternative debugging methods can I use? Also, what should I consider purchasing to debug my microcontrollers?
<salsasteve[m]>
* Hello everyone, I understand that [probe-rs](https://probe.rs/docs/overview/about-probe-rs/) only works if you have a physical debugger or an on-board debugger, is that correct? I own a [Matrix Portal M4](https://www.adafruit.com/product/4745) and, as far as I'm aware, it doesn't have an on-board debugger, and I don't have a physical debugger either. What alternative debugging methods can I use? Also, what should I consider
<salsasteve[m]>
purchasing to debug my microcontrollers?
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
that's correct. you could instead set up a serial port or usb-based log and print to it, but ideally I'd buy a debugger. there's a lot of options, like a cheap stlinkv2 clone or daplink on aliexpress/ebay, mcu-link, the raspberry pi debug probe, or the upcoming (but not yet released) rusty-probe https://shop.probe.rs/products/rusty-probe
<vollbrecht[m]>
also as i understand it has two chips an an cortexm4 and a esp32. For the esp32 you can use something like the esp-prog or any alternative with the same ftdi chip on it