explore has quit [Quit: Connection closed for inactivity]
_skunkjoe has joined #rust-embedded
_skunkjoe has quit [Ping timeout: 240 seconds]
ymwm_ has quit [Remote host closed the connection]
ymwm_ has joined #rust-embedded
ymwm_ has quit [Ping timeout: 256 seconds]
ymwm_ has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
rektide has joined #rust-embedded
explore has joined #rust-embedded
<re_irc>
<clarkkozak> good day everyone!
<re_irc>
I'm playing with a micro:bit v2! So exciting!! For some reason though, when I try to set a break point in the debug, and say continue, it doesn't go to the main function. What's going on?
<re_irc>
Reading symbols from target/thumbv7em-none-eabihf/debug/led-roulette...
<re_irc>
<clarkkozak> I also get "No Source Available" when testing out "layout src" in gdb
<re_irc>
<9names (@9names:matrix.org)> which gdb version are you using?
<re_irc>
<9names (@9names:matrix.org)> that looks like what happens when you're not using a gdb that doesn't support your target - say, if you're using gdb instead of gdb-multiarch on debian/ubuntu
<re_irc>
<9names (@9names:matrix.org)> that wasn't meant to be a double negative, let me try again: "when you're using a gdb that does not support your target"
explore has quit [Quit: Connection closed for inactivity]
fooker has quit [Ping timeout: 252 seconds]
ymwm__ has joined #rust-embedded
_skunkjoe has joined #rust-embedded
ymwm_ has quit [Ping timeout: 272 seconds]
_skunkjoe has quit [Ping timeout: 250 seconds]
<re_irc>
<clarkkozak> gdb --version
<re_irc>
GNU gdb (GDB) 11.
<re_irc>
I may have to get gdb-multiarch. Gimmie a sec
<re_irc>
<clarkkozak> Yes! You're right :) Close reading has always been tricky for me.
<re_irc>
NOTE Depending on which GDB you installed you will have to use a different command to launch it, check out chapter 3 if you forgot which one it was.
<re_irc>
btw arch
<re_irc>
<clarkkozak> How is it possible that we can use the microbit crate without having it definied in the Cargo.toml?
<re_irc>
<K900> Is it?
<re_irc>
<K900> Pretty sure it's not, unless you're using some wrapper around Cargo
<re_irc>
<clarkkozak> 🤷 I'm going through the LED blink for microbit here:
<re_irc>
<clarkkozak> wooooo that's magical. Rust is so cool
<re_irc>
<K900> Nothing really magical about it
<re_irc>
<K900> It's just slightly weird toml syntax
<re_irc>
<clarkkozak> hey don't pop my bubble. Everything is magical when you're a noob
<re_irc>
<clarkkozak> Sometimes I get 1000ms intervals and sometimes i get this repeat error: "Error reading from RTT: Error communicating with probe: A core architecture specific error occurred"
<re_irc>
<clarkkozak> after that I get "Error failed attaching to target"
<re_irc>
<K900> Check the wiring?
<re_irc>
<clarkkozak> it works with the blinking code thogh not the RTT delay 🤷
<re_irc>
<K900> The blinking code doesn't need to communicate with the board
<re_irc>
<clarkkozak> oh interesting good point. I did plug it and unplug it though that didn't do anything
<re_irc>
<K900> Maybe try a different USB port
<re_irc>
<clarkkozak> good moves. testing..
<re_irc>
<K900> Sometimes it's janky like that
<re_irc>
<clarkkozak> you were right for 8 seconds
<re_irc>
<clarkkozak> try a couple. same results
<re_irc>
<K900> Desktop or laptop?
<re_irc>
<clarkkozak> desktop
<re_irc>
<K900> Try one on the back
<re_irc>
<clarkkozak> right into the mobo
<re_irc>
<clarkkozak> tried
<re_irc>
<clarkkozak> trying again..
<re_irc>
<clarkkozak> yeah blue or not same result of that error
<re_irc>
<ryan-summers> What board are you running on? I know there were issues with early ST-link firmware versions and probe-rs a while back
<re_irc>
<clarkkozak> micro:bit v2
<re_irc>
<clarkkozak> the log is hard to grab tbh. It just repeats. Had to take a screenshot to write it done
<re_irc>
<ryan-summers> Huh... the Micro:bit v2 doesn't seem to have the target CPU /RST pin wired to anything... That's an odd programmer configuration
<re_irc>
<ryan-summers> I wonder if you have some bad binary on the board that's disabling the debug interface, and the lack of RST is preventing you from reprogramming? But I'm not sure
<re_irc>
<ryan-summers> Haven't worked with the micro:bit personally
<re_irc>
<clarkkozak> Haha this is my first board! Going through this book. Learning a lot for sure
<re_irc>
<clarkkozak> It talks for a couple of seconds, then throws that error
<re_irc>
<ryan-summers> Ah but you can still program the first run through?
<re_irc>
<clarkkozak> Not as expected. It repeats that error endlessly
<re_irc>
<ryan-summers> But is the device still blinking the LED?
<re_irc>
<clarkkozak> ryan-summers: ah. Sorry for the miscommuncation. There are 2 programs that i'm trying to run:
<re_irc>
Blinking works as expected, while delyaing gives me this error. According to K900 the blinking code doesn't need to communicate with the board, I guess it only flashes
<re_irc>
<ryan-summers> That's odd... so the delay example doesn't work, but the blink one does? They look like essentially the same thing
<re_irc>
<clarkkozak> Interesting right! Im sure its something with my personal setup. Id love to find out why, cuz RTT seems helpful for this stuff
<re_irc>
<ryan-summers> What does your Embed.toml look like for the two projects? Are they different?
<re_irc>
<clarkkozak> as suggested I updated it for this part
<re_irc>
<clarkkozak> what paste bin do y'all prefer?
<re_irc>
<ryan-summers> Github gists is usually easiest
<re_irc>
<clarkkozak> ...hehe too late. The classic:
<re_irc>
<ryan-summers> But you have the same Embed.toml for both the blinking and delay examples?
<re_irc>
<clarkkozak> yes
<re_irc>
<ryan-summers> Try just taking the blinking example and commenting out things in the loop so you just have a delay + print
<re_irc>
<ryan-summers> So take the working example (blinking) and slowly move it to the non-working (delay) example - at whichever point it breaks will give you a hint
<re_irc>
<clarkkozak> Ah! it breaks too!
<re_irc>
<ryan-summers> There might be some weird subtle timing thing happening too, dunno. I think the micro-bit discovery stuff is still fairly new
<re_irc>
<ryan-summers> Try just commenting out like the "set_high()" and see if that still has problems
<re_irc>
<clarkkozak> Ah, links instead of uploading. Right on, my bad y'all
<re_irc>
<ryan-summers> Is there a preference? I upload images here all the time. In any case, that's an odd error to see. It implies that RTT is still going at the expected interval, just that probe-rs can't talk to the probe for some reason
<re_irc>
<ryan-summers> This very well could be an issue with the built-in programmer talking to probe-rs and not you at all
<re_irc>
<ryan-summers> It looks like probe-rs is failing to read data from the RTT channel somehow? Or the RTT channel data is getting corrupted or something
<re_irc>
<clarkkozak> Interesting. Should I open up an issue somewhere?
<re_irc>
<ryan-summers> But if the messages are appearing at the expected 1s interval, then your code is likely running just fine
<re_irc>
<clarkkozak> or mention this in the probe-rs channel?
<re_irc>
<ryan-summers> Probably bring this up on the probe-rs channel
<re_irc>
<xiretza> clarkkozak: (I don't think uploading media is actually a problem, that reaction is just the discord bridge showing that it's processed the message)
<re_irc>
<clarkkozak> ryan-summers: do I put that in my environment then run it? how does that produce logs?
<re_irc>
<ryan-summers> I'm looking to see what log backend cargo-embed uses. That's a specific environment variable the the rust-env-logger backend, which many tools use
<re_irc>
<ryan-summers> Yeah, just use the RUST_LOG env variable for now. You can specify log levels in the TOML as well I believe, but docs say RUST_LOG overrides it
<re_irc>
<ryan-summers> the "RUST_LOG=debug cargo embed" is a bash-ism for setting RUST_LOG for the single command. You can also set the environment variable by whatever means you prefer if you're on Windows
<re_irc>
<clarkkozak> as a note, it blinks and will eventually through that unless error print
<re_irc>
<ryan-summers> Yeah, so I think probe-rs may be having difficulties talking to the debugger firmware they have on the micro-bit sometimes
<re_irc>
<ryan-summers> The further logs might show us a hint about what's going on, but this would all likely go into an issue in probe-rs if that appears to be the case
<re_irc>
Good news is I got my first LED to blink EVER!!!
<re_irc>
<clarkkozak> Okay right on :D thanks for your help!
<re_irc>
<clarkkozak> So much more interesting than a hello world with nodejs
<re_irc>
<ryan-summers> Glad to hear you're enjoying it! LED blinking is something that never goes away in an embedded career, even decades later 😅
<re_irc>
<Clark Kozak> hmm unique id. Maybe I shouldn't have shared all of that. Is this suppsoed to be private information?
<re_irc>
<ryan-summers> Honestly not a clue. If it's not connected to the internet and isn't some private key for signing things, you're probably fine
<re_irc>
<Clark Kozak> yeah I have the latest version of the DAPLink firmware. I don't think reinstalling that would make difference. As for jlink, I'd rather not as that's not what the Rust Embedded Discovery guide suggests to do
<re_irc>
<Clark Kozak> ryan-summers: okay cool. No one hack my blinking led
<re_irc>
<ryan-summers> Yeah, I didn't see any available updates
<re_irc>
<ryan-summers> +for the DAPlink firmware
starblue has quit [Ping timeout: 272 seconds]
<re_irc>
<Clark Kozak> Oh hey. What does the "Incompataible iamge detection: 1" mean?
starblue has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]