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
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?
<dirbaio[m]> yep
<GrantM11235[m]> Based on the stacktrace, it looks like I am hitting this panic https://github.com/knurling-rs/defmt/blob/82882c8b5ddfb58784e3275e70a6e3f270074885/firmware/defmt-rtt/src/lib.rs#L58
<dirbaio[m]> defmt-rtt takes the CS while printing
<dirbaio[m]> so an interrupt cannot happen while printing, which should avoid reentrant printing
<dirbaio[m]> if you're hitting that, something's very wrong 😅
starblue has quit [Ping timeout: 245 seconds]
<dirbaio[m]> it could happen if you try to print from a defmt::Format impl
<dirbaio[m]> or if you hardfault while printing and the hardfault handler tries to print
starblue has joined #rust-embedded
brazuca has quit [Quit: Client closed]
<GrantM11235[m]> I haven't set a hardfault handler, does the default handler do that?
<dirbaio[m]> no
<dirbaio[m]> maybe you're using rp2040 multicore with the singlecore CS impl?
<GrantM11235[m]> Nope, singlecore stm32f103 with the cortex-m single core CS impl
<dirbaio[m]> now i'm really out of ideas lol
Foxyloxy has joined #rust-embedded
<JamesMunns[m]> panics can happen re-entrantly
<JamesMunns[m]> it's possible you are panicking WHILE panicking
<JamesMunns[m]> "double panic aborts" is *only* true in panic-unwind
<JamesMunns[m]> This would be surprising if you are using panic-probe, though
<JamesMunns[m]> Ah, panic-probe does guard against this: https://docs.rs/panic-probe/latest/src/panic_probe/lib.rs.html#41-55
<JamesMunns[m]> hmm, that is using cortex_m::interrupt::disable(); rather than the critical section crate, not sure if that is meaningful
crabbedhaloablut has joined #rust-embedded
<GrantM11235[m]> I don't think that makes a difference in my case since I am using critical-section-single-core
<GrantM11235[m]> I might have some UB somewhere, I am messing around with DMA
<GrantM11235[m]> Yup, I was accidentally dma-ing 8kb of data into a 256 byte buffer 😬
<JamesMunns[m]> So much Bonus Data!
<JamesMunns[m]> Can't imagine why that made the MCU so upset.
Darius has quit [Ping timeout: 255 seconds]
Darius has joined #rust-embedded
RobertJrdens[m] has joined #rust-embedded
<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]
diondokter[m] has joined #rust-embedded
<diondokter[m]> <caemor[m]> "Is there a list of device crates..." <- Of the drivers under my care it's:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/pzDFaAYHzAtVqeEqLFqAppMW>)
IlPalazzo-ojiisa has joined #rust-embedded
<diondokter[m]> Hey all I'm running into a weird issue on the nRF91 and GPIOTE.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/dwzuURgPxultihDnQIumnafs>)
<JamesMunns[m]> is it possibly "you need to poll the future once to register the event"? something like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/EOynUfcRJIlngjBPxpYHxten>)
<JamesMunns[m]> not sure how embassy's GPIOs work specifically, and if they do anything to pre-register where this wouldn't be a problem
<diondokter[m]> Well waiting is a waiting for low, not for the edge. So once the gpiote senses the low, it should go off
<JamesMunns[m]> gpiote listens for edges
<JamesMunns[m]> but maybe embassy checks for low in sw
<diondokter[m]> The waiting is also done in a separate task in a select with 2 other things. Those two things are running just fine
<diondokter[m]> You sure? I thought it was the opposite. Embassy definitely does the edge detection in software
<JamesMunns[m]> "wait for low" does:
<JamesMunns[m]> * if low, return now
<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.
<JamesMunns[m]> hm
wassasin[m] has joined #rust-embedded
<wassasin[m]> GPIOTE triggers the event on a rising edge of the detect signal though
<diondokter[m]> Maybe I should manually check what the sense register is set to
<JamesMunns[m]> The code does seem to enable port interrupts (always), so the event should fire
<diondokter[m]> Green works, but red doesn't
<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
<JamesMunns[m]> * ask dirbaio
<JamesMunns[m]> It SEEMS like it shouldn't be racy:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/nbOPEtKSNcWxKiTRJbfAgYZZ>)
<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]> (on ANY port event, it looks like ALL sense fields are cleared)
<wassasin[m]> No only those that are latched
<diondokter[m]> In the GPIOTE interrupt, embassy-nrf looks at the latch bits to determine which pin it was
<JamesMunns[m]> ah, maybe that BitIter thing only iterates over the high bits?
<diondokter[m]> But the entire interrupt doesn't go off (I have a log in there)
<JamesMunns[m]> wait the gpiote interrupt doesn't fire at all?
<diondokter[m]> No
<diondokter[m]> Only later
<JamesMunns[m]> well that seems bad!
<diondokter[m]> Yeah :P
<diondokter[m]> If I manually pend the interrupt, it does fire, but doesn't see that a port event has occured
<diondokter[m]> Is there a feature in nRF to turn on and off peripheral events?
<JamesMunns[m]> wait does gpiote::init ever get called?
<diondokter[m]> Yeah, in the init of the hal itself
<wassasin[m]> What is the value of gpiote::events_port before you do the test?
<diondokter[m]> wassasin[m]: I'll check that
<wassasin[m]> Intenclr is never written to for port
<wassasin[m]> AFAIC
<wassasin[m]> * AFAIK
<JamesMunns[m]> hmm, that shouldn't be the case tho, you do always set it as an input before you set sense
<diondokter[m]> Yeah and the latch is as expected as far as I can see from my logs
<diondokter[m]> events_port continuously reads out as 0 (outside of the gpiote interrupt)
<wassasin[m]> I don't understand why the interrupt handler writes the bit back into the register
<wassasin[m]> It is not a 'write 1 to clear'-type of register
<JamesMunns[m]> it seems to treat it that way
<wassasin[m]> You needn't reset the value either as the GPIOTE sets the value specifically for the interrupt
<diondokter[m]> It is a Read Write register though
<wassasin[m]> Yeah, you must set it to '0' prior to using the GPIOTE
<wassasin[m]> Oh right, write sets it to 0
<JamesMunns[m]> yeah
<JamesMunns[m]> datasheet shows writing back the bit clears the field
<wassasin[m]> For LATCH yes, but not for EVENTS_PORT
<JamesMunns[m]> aren't all event registers "write back to clear"?
<wassasin[m]> Unfortunately not
<JamesMunns[m]> what
<diondokter[m]> Then how does it clear? Does the hardware do that?
<JamesMunns[m]> > (write '0' to EVENTS_PORT)
<diondokter[m]> JamesMunns[m]: Yeah, that's what embassy does
<JamesMunns[m]> ah
<JamesMunns[m]> g.events_port.write(|w| w);
<JamesMunns[m]> that writes the RESET value (0), not the CURRENT value
<diondokter[m]> Yep
<diondokter[m]> Looks confusing, but yes
<wassasin[m]> This is not done at all for events_in
<JamesMunns[m]> idk, gotta run, good luck!
<diondokter[m]> JamesMunns[m]: Thanks for the help so far!
<diondokter[m]> Huh... If I don't put the chip in system off mode, then the GPIOTE works as expected
<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]
brazuca has joined #rust-embedded
<firefrommoonligh> <RobertJrdens[m]> "A while ago somebody was looking..." <- > <@jordens:matrix.org> A while ago somebody was looking for a FIR filter implementation for embedded. Maybe firefrommoonlight ?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/MTYTjJhzEgfcuSkrzMbxQqNX>)
limpkin has joined #rust-embedded
<diondokter[m]> WTF
<diondokter[m]> So the GPIOTE firing? That happens after I clear the latch register just before I go to system off
<diondokter[m]> How does that work!?
<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]> uhhhhhh
<dirbaio[m]> iiuc DETECT is active high
<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)
Abhishek_ has joined #rust-embedded
diagprov has joined #rust-embedded
nohit has joined #rust-embedded
diagprov has joined #rust-embedded
diagprov has quit [Changing host]
stephe has joined #rust-embedded
edm has joined #rust-embedded
NishanthMenon has joined #rust-embedded
<diondokter[m]> JamesMunns[m]: > <@jamesmunns:beeper.com> it's always either:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/cmOpBeBeiyGKIFLgwFrlIDpK>)
<diondokter[m]> JamesMunns[m]: Good point!
SanchayanMaity has joined #rust-embedded
dnm has joined #rust-embedded
<JamesMunns[m]> diondokter[m]: > <@diondokter:matrix.org> Haha yep it's hard.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/rsApLOPkdEzwxQDslIGPjhWw>)
<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
<jessebraham[m]> Failing run:
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.
<jessebraham[m]> https://github.com/MabezDev/embedded-fatfs might work?
<sourcebox[m]> Ok, I'll have a look.
<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]
brazuca has quit [Quit: Client closed]
Foxyloxy has quit [Ping timeout: 252 seconds]
Rahix has quit [Quit: ZNC - https://znc.in]
hmw- has joined #rust-embedded
hmw has quit [Ping timeout: 240 seconds]
sknebel has quit [Ping timeout: 240 seconds]
sknebel has joined #rust-embedded
Rahix has joined #rust-embedded
ilpalazzo-ojiis4 has quit [Server closed connection]
ilpalazzo-ojiis4 has joined #rust-embedded