IlPalazzo-ojiisa has quit [Remote host closed the connection]
<GrantM11235[m]>
Does anyone know why panic-probe isn't printing my panic messages? I have panic-probe = { version = "0.3.1", features = ["print-defmt"] } in my cargo toml.
<GrantM11235[m]>
I have tried the latest versions of both probe-run and probe-rs. The normal defmt output works fine, and I get a stacktrace, but the panic message is nowhere to be found
<dirbaio[m]>
do you have panic-immediate-abort in .cargo/config.toml?
<GrantM11235[m]>
nope
<dirbaio[m]>
maybe you're missing use panic_probe as _ in your main.rs... (but I think that would fail to compile?)
<GrantM11235[m]>
I have use defmt_rtt as _; and use panic_probe as _;
<dirbaio[m]>
then I'm out of ideas 🥲
<dirbaio[m]>
* perhaps you're filtering it out with DEFMT_LOG?
<dirbaio[m]>
I think the log comes from the panic-probe crate, not yours
<dirbaio[m]>
if it's not that, then I'm out of ideas 🥲
<GrantM11235[m]>
hmm, it might be a hardfault, not a panic
ello has quit [Server closed connection]
ello has joined #rust-embedded
jasperw has quit [Ping timeout: 246 seconds]
jasperw has joined #rust-embedded
<GrantM11235[m]>
is defmt/defmt-rtt supposed to work inside an interrupt?
<RobertJrdens[m]>
Just 4 instructions per sample on Skylake typically. On cortex M4 the assembly looks really clean and better than anything I can come with by hand. But I didn't benchmark it on arm yet.
<RobertJrdens[m]>
A while ago somebody was looking for a FIR filter implementation for embedded. Maybe firefrommoonlight ?
vrakaslabs[m] has quit [Quit: Idle timeout reached: 172800s]
emerent_ has joined #rust-embedded
emerent is now known as Guest2969
emerent_ is now known as emerent
Guest2969 has quit [Killed (iridium.libera.chat (Nickname regained by services))]
caemor[m] has joined #rust-embedded
<caemor[m]>
Is there a list of device crates implementing the e-h 1.0 rc?
s7rul[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
* if not low, set interrupt for falling edge, wake on interrupt
<diondokter[m]>
Hmmmm...
<JamesMunns[m]>
it's a LITTLE racy, if the pin fell RIGHT after checking, but RIGHT BEFORE the interrupt is registered, you could lose it I guess.
<JamesMunns[m]>
but tbh that time SHOULD be pretty miniscule
<diondokter[m]>
Yeah it should then work most of the time. But it always goes wrong for me
<diondokter[m]>
Ah ok, so a channel uses the edge, but the port event uses the sense mechanism for low and high. Embassy uses the port for this not the channel
<JamesMunns[m]>
ah!
<diondokter[m]>
So the racyness isn't an issue here
<JamesMunns[m]>
> Putting the system into System ON IDLE while DETECT is high will not cause DETECT to wake the system up again.
<wassasin[m]>
I think that the GPIO DETECT and GPIOTE PORT mechanism can not be used to detect 'when low' as-is; you must check it within a critical section before enabling the event in GPIOTE
<JamesMunns[m]>
yeah, I
<diondokter[m]>
wassasin[m]: If that is the case, then the embassy-nrf implementation of this has been wrong for 14+ months (last change of this feature)
<diondokter[m]>
But also, it should still work. Because the gpiote is set up before the interrupt goes low
<JamesMunns[m]>
well, the interrupt is active, but you haven't registered a waker until the first poll, but on first poll it SHOULD be able to tell if the sense line has fired
<JamesMunns[m]>
are you waiting on multiple pins?
<diondokter[m]>
No, in that task it waits on a message bus, the interrupt pin and a time ticker.
<diondokter[m]>
In other tasks I am waiting on other pins, yes
<wassasin[m]>
First the GPIOTE port event must be configured before configuring the GPIO sense
<wassasin[m]>
And then
<wassasin[m]>
> The DETECT signal will go high immediately if the SENSE condition configured in the PIN_CNF registers is met when the sense mechanism is enabled. This will trigger a PORT event if the DETECT signal was low before enabling the sense mechanism.
<wassasin[m]>
GPIOTE will then see the rising edge on DETECT and trigger the port event
<JamesMunns[m]>
yeah, the event is enabled
<JamesMunns[m]>
it's enabled like always, it seems to be done in init
<JamesMunns[m]>
then the sense is enabled, then on first poll a waker is registered, then it checks if the sense bit is cleared (because a wake occurred)
<diondokter[m]>
Ok, the sense is properly configured
<diondokter[m]>
The latch is turned on
<diondokter[m]>
* turned on after the signal goes low
<wassasin[m]>
What is the value of DETECT before and after?
<diondokter[m]>
Not sure you can read that from a register
<wassasin[m]>
Ah right, is the LATCH unset before you trigger it?
<diondokter[m]>
Yes
<JamesMunns[m]>
but yeah, my $0.02 is:
<JamesMunns[m]>
* add logs to the interrupt and PortInputFuture, see what it does
<diondokter[m]>
Yeah, I think the embassy code is correctly implemented
<diondokter[m]>
My future is actively polled way before the interrupt happends
<diondokter[m]>
s/happends/happens/
<JamesMunns[m]>
that being said, I can't tell how they ONLY wake the proper pin using the port mechanism, but the failure mode of that would be "too many wakes" not "too late wakes"
<JamesMunns[m]>
The DETECT signals are the rising/falling ones, right?
<JamesMunns[m]>
looks like port sense might not be able to wake you from deep sleep?
<diondokter[m]>
It does wake me up fine
<JamesMunns[m]>
oh, it wakes but no interrupt fires?
<diondokter[m]>
Yes, but I think that's expected
<JamesMunns[m]>
🤯
<diondokter[m]>
Well, but how should it interrupt? The CPU wakes up as if it has just powered on. So the NVIC is fully reset.
<diondokter[m]>
The problem is that if the CPU is woken up by something else, e.g. me pressing a button or the accelerometer interrupt going off, it then doesn't detect the RTC interrupt while the CPU is still on.
<diondokter[m]>
The weird thing is that the interrupt does fire much later when we're preparing to go to sleep again.
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
K900 has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
🍿
timokrgr[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
Interrupt pipes must have been a little clogged :p
<diondokter[m]>
If I don't clear, the device immediately wakes up as if the interrupt happened in the sleep
<diondokter[m]>
Hmmmm... Ok maybe it makes a little bit of sense. Embassy sets LDETECT. This means the DETECT signal is high as long as a latch bit is high. Resetting latch then causes a falling edge
<dirbaio[m]>
LDTETECT is active high, a falling edge in it doesn´t matter
<diondokter[m]>
dirbaio[m]: You sure? Because when I set it to the default my GPIOTE works!
<dirbaio[m]>
so, if you go to system off while it is already high, it immediately exits
<diondokter[m]>
That's true yeah
<diondokter[m]>
I'm looking in the docs what it says about it
<dirbaio[m]>
ahh
<dirbaio[m]>
perhaps EVENTS_PORT only gets set on DETECT rising edge though
<diondokter[m]>
That's what I'm thinking
<diondokter[m]>
Well
<dirbaio[m]>
so for exiting SYSTEM OFF it's level-triggered, but for EVENTS_PORT it's edge triggered
<dirbaio[m]>
i've run into similar weird shit before
<dirbaio[m]>
they do it so that the event is usable with PPI, so that it is not "constantly firing", it fires just once
<dirbaio[m]>
so
<diondokter[m]>
That might be it yeah
<diondokter[m]>
The docs section about the DETECT signal doesn't say anything about it
<dirbaio[m]>
if on reset, PIN_CNF is not reset (maybe only the sense bits?), but EVENTS_PORT is
<dirbaio[m]>
s/reset/system off exit/, s/PIN_CNF/PIN\_CNF/, s/EVENTS_PORT/EVENTS\_PORT/
<dirbaio[m]>
you can get in a state where DETECT is high but EVENTS_PORT is low
<diondokter[m]>
Ah yeah
<dirbaio[m]>
so it all gets stuck
<dirbaio[m]>
unless you clear DETECT
<dirbaio[m]>
s/unless/until/
<diondokter[m]>
Though I don't think that's the full picture yet. Because on init, embassy resets the latch (which I didn't know yet)
<dirbaio[m]>
perhaps resetting the latch has no effect if PINxx.DETECT is high
<dirbaio[m]>
like, if PINxx.DETECT is high and you reset the latch, LDETECT stays permanently high
<diondokter[m]>
Ah that might be true
<dirbaio[m]>
instead of going LOW for one clock cycle then back HIGH
<dirbaio[m]>
so perhaps
<diondokter[m]>
So now the question. Will embassy-nrf break if we don't use LDETECT?
<dirbaio[m]>
on boot, clear all PIN_CNF[x].SENSE bits, then clear LDETECT?
<dirbaio[m]>
iirc you need LDETECT to avoid race conditions
<diondokter[m]>
dirbaio[m]: You mean, switch off LDETECT, clear latch, turn on LDETECT?
<dirbaio[m]>
no
<dirbaio[m]>
disable all PIN_CNFx.SENSE, so that there's nothing setting the latch high anymore
<diondokter[m]>
dirbaio[m]: Oh the sense. Yeah
<dirbaio[m]>
then clear the latch
<dirbaio[m]>
that will guarantee the latch output (LDETECT) goes low
<diondokter[m]>
Whoops, did not mean to quote there
<diondokter[m]>
I can try that
<dirbaio[m]>
PIN_CNFx state is retained across system off
<dirbaio[m]>
it's cleared on power-on reset only
<dirbaio[m]>
* on power-on or pni reset only
<dirbaio[m]>
* on power-on or pin reset only
<diondokter[m]>
Yeah. At least in our code we don't need that since we're reinitializing everything always
<dirbaio[m]>
so I guess that's why this bug took too long to surface, you can only trigger it with system off
<diondokter[m]>
Yep
<diondokter[m]>
Oh lol
<diondokter[m]>
There's an even more simple solution
<diondokter[m]>
I commented out the line that resets the events port register and this seems to work too
<diondokter[m]>
In the init
<dirbaio[m]>
ahh that's retained too?
<dirbaio[m]>
or perhaps not retained but it gets triggered immediately at boot before, gpiote init
<diondokter[m]>
So my guess is that it was being set, but before we enabled the interrupt already reset it
<dirbaio[m]>
makes a lot of sense
<diondokter[m]>
That's a lot less cursed
<dirbaio[m]>
yeah
<dirbaio[m]>
nice!
<diondokter[m]>
Oh man
<diondokter[m]>
Finally!
<JamesMunns[m]>
Congrats on solving the murder mystery :)
<diondokter[m]>
I've been hunting this bug for like 4 weeks :P (well, on tuesdays and thursdays)
<diondokter[m]>
When all you can see is 'device doesn't wake up from sleep sometimes' it's very hard to find
<JamesMunns[m]>
I have a few things that basically make me double the estimates for anything, and "very low power sleep required" is one of them :p
<diondokter[m]>
Anyways, PR is inbound
Abhishek_ has quit [Ping timeout: 240 seconds]
<JamesMunns[m]>
* how to make the thing ACTUALLY sleep and shut everything you want off
<JamesMunns[m]>
it's always either:
<JamesMunns[m]>
* how to make the thing ACTUALLY wake back up and act normal afterwards
<diondokter[m]>
Gives me a reason to update more of our drivers to EH 1.0 RC
diagprov has quit [Ping timeout: 246 seconds]
stephe has quit [Ping timeout: 246 seconds]
seds has quit [Ping timeout: 246 seconds]
edm has quit [Read error: Connection reset by peer]
SanchayanMaity has quit [Read error: Connection reset by peer]
nohit has quit [Read error: Connection reset by peer]
NishanthMenon has quit [Ping timeout: 258 seconds]
dnm has quit [Ping timeout: 245 seconds]
<JamesMunns[m]>
Just double checking, does it all work just as well if you do a clean boot with NO debugger attached?
seds has joined #rust-embedded
<JamesMunns[m]>
(just because "attached debugger" tends to change a ton of deep sleep behaviors as well, wanted to make sure the mystery didn't continue)
<diondokter[m]>
<diondokter[m]> "Good point!" <- Yep, can't seem to break it now where I could break it very reliably before
loki_val has joined #rust-embedded
<JamesMunns[m]>
as in, "it works totally fine with no debugger, even without the changes from today"?
crabbedhaloablut has quit [Read error: Connection reset by peer]
<diondokter[m]>
I only really added logging today and turned off the modem. So it should. I'm definitely gonna test it with the full test, but that takes like 2 days before it maybe breaks
brazuca has quit [Quit: Client closed]
jessebraham[m] has joined #rust-embedded
<jessebraham[m]>
Just FYI, I was going to update the svd2rust CI to check some more of our SVDs, but it looks like the Nordic 1.65.0 job is failing due to an MSRV issue
<jessebraham[m]>
Happy to fix it along with my changes if you would like, but just don't want to make the call on what to do about that job haha
sirhcel[m] has quit [Quit: Idle timeout reached: 172800s]
ni has quit [Ping timeout: 246 seconds]
ni has joined #rust-embedded
brazuca has joined #rust-embedded
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
e.g. an existing crate like embedded-sdmmc would also be async. I'm a bit lost here, so where to start?
<sourcebox[m]>
I'm trying to figure out how to deal with SD cards and eMMC flash from the application side. My HAL will provide functions for reading and writing blocks of 512 bytes, that's the low-level part. But on top of that, there has to be code to manage partitions (at least for the SD cards) and file systems (FAT32). And it should be non-blocking, so async is probably the way to go. In my HAL, I can make the block transfers async, but
<sourcebox[m]>
* I'm trying to figure out how to deal with SD cards and eMMC flash from the application side. My HAL will provide functions for reading and writing blocks of 512 bytes, that's the low-level part. But on top of that, there has to be code to manage partitions (at least for the SD cards) and file systems (FAT32). And it should be non-blocking, so async is probably the way to go. In my HAL, I can make the block transfers async, but
<sourcebox[m]>
e.g. an existing crate like embedded-sdmmc would also need to be async. I'm a bit lost here, so where to start?
<sourcebox[m]>
Btw. the solution in C would be FatFs running in a low-priority FreeRTOS task. This is something I've done before and it's working.
<sourcebox[m]>
Seems to be quite new, maybe that's the reason I did not stumble upon it. Not sure about the partition handling. That's required because the SoC can boot from SD card.
<sourcebox[m]>
But maybe mabez can give some info about that.
mabez[m] has joined #rust-embedded
<mabez[m]>
The device module gives you a SliceStream which can be used to access partitions. You'll need to parse the MBR to find partition offsets yourself though
<mabez[m]>
There is an MBR parsing crate for no_std though
<mabez[m]>
I'll add a full no_std example at some point, I just haven't got around to doing it yet
<sourcebox[m]>
Ok, thanks. I have to dig deeper into the details how this works. eMMC seems to have 2 special boot partitions, so it's a bit different than an SD card.
<mabez[m]>
What chip are you using, and which transport method, SPI or SDIO?
<sourcebox[m]>
Unfortunately, for eMMC, I also have to write the partition data because the flash is initially empty when the device is booted for the first time.
<sourcebox[m]>
That's an STM32MP1 with the SDMMC peripheral.
<mabez[m]>
Haven't heard of the MP1, but is it supported by the sdmmc driver in embassy-stm32?
<sourcebox[m]>
No, that's a Cortex-A7 dual-core SoC.
<sourcebox[m]>
I have to write a HAL for it myself.
<sourcebox[m]>
This chip does not really fit into the common STM32 MCU lines.
<mabez[m]>
Gotcha, well the device feature of embedded-fatfs should be what you need for partitions/block device helpers, when you get to that point
<sourcebox[m]>
It's not urgent right now because I'm still at the point where I upload the code via JTAG. I just want to have some possible solution in mind.
<sourcebox[m]>
I also hope that it gets to the point where nightly is not required anymore.
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
loki_val has quit []
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
fuse117[m] has quit [Quit: Idle timeout reached: 172800s]
codec_abc[m] has quit [Quit: Idle timeout reached: 172800s]
Rahix has quit [Ping timeout: 245 seconds]
Rahix has joined #rust-embedded
PhilMarkgraf[m] has quit [Quit: Idle timeout reached: 172800s]