ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc> <@nvsd:matrix.org> is there a way to conditionally include std when running tests? I'm sure I've seen this done but can't remember bug google is failing me.
<re_irc> <@nvsd:matrix.org> * but
<re_irc> <@grantm11235:matrix.org> Replace "#[no_std]" with "#![cfg_attr(not(test), no_std)]"
<re_irc> <@nvsd:matrix.org> * and
<re_irc> <@nvsd:matrix.org> I'm such a dumb dumb
<re_irc> <@nvsd:matrix.org> For some reason I was adding that above my test instead of replacing the #[no_std] at root
<re_irc> <@nvsd:matrix.org> πŸ€ πŸ”«
<re_irc> <@nvsd:matrix.org> lol thanks for the help
<re_irc> <@grantm11235:matrix.org> lol no problem
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
<re_irc> <@korken89:matrix.org> Has anyone had the issue with "defmt" that it randomly has started printing out binary data instead of decoded data? If so, did you figure out what it was?
<re_irc> I an almost clean project I now do "defmt::info!("hello"); panic!("world");" and run with "DEFMT_LOG=trace cargo run --bin app", and only the panic comes out, the hello does not come out. If I pring a lot of stuff I finally get the following:
<re_irc> (HOST) INFO flashing program (32 pages / 32.00 KiB)
<re_irc> (HOST) INFO success!
<re_irc> ────────────────────────────────────────────────────────────────────────────────
<re_irc> >~?<:=r%r;j?>
<re_irc> (0b80b8|0b8
<re_irc> UοΏ½8|οΏ½8pοΏ½8
<re_irc> }JB@zAzBzCzDzEzzKzL
<re_irc> zN
<re_irc> zO
<re_irc> zG=:}H:I>q
<re_irc> <@korken89:matrix.org> Moreover I am streaming out 10 times per second a temerature reading, instead I get the following:
<re_irc> AX
<re_irc> :HK B
<re_irc> AY
<re_irc> AZ
<re_irc> :PοΏ½B
<re_irc> :d!B
<re_irc> A[
<re_irc> :"B
<re_irc> A\
<re_irc> :"B
<re_irc> A]
<re_irc> :οΏ½#B
<re_irc> A^
<re_irc> :XοΏ½B
<re_irc> <@korken89:matrix.org> Plus the "INFO" infront is missing
<re_irc> <@korken89:matrix.org> It seems like "probe-run" spews out random data?
<re_irc> <@korken89:matrix.org> I also get the same output with "probe-rs-cli run"
<re_irc> <@korken89:matrix.org> So maybe it's defmt decoder that is printing this?
<re_irc> <@korken89:matrix.org> Alright, I have a reproduction the following app prints "~" instead of "INFO hello":
<re_irc> #![no_std]
<re_irc> use defmt_rtt as _;
<re_irc> #![no_main]
<re_irc> use panic_probe as _;
<re_irc> #[rtic::app(device = stm32l4xx_hal::stm32, dispatchers = [DFSDM1, DFSDM2])]
<re_irc> mod app {
<re_irc> #[shared]
<re_irc> struct Shared {}
<re_irc> #[local]
<re_irc> struct Local {}
<re_irc> #[init]
<re_irc> fn init(cx: init::Context) -> (Shared, Local, init::Monotonics) {
<re_irc> (Shared {}, Local {}, init::Monotonics())
<re_irc> }
<re_irc> #[idle]
<re_irc> fn idle(_cx: idle::Context) -> ! {
<re_irc> loop {
<re_irc> cortex_m::asm::delay(1_000_000);
<re_irc> defmt::info!("hello");
<re_irc> }
<re_irc> }
<re_irc> }
<re_irc> <@korken89:matrix.org> Using the following "defmt" deps:
<re_irc> defmt = { version = "0.3.4" }
<re_irc> defmt-rtt = "0.4.0"
<re_irc> panic-probe = { version = "0.3.1", features = ["print-defmt"] }
<re_irc> <@korken89:matrix.org> Using the following "defmt" deps:
<re_irc> cortex-m-rtic = "1"
<re_irc> cortex-m = { version = "0.7.7", features = ["critical-section-single-core"] }
<re_irc> defmt-rtt = "0.4.0"
<re_irc> defmt = { version = "0.3.4" }
<re_irc> panic-probe = { version = "0.3.1", features = ["print-defmt"] }
<re_irc> <@korken89:matrix.org> I have also tested with the "rzcobs" feature to no effect
<re_irc> <@korken89:matrix.org> Alright, running with "--json" output does not change, so it must be something internal doing the printing
<re_irc> <@korken89:matrix.org> Alright, I have found what makes it go wrong
<re_irc> <@korken89:matrix.org> The chip (STM32L431KB) has 48k + 16K ECC RAM
<re_irc> <@korken89:matrix.org> They are contigous
<re_irc> <@korken89:matrix.org> If one sets the memory.x to 64k ti break, 48k it works
<re_irc> <@korken89:matrix.org> So it's something weird when the RTT data is placed in the ECC RAM
<re_irc> <@korken89:matrix.org> I looked in the reference manual, and from what I can find one does not need to "initialize" the RAM
<re_irc> <@korken89:matrix.org> Plus "cortex-m" init 0s it without issues
<re_irc> <@korken89:matrix.org> I have not idea what's happening here πŸ˜…
<re_irc> <@korken89:matrix.org> Maybe or has run into something similar to this?
<re_irc> <@korken89:matrix.org> I have checked with a debugger now, I can read the RTT block when it's in ECC ram with openocd 🀷
<re_irc> <@adamgreig:matrix.org> You could try the new zero init feature in c-m-rt just to be sure
<re_irc> <@adamgreig:matrix.org> Sounds pretty weird...
<re_irc> <@korken89:matrix.org> Fun fact
<re_irc> <@adamgreig:matrix.org> Have you set the log level high enough for the info log to show? Maybe use defmt println
<re_irc> <@korken89:matrix.org> This app has been running correctly for 2 years
<re_irc> <@korken89:matrix.org> Yes
<re_irc> <@korken89:matrix.org> It started breaking during the last month, and the customer came and asked why logging broke
<re_irc> <@korken89:matrix.org> It's at least not the compiler, I did a bisect of compiler versions
<re_irc> <@korken89:matrix.org> (all the way back to 2 years ago)
<re_irc> <@korken89:matrix.org> Or, 1 year 7 months - but yeah
<re_irc> <@adamgreig:matrix.org> Any library version updates? There's new defmt and c-m-rt and probe-rs-cli...
<re_irc> <@korken89:matrix.org> Yeah, I tested downgrading to before the defmt format break to test
<re_irc> <@korken89:matrix.org> The error persisted
<re_irc> <@korken89:matrix.org> Yeah, I tested downgrading to before the defmt wire format break to test
<re_irc> <@korken89:matrix.org> The app only uses ~19k of RAM so I'll just reduce the size of the buffer for now :)
<re_irc> <@korken89:matrix.org> But why ECC ram? ....
<re_irc> <@korken89:matrix.org> I'm so confused
<re_irc> <@korken89:matrix.org> The app only uses ~19k of RAM so I'll just reduce the size of the RAM section for now :)
<re_irc> <@adamgreig:matrix.org> Does the length of the panic message change the behaviour?
<re_irc> <@adamgreig:matrix.org> Like try making it one, two, three, ..., seven bytes longer
<re_irc> <@korken89:matrix.org> Tested a bit, and no difference
<re_irc> <@korken89:matrix.org> I could make the RAM 49k, then the RTT block is juuuust on the right side of ECC ram
<re_irc> <@korken89:matrix.org> Fun fact, the other stuff that then is in ECC ram reads/writes correctly (practically all system state)
<re_irc> <@korken89:matrix.org> Is there some extra thing that needs doing when a debugger reads/writes ECC ram maybe?
<re_irc> <@adamgreig:matrix.org> Usually the distinction is that writes don't flush until an entire ECC word is written or a different write is made but it doesn't seem like that should be a huge issue here...
<re_irc> <@adamgreig:matrix.org> I guess maaaybe if the write to the buffer indices isn't flushed but then it should just be the old value, not an invalid one
<re_irc> <@thejpster:matrix.org> Another ping for people interested in how the Launching Pad Team is going to work to check out the Zulip thread and leave their thoughts in the HackMD that has been created: https://rust-lang.zulipchat.com/#narrow/stream/384197-t-launching-pad
<re_irc> <@juliand:fehler-in-der-matrix.de> Getting 403 on the doc
<re_irc> <@thejpster:matrix.org> For example, one of the questions is β€œHow will the launchpad representative effectively represent all of launchpad’s subteams and keep informed as to their activity and needs?”
<re_irc> <@thejpster:matrix.org> : are you signed in to HackMD? I think it’s restricted to signed in users. Maybe to WG Team members, not sure.
<re_irc> <@juliand:fehler-in-der-matrix.de> : Nope, will try that
<re_irc> <@thejpster:matrix.org> Who precisely constitutes a WG Team member is an interesting question.
<re_irc> <@yatekii:matrix.org> : not all memory is guaranteed to be readable over debug wire when the core is not stopped. Could be something like this ...
<re_irc> <@yatekii:matrix.org> * readable/writeable
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc> <@korken89:matrix.org> : Could be, I'll investigate a bit more :)
<re_irc> <@juliand:fehler-in-der-matrix.de> : : I am not yet very familiar with how the processes inside the council etc. work.
<re_irc> My current understanding is that the representative in the launching pad would be mainly communicating planned changes towards the embedded rust WG (or more general the Rust Embedded users) and communicate WG's concerns back up to the council. Is that right?
<re_irc> Who constitutes a WG Team member would be interesting to know. Isn't that fixed somehow?
<re_irc> <@thejpster:matrix.org> : Towards all of the WGs covered by the launching pad, but yes.
<re_irc> <@yatekii:matrix.org> : you can easily check by writing sth to ecc and reading it back. if it is all zeroes, its that :)
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
<re_irc> <@imdoor:ilgt.lv> hey, i'm facing an issue where my code would run on the device only right after flashing it on the board with "probe-run", but not on its own (when the board is powered off/on). in the second scenario it just stops at some fixed point in code. anyone seen something like this before?
<re_irc> some more details: i'm following the knurling sessions book, using a nrf52840 DK, i'm flashing my code using the probe-run tool. the weird thing is that the issue manifests only occasionally – after some seemingly unrelated changes in code it runs fine (with or without being connected to the pc), and after others it doesn't
sauce has quit []
sauce has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
IlPalazzo-ojiisa has quit [Remote host closed the connection]