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
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
sroemer has quit [Ping timeout: 265 seconds]
cbjamo[m] has quit [Quit: Idle timeout reached: 172800s]
sroemer has joined #rust-embedded
sroemer has joined #rust-embedded
richardeoin has quit [Quit: WeeChat 2.8]
richardeoin has joined #rust-embedded
sroemer has quit [Ping timeout: 252 seconds]
ryan-summers[m] has quit [Quit: Idle timeout reached: 172800s]
LeandroMarceddu[ has joined #rust-embedded
<LeandroMarceddu[> I'm a bit confused about how QSPI, flash storage and STM32F446 work together. There's 512kbyte on-board with the 446 that I have (ZET). If I connect the flash storage to the QSPI, will it consider it's total storage as 512Kbyte + storage or does it need to be explicitly told? Will it just start filling from the 512Kbyte and up (because the firmware is larger)? These are all hypothetical and I'm still very much considering and
<LeandroMarceddu[> learning things
pcs38 has joined #rust-embedded
richardeoin has quit [Quit: WeeChat 2.8]
pcs38 has quit [Quit: leaving]
sroemer has joined #rust-embedded
rafael[m] has joined #rust-embedded
<rafael[m]> Hi, is there advice what to look for, if a firmware works well when debugging but hangs when started by just powering? It must be a timing issue, but can just using some defmt::info throw this so off?
<Lumpio-> Are you using blocking mode RTT
<rafael[m]> i think so, yes
<rafael[m]> oh... right - so the delays are going to be as long as it takes to get the info!("whatever") out to me and that way i have maybe a longer delay than i thought everywhere?
<Lumpio-> I can't remember the implementation in defmt exactly but blocking mode might block indefinitely if there is no debugger reading the output
<Lumpio-> This is why there's a non-blocking mode, and I think there might've been a feature that enables blocking on the fly via the debugger only when requested
<rafael[m]> hm okay so far i never had to disable debug messages when running detached, but that is an easy test, let me see.
<rafael[m]> no luck, all info! commented out, works when flashing through the debug probe, does not work when just powering up. compiling in debug or release mode also changes nothing. So, going to have a look at all places with info! and consider a small delay there. The offending hardware is a DFPlayer mini, these have a reputation of being difficult that way.
starblue[m] has quit [Quit: Idle timeout reached: 172800s]
EricSeppanen[m] has joined #rust-embedded
<EricSeppanen[m]> Apologies for the offtopic post, but I'm working on a project for RustWeek in the Netherlands, and I need to find a vendor that can laser-cut 1-2mm steel sheets. If anyone can recommend a service that can ship to the Netherlands, I'd appreciate any recommendations. I've checked with Xometry.eu (quite expensive) and SendCutSend (good price, but USA only), but hoping I can find some place better.
<EricSeppanen[m]> I hoped there would be some overlap between "people who do bare-metal embedded systems" and "people who know where to get physical stuff manufactured"... thanks for any help!
pcs38 has joined #rust-embedded
richardeoin has joined #rust-embedded
<whitequark[cis]> <EricSeppanen[m]> "Apologies for the offtopic post,..." <- laser cutting services are quite prevalent, i don't know netherlands specifically but since the capital investment is so small lots of tiny shops do it
<whitequark[cis]> i would look for shops that work with advertising (like, physical advertising, signs and stuff) since these will have a relatively high volume of orders and are usually a bit cheaper
<whitequark[cis]> they also do acrylic cutting and bending if you need that
pcs38 has quit [Read error: Connection reset by peer]
<whitequark[cis]> although on a quick search, it looks like the small shops in NL don't do metal
wassasin[m] has joined #rust-embedded
<wassasin[m]> Eric Seppanen: I know a few local companies in Nijmegen that do it. In my town: https://quickprint.nl/metaal-lasersnijden/
<wassasin[m]> Up to 10mm stainless
pcs38 has joined #rust-embedded
<wassasin[m]> I would not recommend importing any steel from outside the EU. Customs are actively monitoring for it due to Russia sanctions. Getting stencils from JLCPCB is a pain
<wassasin[m]> Unrelated: JLCPCB rep told me they will have blind/buried vias next month, and rigid-flex the month after that
diondokter[m] has joined #rust-embedded
<diondokter[m]> <EricSeppanen[m]> "Apologies for the offtopic post,..." <- > <@ericseppanen:matrix.org> Apologies for the offtopic post, but I'm working on a project for RustWeek in the Netherlands, and I need to find a vendor that can laser-... (full message at
<JamesMunns[m]> <Lumpio-> "I can't remember the implementat..." <- iirc `defmt-rtt` starts in "overwrite" mode and expects the debugger to overwrite "block if full" by default
<JamesMunns[m]> The first one is pretty common, usually if you have external i2c or spi devices, check the datasheet, they often say stuff like "don't try to talk to the device for 5-100ms after powered on" or something
<JamesMunns[m]> Some googling says the chip might take a few seconds to boot up, if you're blocking or awaiting a response without a timeout, it might appear to hang
<rafael[m]> James Munns thx! Will have a look at all these hints later tonight. I power the dfplayer via mosfet switch, so it should have the same time to power up either way, but ... the time the controller has power is different still. So maybe that is a lead.
<wassasin[m]> rafael: you power it via p-channel mosfet?
<wassasin[m]> * p-channel mosfet? And with a debugger it works? Try adding a small delay between program start and switching the mosfet. The mosfet resistance might be low enough that the capacitance of the DFrobot brownouts your MCU when booting
<rafael[m]> it is a N-Channel (IRLZ44N), and i happenbed to have one delay there already, but thanks for the hint 🙂 The power draw does not look off, power up, first plateau is mostly delays and some prep, then the next increase is the switching on of the dfplayer, the spike thereafter is the command to read the sd-card of the dfplayer to count tracks. Then the long plateau is 5 times timing out on retry of that, then the fall back down is
<rafael[m]> giving up and switching off the dfplayer.
<rafael[m]> s/happenbed/happened/
<rafael[m]> i will give the thing yet more time and if that does not work i will dig out a ssd1306 and send the debug messages there so i can see what is going on. 🙂
<wassasin[m]> Ah you switch GND for the DFrobot?
<wassasin[m]> Take care to only change the GPIOs from Hi-Z to something else after the Nfet power has turned on
<rafael[m]> <wassasin[m]> "Ah you switch GND for the..." <- Yes
<rafael[m]> <wassasin[m]> "Take care to only change the..." <- That is will look into
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has quit [Quit: leaving]
<EricSeppanen[m]> <diondokter[m]> "> <@ericseppanen:matrix.org..." <- I tried to get a quote from them but they require an EU company name to get a quote. If you have another way of getting a quote from them, I could send an email with the cad file.
spikespaz[m] has quit [Quit: Idle timeout reached: 172800s]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
ana_briated has joined #rust-embedded