<re_irc>
< (@antonok:antonok.com)> ok, I narrowed it down to a "UsbDeviceBuilder" call. In my case I'm resetting to bootloader past that point, but I think flashing onboard LEDs would work just as well. Works on stable but not nightly.
<re_irc>
< (@adamgreig:matrix.org)> weird, I wonder what's going on there then
<re_irc>
< (@adamgreig:matrix.org)> btw, in cargo.toml the ^ is used by default if you don't specify anything else, so "0.13" is identical to "^0.13"
<re_irc>
< (@adamgreig:matrix.org)> ah, sorry, threads somehow got turned off in my element settings?
<re_irc>
< (@antonok:antonok.com)> hacknus seems to have narrowed it down to an issue with the AHB clock in "stm32f4xx-hal" in nightly, although I don't see any other reports
<re_irc>
< (@adamgreig:matrix.org)> do you have a debugger attached? I wonder if you're also hanging on waiting for AHBIDL to be set
<re_irc>
< (@adamgreig:matrix.org)> I don't know that rust-lang will be able to do anything with it yet, there's no details on how this is a compiler regression as such
<re_irc>
< (@adamgreig:matrix.org)> I've got it reproducing here exactly as you and hacknus describe, though
<re_irc>
< (@adamgreig:matrix.org)> the bit it's trying to read is indeed set in memory so what's going on ...
<re_irc>
< (@adamgreig:matrix.org)> looks like it's a bug in the synopsys-otg-usb crate rather than rust-lang, if you see any commits in the nightly range you're bisecting around struct (re)ordering that's probably it
<re_irc>
< (@adamgreig:matrix.org)> I guess it's in the release notes and all
<re_irc>
< (@adamgreig:matrix.org)> just pulling this out of the stm32 usb thread: https://github.com/rust-lang/rust/pull/102750 means rustc is finally changing around struct ordering, and if you look at all the linked issues you can see everyone having fun with this change, check yo crates for structs that should be "repr(C)"
<re_irc>
< (@adamgreig:matrix.org)> -and if you look at all the linked issues you can see everyone having fun with this change,
<re_irc>
< (@jamesmunns:beeper.com)> dngrs (spookyvision@{github,cohost}): Theres an unstable flag for this, let me find it
<re_irc>
<Félix | Totem> Also, it uses a Direct memory access, not sure if it's handled by stm32-rs and RTIC
<re_irc>
< (@k900:0upti.me)> This is extreme levels of overengineering tbh
<re_irc>
< (@k900:0upti.me)> DMA is a very sharp tool
<re_irc>
< (@k900:0upti.me)> This is not really a good use case for it
<re_irc>
<Félix | Totem> Oh, alright, it's a hard pass, then. I sometimes like overengineering for the fun of it, but not in a field I'm new in 😛
richardeoin has joined #rust-embedded
crabbedhaloablut has quit [Write error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<Julia> Hello I am new to using Rust for embedded systems and am having trouble setting up a simple blinky program. I am working with an nrf51822 and have a st-link v2 programmer, however it seems that flashing doesn't work correctly. I hope this is the right place to ask for help 😅!
<re_irc>
<thejpster> Which software are you using for flashing the nRF51?
<re_irc>
<thejpster> I’m told that some ST Link programmers will only program ST Micro chips.
<re_irc>
<Julia> So I'm not sure how it exactly works, but I just call "cargo embed --release".
<re_irc>
<Julia> I am _very_ new to reading these. I tried setting the flash origin to 0x0000_0000, but that didn't work - unless I made some other error of course.
<re_irc>
< (@omar_u8:matrix.org)> According to this code starts at 0x00000000 but range is not specified.
<re_irc>
<Julia> There should be 256kb memory and 16kb RAM
<re_irc>
< (@omar_u8:matrix.org)> Julia: Not sure, though by the way small tip I think you can do something like this if easier rather than using hex numbers: "LENGTH = 256K"
<re_irc>
< (@omar_u8:matrix.org)> * way,
<re_irc>
<henrik_alser> Julia: can you try erasing the whole flash with nrfutil?
<re_irc>
MEMORY
<re_irc>
<henrik_alser> I believe your memory.x should look like this if you’re not using softdevice
<re_irc>
< (@omar_u8:matrix.org)> Julia Reminds me of my early days trying to get the toolchain to work :) You might want to try with different tools until you get something going and then switch. One option I resort to typically is falling back on vendor setup/toolchain (nrf in your case) to flash the generated binary from elsewhere.
<re_irc>
< (@omar_u8:matrix.org)> It gets easier at a certain point :-)
<re_irc>
<Julia> It really sucks because I follow an embedded systems course, and instead of teaching us C/C++, they teach us Rust. However I haven't seen Rust actually run on any MCU so far :(.
<re_irc>
< (@k900:0upti.me)> Does your course have a specific hardware target that it recommends?
<re_irc>
<Julia> nrf51822
<re_irc>
<Julia> We are supposed to make a control system for a drone using it next semester, which is why I wanted to get a headstart to see if I can get it working.
<re_irc>
< (@k900:0upti.me)> That's just a chip, but any specific board?
<re_irc>
<Julia> I don't know that yet.
<re_irc>
< (@k900:0upti.me)> What board are you using right now?
<re_irc>
<Julia> By board do you mean the thing I'm plugging it into? That'd be the BLE400.
<re_irc>
< (@k900:0upti.me)> The nRF51822 is just the chip itself
<re_irc>
< (@k900:0upti.me)> So presumably you have the official evaluation kit
<re_irc>
< (@adamgreig:matrix.org)> given as flash programming seems to have succeeded it seems like the stlink and connection is OK
<re_irc>
<Julia> There are only 4 cables to connect and I checked multiple times that they are correct. Ubuntu also recognizes my programmer.
<re_irc>
< (@adamgreig:matrix.org)> just something's wrong with what's being programmed that means it's not starting up (assuming it's not blinking as well as the RTT error)
<re_irc>
< (@k900:0upti.me)> If the debugger works properly, you should be able to, well, debug your code
<re_irc>
< (@k900:0upti.me)> As in step through it and see what it does
<re_irc>
< (@k900:0upti.me)> And where (or if) it breaks
bjc has joined #rust-embedded
<re_irc>
< (@dkhayes117:matrix.org)> Do you have a .cargo/config.toml file?
<re_irc>
< (@k900:0upti.me)> Well that's not as much information as I hoped
<re_irc>
< (@k900:0upti.me)> Might be a good time to file a bug on probe_rs tbh
<re_irc>
< (@k900:0upti.me)> This definitely isn't normal
<re_irc>
< (@k900:0upti.me)> It looks like the chip-side code is failing for whatever reason
<re_irc>
<Julia> The first thing that comes to mind is that I did something wrong since this is the first time I'm doing this, not that the software I'm using is wrong. I think there is a server for probe-rs, maybe I should ask there first?
<re_irc>
< (@k900:0upti.me)> I'd probably file an issue, because even if you _are_ doing something wrong, this is not a good failure mode
_whitelogger has joined #rust-embedded
<re_irc>
<Julia> : It's the same, and we checked the sheets.
<re_irc>
<Julia> * same error,
<re_irc>
< (@yatekii:matrix.org)> no the datasheet says "256kB/128kB flash and 32kB/16kB RAM" and they use 256kb flash and 16kb RAM which sounds wrong to me
<re_irc>
< (@k900:0upti.me)> The board comes with the higher end chip, supposedly
<re_irc>
< (@adamgreig:matrix.org)> Would it matter though? The tiny blink firmware isn't going to write over 128k of flash and the ram is small enough to not be putting the stack in the wrong place anyway
<re_irc>
< (@yatekii:matrix.org)> : the nRF51 standard algos do some stupid fucking checks and rease all flash and stuff like that. fgixed it for the nrf52's but not for the 51's I think
<re_irc>
< (@yatekii:matrix.org)> so depending on what Is already on there etc it could be that.
<re_irc>
< (@yatekii:matrix.org)> the flash algo error code is something we do not control and is from nordic.
<re_irc>
< (@adamgreig:matrix.org)> Ah, annoying
<re_irc>
< (@yatekii:matrix.org)> Julia: does "probe-rs-cli info" say something useful? What does "probe-rs-cli erase --allow-erase-all --chip nRF51822" do?
<re_irc>
DEBUG probe_rs::flashing::flasher: content of a1 0x0: 0x00000000 should be: 0x00000000
<re_irc>
< (@k900:0upti.me)> Is that all the output?
<re_irc>
<Julia> Yes
<re_irc>
< (@korken89:matrix.org)> Has anyone else experienced that "cortex-m-semihosting" "v0.5.0" breaks in QEMU?
<re_irc>
< (@korken89:matrix.org)> A lot of RTIC examples that are tested in CI now needs a "nop()" between an "hprinln!" and "debug::exit(..)" or the last "hprintln!" is not printed
<re_irc>
< (@yatekii:matrix.org)> Julia: can you try flashing again?
<re_irc>
< (@adamgreig:matrix.org)> : wonder if it's because it's now using inline asm and so there's not more instructions there anyway
<re_irc>
< (@adamgreig:matrix.org)> and thus revealing some weird thing with qemu
<re_irc>
<Julia> : Same error still.
<re_irc>
< (@korken89:matrix.org)> Hmm
<re_irc>
< (@korken89:matrix.org)> : Could be, I have not tested on hardware only that QEMU does not like it 😅
<re_irc>
< (@korken89:matrix.org)> And it was a bit weird that a NOP fixes it, like there is a "delay" in "hprintln"
<re_irc>
< (@korken89:matrix.org)> But it's based on breakpoints so it should not have a "delay" for printing
<re_irc>
< (@yatekii:matrix.org)> Julia: do you have a commit to the current project setup?
<re_irc>
< (@adamgreig:matrix.org)> there's a zip file ^
<re_irc>
<Julia> I can make my github repository public, and share it here if you like.
<re_irc>
<Julia> Otherwise yes there is a zip file like adam said.
<re_irc>
< (@yatekii:matrix.org)> : I think it's outdated
<re_irc>
< (@korken89:matrix.org)> We'll make an issue on "cortex-m-semihosting" and track it there
<re_irc>
< (@adamgreig:matrix.org)> : could you possibly include a disassembly snippet around the final hprintln and debug::exit call to compare 0.4 to 0.5? i wonder if it's just ending up as literally bkpt, bkpt
<re_irc>
< (@korken89:matrix.org)> : We updated from "0.3.3" to "0.5" so we're not really sure if "0.4" or "0.5" is the issue
<re_irc>
< (@korken89:matrix.org)> But we'll include asm
<re_irc>
< (@adamgreig:matrix.org)> might be some sort of bug in qemu
<re_irc>
< (@adamgreig:matrix.org)> maybe debug::exit could have a preceding nop though
<re_irc>
< (@korken89:matrix.org)> Could indeed be
<re_irc>
< (@korken89:matrix.org)> Yeah, I think that should be fine
<re_irc>
< (@yatekii:matrix.org)> Julia: are you able to read the markings on the chip?
<re_irc>
<Julia> It only says NRF51822 sadly, no postfix.
<re_irc>
< (@yatekii:matrix.org)> also not underneath? it must be there ...
<re_irc>
< (@k900:0upti.me)> Can you post a picture of it?
<re_irc>
<Julia> Not underneath either, but I will make a picture of both sides.
<re_irc>
< (@yatekii:matrix.org)> The problem is that it's only the flash-algorithm failing. and the nRf51822 is chip-0 aka the thing we always tested with. so I doubt anything really bad
<re_irc>
< (@yatekii:matrix.org)> lemme grab my microbit
<re_irc>
< (@dkhayes117:matrix.org)> Probably won't help, but did you try it with 32K of RAM?
<re_irc>
< (@yatekii:matrix.org)> Julia: I can flash perfectly fine. and get an RTT console. most likely your "nrf51822" is just bad. Looks very china china to me, no offense
<re_irc>
NOTE: Any generated log error messages will be displayed.
<re_irc>
NOTE: For additional output, try running again with logging enabled (--log).
<re_irc>
<Julia> I don't have a segger debugger, which I think you need to use this.
<re_irc>
< (@yatekii:matrix.org)> ah shoot didn't consider that
<re_irc>
< (@dirbaio:matrix.org)> Julia: try disconnecting VDD from the stlink to the board, and powering the board independently over usb
<re_irc>
< (@dirbaio:matrix.org)> the stlink's power regulator could be not powerful enough
<re_irc>
< (@dirbaio:matrix.org)> flaky power can cause fun issues like this
<re_irc>
<Julia> Okay let me grab an extra cable.
<re_irc>
<Julia> It now shows a light on the board, but it still has the same error when I try to flash.
<re_irc>
< (@afoht:matrix.org)> : Issue added, hopefully that covers the disassembly you were looking for, if not I have the files so can provide them if needed.
<re_irc>
<Julia> So, how do I quickly switch between the two then? Like if I want to setup a task that includes flashing and one that just resets?
<re_irc>
< (@yatekii:matrix.org)> Julia: default is just the profile name. you can make as many profiles as you want. and you can do "cargo embed profile"
<re_irc>
< (@yatekii:matrix.org)> you do not need to set all fields of the profile. it will inherit from default.
<re_irc>
< (@yatekii:matrix.org)> if you make more profiles you can also set the profile to inherit from
<re_irc>
<Julia> so if i want a flashing profile, I could do something like:
<re_irc>
enabled = true
<re_irc>
and then call "cargo embed flash"?
<re_irc>
[flash.flashing]
<re_irc>
<Julia> Seems to work. Wow this is a nice workflow!
<re_irc>
< (@yatekii:matrix.org)> Julia: yes
<re_irc>
<Julia> So just out of curiosity then, why do you think probe-rs didnt delete those sectors?
<re_irc>
< (@yatekii:matrix.org)> Julia: because they were protected?
<re_irc>
<Julia> Shouldn't probe-rs do something about that? Like either give a warning or an option to erase them?
<re_irc>
< (@yatekii:matrix.org)> Julia: every chip does locking mechanisms differently and probe-rs does not know about the one for this chip yet. also, the nordic provided flash algorithm here is just plain stupid ... it should error that it cannot erase because it's locked instead of saying the erase was successfull but then failing when writing ...
<re_irc>
<Julia> Could probe-rs abstract over that error and add an additional possible cause? I feel like that could save a headache for future devs.
<re_irc>
< (@yatekii:matrix.org)> Julia: well yes :) it's work ;)(
<re_irc>
< (@yatekii:matrix.org)> those error codes are arbitrary
<re_irc>
< (@yatekii:matrix.org)> and not documented
<re_irc>
< (@yatekii:matrix.org)> don't get me wrong Julia this is a hard bug in my book, but it's tricky to solve, not particularly fun and we all do this in our sparetime :)
bvr has quit [Quit: Lost terminal]
<re_irc>
<Julia> Oh yeah I'm not demanding anything, just maybe a suggestion haha. Anyways cheers for the help and all!
<re_irc>
< (@yatekii:matrix.org)> No worries :)
dc740 has quit [Remote host closed the connection]
<re_irc>
< (@yatekii:matrix.org)> If I can push myself to it I will do this full time soon then stuff like that will be fixed :) If not, welp :D