emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
alefir has joined #rust-embedded
tokomak has joined #rust-embedded
starblue1 has quit [Ping timeout: 250 seconds]
starblue1 has joined #rust-embedded
<re_irc> <Yuhan Lin> cr1901: Is it possible to run "compilefail" tests for "msp430-rt" the same way it's done for "cortex-m-rt"? I tried setting it up but Xargo can't build "compilefail" at all and the Cargo can't build the main crate.
Guest2 has joined #rust-embedded
limpkin has quit [*.net *.split]
Lumpio- has quit [*.net *.split]
badboy has quit [*.net *.split]
sknebel has quit [*.net *.split]
Rahix has quit [*.net *.split]
richardeoin has quit [*.net *.split]
badboy has joined #rust-embedded
limpkin has joined #rust-embedded
sknebel has joined #rust-embedded
Lumpio- has joined #rust-embedded
Rahix has joined #rust-embedded
richardeoin has joined #rust-embedded
<cr1901> Yuhan Lin: I'm not sure what's wrong w/ the msp430-rt docs I'm afraid. I'll take a look this weekend or early next week
<cr1901> Today is not going to be a good day to look at it; docs build fine for me locally when I pass --target=msp430-none-elf -Zbuild-std=core
starblue1 has quit [Ping timeout: 240 seconds]
starblue1 has joined #rust-embedded
<re_irc> <dirbaio> ghidra now explodes while loading rust ELFs? "Error during DWARFAnalyzer import: ghidra.app.util.bin.format.dwarf4.DWARFException: Only DWARF version 2, 3, or 4 information is currently supported."
<re_irc> <adamgreig> rust's too secure for the nsa 🔒️
<re_irc> <dirbaio> it seems it's now generating DWARFv5 by default..?
<re_irc> links to a commit, but it's clang, not llvm, not sure why/how that affects rustc
<re_irc> <dirbaio> there's this https://github.com/rust-lang/rust/issues/75890
<re_irc> <dirbaio> either way I can't recompile, this is when trying to debug a crash from a device in the field lol
<re_irc> <dirbaio> I got a register/stack dump... addr2line outputs nonsense, ghidra won't load the elf... yay
<re_irc> <adamgreig> tried radare2/cutter?
<re_irc> <dirbaio> could try yep
<re_irc> <dirbaio> I got defmt logs too, but they show no clue because "regular" panics like .unwrap() or array indexing aren't logged
<re_irc> <dirbaio> (you can log them to defmt if you opt-in to core::fmt bloat which defeats the point of defmt)
<re_irc> <dirbaio> it'd be amazing if there was a way to get these logged without bloat >_<
<re_irc> <dirbaio> even if forking libcore or whatever
<re_irc> <diondokter> Is "#[no_mangle]" still the only/best way to keep data around even the the compiler thinks it isn't used?
<re_irc> That is what the cortex-m-rt crate does with the vector tables, but this suggests that it isn't a good way: https://internals.rust-lang.org/t/precise-semantics-of-no-mangle/4098
<re_irc> #[link_section = ".spm"]
<re_irc> For my specific usecase, I'd like to include another program in my program. This works:
<re_irc> <dirbaio> there's also "#[used]"
<re_irc> <dirbaio> I have both "#[used]" and "#[no_mangle]" in a similar usecase, I'm not sure if "#[used]" is enough to get it to not optimize it out.. :S
<re_irc> #[used]
<re_irc> #[link_section = ".softdevice"]
<re_irc> <dirbaio> #[cfg(feature = "softdevice")]
<re_irc> #[no_mangle]
<re_irc> <diondokter> Hmmm I can try next time
<re_irc> <diondokter> Thanks!
<re_irc> <dirbaio> plus "include_bytes!" twice to avoid having to hardcode the length D:
<re_irc> <dirbaio> * :D
<re_irc> <diondokter> Ah right
<re_irc> <diondokter> :P
<re_irc> <dirbaio> 🙈
<re_irc> <diondokter> Yeah, just using "#[used]" seems to do the trick!
<re_irc> I like this much better :)
<re_irc> <dirbaio> nice!
tokomak has quit [Ping timeout: 240 seconds]
Guest2 has quit [Ping timeout: 256 seconds]
GenTooMan has quit [Ping timeout: 245 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <gauteh> Are interrupts disabled if I do cortex_m::SCB::sys_reset()?
<re_irc> <adamgreig> as in, will any interrupts still be enabled after the reset? in which case no, the reset clears all enabled vectors in NVIC
<re_irc> <adamgreig> (sorry, I inverted your question: interrupts are all disabled after a reset until enabled by software, and the SCB sys_reset is the same as toggling nRST pin in this case)
<re_irc> <gauteh> Ok!
<re_irc> <gauteh> Thanks.
<re_irc> <omar_u8> I am getting a segmentation fault when trying to run an openocd session, any clues where I shoule be looking?
<re_irc> <omar_u8> I am getting a segmentation fault when trying to run an openocd session, any clues where I shoule be looking?
<re_irc> openocd -f interface/stlink.cfg -f target/stm32f4x.cfg
<re_irc> This is the output im getting
<re_irc> Open On-Chip Debugger 0.11.0
<re_irc> <omar_u8> * should
<re_irc> <9names (@9names:matrix.org)> Run openocd through gdb so you get a stack trace when it segfaults, search their GitHub issues for similar reports, make a new one if you can't find anyone with the same error.
<re_irc> <omar_u8> 9names: I’m sorry but I’m not sure how to do that in gdb. Though in general, when starting gdb I’ve tried connecting to target through gdb, I get a timeout.
<re_irc> <omar_u8> * gdb if you can please help.
<re_irc> <xiretza> omar_u8: "gdb --args openocd -f interface/stlink.cfg -f target/stm32f4x.cfg" should do it - then once in the gdb shell, type "run", wait until it segfaults, then look at the output of "backtrace full"
<re_irc> <9names (@9names:matrix.org)> Just in case it's not clear from the error messages: openocd is crashing, so you are using gdb here to debug openocd, not your embedded program.
<re_irc> <9names (@9names:matrix.org)> If you aren't up for that, you can also try using a different debug tool like probe-rs-debugger or pyocd to see if that helps.