<JamesMunns[m]>
The target sections ARE joined together on multiple matches, but build is only taken if there are no matching target sections
cr1901 has quit [Ping timeout: 245 seconds]
cr1901 has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 256 seconds]
cr1901_ is now known as cr1901
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
<DanielakaCyReVol>
<JamesMunns[m]> "The target sections ARE joined..." <- ah, that's a gotcha, heh - thank you!
<DanielakaCyReVol>
I was really struggling to find this in the docs...
<DanielakaCyReVol>
Now I wonder why I hadn't found it. 🤔
<DanielakaCyReVol>
to narrow it down, I have set up another project with minimal footprint, and kept adding the same bits... and nothing ever caused the same problem - until I thought: "no way, it can't be because of the other rustflags in the config.toml...?!" - and that was it 😅
<DanielakaCyReVol>
reminds me a bit of something I once had with Docker
<DanielakaCyReVol>
there were two options with mutual implications, but documented far apart from each other - one was referencing the other, but not vice versa, so I added that back reference, my first and only contribution to that ever (so far)
<DanielakaCyReVol>
sooo... I am thinking if I could add something to the Rust docs
<DanielakaCyReVol>
gotta go back mentally to recap what I did when I tried to figure this stuff out
<DanielakaCyReVol>
my searches mostly led me to the features section in Cargo.toml, that I recall... it was hard to get to the --cfg stuff already
<DanielakaCyReVol>
ah, we could add that to the section on features 💡
<DanielakaCyReVol>
sorry for thinking out loud, over and out 🤐 - and thank you again :)
iamzim has joined #rust-embedded
cr1901 has quit [Ping timeout: 256 seconds]
luojia65[m] has joined #rust-embedded
<luojia65[m]>
I've updated k210-hal code to support embedded-hal 1.0.0 and embedded-io 0.6.1
<luojia65[m]>
Is it possible to release a new k210-hal version? :) disasm
Guest7282 has quit [Ping timeout: 264 seconds]
cr1901 has joined #rust-embedded
iamzim has left #rust-embedded [#rust-embedded]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
notgull has joined #rust-embedded
notgull has quit [Ping timeout: 256 seconds]
pbsds has quit [*.net *.split]
tafa has quit [*.net *.split]
NishanthMenon has quit [*.net *.split]
diagprov has quit [*.net *.split]
M9names[m] has quit [*.net *.split]
JomerDev[m] has quit [*.net *.split]
ryan-summers[m] has quit [*.net *.split]
K900 has quit [*.net *.split]
mightypork has quit [*.net *.split]
ni has quit [*.net *.split]
jasperw has quit [*.net *.split]
innegatives_ has quit [*.net *.split]
DanielakaCyReVol has quit [*.net *.split]
mpiechotka[m] has quit [*.net *.split]
Foxyloxy_ has quit [*.net *.split]
vancz has quit [*.net *.split]
Ekho has quit [*.net *.split]
AdamHott[m] has quit [*.net *.split]
dreamcat4 has quit [*.net *.split]
barnabyw[m] has quit [*.net *.split]
ello has quit [*.net *.split]
bpye has quit [*.net *.split]
luojia65[m] has quit [*.net *.split]
Shell has quit [*.net *.split]
andodeki2[m] has quit [*.net *.split]
dne has quit [*.net *.split]
thejpster[m] has quit [*.net *.split]
JamesMunns[m] has quit [*.net *.split]
sigmaris has quit [*.net *.split]
nadja has quit [*.net *.split]
mathu has quit [*.net *.split]
Socke has quit [*.net *.split]
WSalmon has quit [*.net *.split]
fooker has quit [*.net *.split]
exark has quit [*.net *.split]
crabbedhaloablut has quit [*.net *.split]
jr-oss has quit [*.net *.split]
markov_twain has quit [*.net *.split]
sknebel has quit [*.net *.split]
Ralph[m] has quit [*.net *.split]
dirbaio[m] has quit [*.net *.split]
adamgreig[m] has quit [*.net *.split]
inara has quit [*.net *.split]
whitequark[cis] has quit [*.net *.split]
cyrozap has quit [*.net *.split]
stephe has quit [*.net *.split]
ragarnoy[m] has quit [*.net *.split]
leonardvdj[m] has quit [*.net *.split]
kenny has quit [*.net *.split]
agg has quit [*.net *.split]
xnor has quit [*.net *.split]
edm has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
jsolano has quit [*.net *.split]
Abhishek_ has quit [*.net *.split]
cr1901 has quit [*.net *.split]
nohit has quit [*.net *.split]
GrantM11235[m] has quit [*.net *.split]
Rahix has quit [*.net *.split]
seds has quit [*.net *.split]
Darius has quit [*.net *.split]
thomas25 has quit [*.net *.split]
HumanG33k has quit [*.net *.split]
JamesSizeland[m] has quit [*.net *.split]
therealprof[m] has quit [*.net *.split]
JorgeMuoz[m] has quit [*.net *.split]
diondokter[m] has quit [*.net *.split]
firefrommoonligh has quit [*.net *.split]
Lumpio[m] has quit [*.net *.split]
sauce has quit [*.net *.split]
wose has quit [*.net *.split]
mabez[m] has quit [*.net *.split]
eldruin[m] has quit [*.net *.split]
StephenD[m] has quit [*.net *.split]
holo[m] has quit [*.net *.split]
dnm has quit [*.net *.split]
corecode has quit [*.net *.split]
hmw has quit [*.net *.split]
rtyler has quit [*.net *.split]
limpkin has quit [*.net *.split]
zagura has quit [*.net *.split]
dav1d has quit [*.net *.split]
emerent has quit [*.net *.split]
sirhcel[m] has quit [*.net *.split]
danielb[m] has quit [*.net *.split]
jannic[m] has quit [*.net *.split]
sjm42[m] has quit [*.net *.split]
Farooq has quit [*.net *.split]
stgl has quit [*.net *.split]
yourarj[m] has quit [*.net *.split]
_catircservices has quit [*.net *.split]
GenTooMan has quit [*.net *.split]
Lumpio- has quit [*.net *.split]
cr1901 has joined #rust-embedded
tafa has joined #rust-embedded
luojia65[m] has joined #rust-embedded
emerent has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
DanielakaCyReVol has joined #rust-embedded
sirhcel[m] has joined #rust-embedded
mabez[m] has joined #rust-embedded
Farooq has joined #rust-embedded
jr-oss has joined #rust-embedded
exark has joined #rust-embedded
danielb[m] has joined #rust-embedded
jannic[m] has joined #rust-embedded
eldruin[m] has joined #rust-embedded
GrantM11235[m] has joined #rust-embedded
StephenD[m] has joined #rust-embedded
sjm42[m] has joined #rust-embedded
Shell has joined #rust-embedded
mpiechotka[m] has joined #rust-embedded
Socke has joined #rust-embedded
WSalmon has joined #rust-embedded
andodeki2[m] has joined #rust-embedded
JamesSizeland[m] has joined #rust-embedded
JomerDev[m] has joined #rust-embedded
JorgeMuoz[m] has joined #rust-embedded
dne has joined #rust-embedded
therealprof[m] has joined #rust-embedded
yourarj[m] has joined #rust-embedded
ryan-summers[m] has joined #rust-embedded
HumanG33k has joined #rust-embedded
diondokter[m] has joined #rust-embedded
firefrommoonligh has joined #rust-embedded
dirbaio[m] has joined #rust-embedded
Foxyloxy_ has joined #rust-embedded
thejpster[m] has joined #rust-embedded
adamgreig[m] has joined #rust-embedded
Lumpio[m] has joined #rust-embedded
vancz has joined #rust-embedded
markov_twain has joined #rust-embedded
kenny has joined #rust-embedded
stgl has joined #rust-embedded
agg has joined #rust-embedded
whitequark[cis] has joined #rust-embedded
Ekho has joined #rust-embedded
fooker has joined #rust-embedded
holo[m] has joined #rust-embedded
AdamHott[m] has joined #rust-embedded
K900 has joined #rust-embedded
barnabyw[m] has joined #rust-embedded
mightypork has joined #rust-embedded
Rahix has joined #rust-embedded
inara has joined #rust-embedded
JamesMunns[m] has joined #rust-embedded
dreamcat4 has joined #rust-embedded
dnm has joined #rust-embedded
jsolano has joined #rust-embedded
_catircservices has joined #rust-embedded
seds has joined #rust-embedded
nohit has joined #rust-embedded
ni has joined #rust-embedded
cyrozap has joined #rust-embedded
xnor has joined #rust-embedded
edm has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
GenTooMan has joined #rust-embedded
sigmaris has joined #rust-embedded
jasperw has joined #rust-embedded
nadja has joined #rust-embedded
Darius has joined #rust-embedded
innegatives_ has joined #rust-embedded
sknebel has joined #rust-embedded
ello has joined #rust-embedded
mathu has joined #rust-embedded
bpye has joined #rust-embedded
thomas25 has joined #rust-embedded
Lumpio- has joined #rust-embedded
Abhishek_ has joined #rust-embedded
stephe has joined #rust-embedded
wose has joined #rust-embedded
corecode has joined #rust-embedded
sauce has joined #rust-embedded
diagprov has joined #rust-embedded
NishanthMenon has joined #rust-embedded
pbsds has joined #rust-embedded
M9names[m] has joined #rust-embedded
Ralph[m] has joined #rust-embedded
leonardvdj[m] has joined #rust-embedded
ragarnoy[m] has joined #rust-embedded
m5zs7k has quit [Max SendQ exceeded]
zagura has joined #rust-embedded
limpkin has joined #rust-embedded
rtyler has joined #rust-embedded
dav1d has joined #rust-embedded
hmw has joined #rust-embedded
m5zs7k_ has joined #rust-embedded
m5zs7k_ is now known as m5zs7k
Guest7282 has joined #rust-embedded
Mathy[m] has joined #rust-embedded
<Mathy[m]>
Hi folks, I'm attempting to run a ST7789V display over SPI on esp32 using esp-hal and mipidsi crates. It works, but redrawing is very slow, you can see the scanline travel down the screen during a second kind of slow. It looks to me like DMA might not be working properly but I figured I'd ask here if somebody has experience with a similar setup / sample code I could have a look at before diving off the deep end.
<Mathy[m]>
Mathy[m]: Ping almindor as you seem to be the creator of the mipidsi package 😬
<therealprof[m]>
<Mathy[m]> "Hi folks, I'm attempting to..." <- You might want to check out #rust-embedded-graphics:matrix.org and also scroll up a couple of pages. For some reason ESP32 seems to be really a hot topics in recent weeks...
<Mathy[m]>
Thanks, I came across to references to that room but failed to find it in the room finder so I figured it was discontinued or something :-)
marcedal has joined #rust-embedded
<eldruin[m]>
<hadez> "Does anyone have any examples of..." <- > <@hadez:matrix.gorge.works> Does anyone have any examples of returning an `Err()` for the embedded hal i2c module? I'm working on porting some older sensor drivers I wrote awhile ago and I had manually implemented error enums for i2c. Still trying to wrap my head... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/YFoDzUbVmZXvzYjMoAsdHvmv>)
sympatron[m] has joined #rust-embedded
<sympatron[m]>
What kind of SpiDevice from embedded-hal-bus is the best for sharing between tasks of different priority. I think RefCellDevice would not work, because it is not Send. Is this correct? CriticalSectionDevice is quite drastic, because RTIC would lock much more granular.
<sympatron[m]>
* What kind of SpiDevice from embedded-hal-bus is the best for sharing between tasks of different priority? I think RefCellDevice would not work, because it is not Send. Is this correct? CriticalSectionDevice is quite drastic, because RTIC would lock much more granular.
jake_001[m] has joined #rust-embedded
<jake_001[m]>
<eldruin[m]> "> <@hadez:matrix.gorge.works..." <- Thanks! Figured out the issue after reading through their impl blocks.
<jake_001[m]>
I'm calling it a night for now.
<Mathy[m]>
<Mathy[m]> "Ping almindor as you seem to..." <- Solved
yourarj[m] has quit [Quit: Idle timeout reached: 172800s]
ryan-summers[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has left #rust-embedded [Error from remote client]
<Ralph[m]>
i'm afraid of touching that as it seems to be _very_ tailored to the current ms-based implementation and seems to be very fine-tuned. so probably the same would have to be done again for the new ns-based delay?
<Ralph[m]>
just dropping this here as i haven't seen an open PR or an open issue for it yet and there's also no alpha/RC based implementation around already.
<Ralph[m]>
tbh, i yet have to write any async code 😬. so i'm still not sure what the current best practices are for drivers regarding async: write two drivers, one being async? write only an async driver? write an async driver based on the sync one? ship both in the same crate or separate (and if separate: why)?
<diondokter[m]>
TBH, with async now stable, embassy being async and rtic also being async, I see no reason why not to make drivers (and applications) async
<diondokter[m]>
Any async code you can make blocking if you want. Not the other way around. And blocking code can still pretend to be async (though that would lead to bad performance in general, but might be acceptable in specific situations)
<JamesMunns[m]>
This uses an extension trait for Reasons, but could be the same with a struct instead of an extension trait.
<firefrommoonligh>
<Ralph[m]> "> <@diondokter:matrix.org> Why..." <- > <@rursprung:matrix.org> cool! i just read the header of your `lib.rs` and saw that it claims to implement the `accelerometer` traits but it doesn't implement them anymore. was this intentional?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/dNaVzMxAMEjQPOIdVxpVBdzh>)
<firefrommoonligh>
* I do a lot of work with accelerometers. Most of the code is device-specific config. The parts that are general to most accels is "Start an SPI DMA transfer of 13 bytes with the first byte being the first data register address"
<Ralph[m]>
so you'd suggest that something like [`tb6612fng-rs`](https://github.com/rursprung/tb6612fng-rs/) should be `async`? even though i'd expect a motor controller to react immediately and not whenever it pleases it to do so?
<firefrommoonligh>
There is a lot of standardization around pinout and that read API, but the config tends to vary significantly
<JamesMunns[m]>
Ralph[m]: Not sure, is that "immediately set gpio, no 'behavior over time'"?
<JamesMunns[m]>
Or is that something like "step pulses at some frequency over 2 seconds" or something?
<firefrommoonligh>
*You may be able to abstract the read interpretation post-SPI transfer
<firefrommoonligh>
I guess, this seems like a case where the cononical use case wouldn't work for it
<firefrommoonligh>
*Oh another thing that could be abstracted is post-read software filters, like with the idsp crate or w/e
<Ralph[m]>
JamesMunns[m]: the former, i'd say. again: i've never used `async`, so i'm not 100% familiar with its behaviour with `await`, so maybe my understanding is completely wrong here
<diondokter[m]>
Ralph[m]: Yeah. And also note that 'async' does not mean 'deferred'. So it can still immediately react.
<diondokter[m]>
In fact, with async it would be possible to make like nice software-defined acceleration and deceleration without blocking other code forever or doing annoying interrupt stuff
<firefrommoonligh>
The toughest part is step 1 because there can be a lot of things to tweak!
<JamesMunns[m]>
Ralph[m]: Yeah, if you aren't ever blocking with timer delays or sending data over an interface, that might take some time (like the time to send out a byte at 9600 baud/100khz/1MHz/16MHz, then there's probably no need for async.
<JamesMunns[m]>
Like, if you JUST use `Digital` pins and no timer, there's not even async traits for that
<JamesMunns[m]>
but for accelerometers/adcs/motor controllers that send/receive data over SPI or I2C, especially on a shared bus where you might have to wait for the current transaction to finish, async can help a lot there.
<firefrommoonligh>
Agree on not blocking for the data read
<firefrommoonligh>
Especially if you're running an 8khz read cycle or w/e, which these can do
<Ralph[m]>
JamesMunns[m]: > <@jamesmunns:beeper.com> Yeah, if you aren't ever blocking with timer delays or sending data over an interface, that might take some time (like the time to send out a byte at 9600 baud/100khz/1MHz/16MHz, then there's probably no need for async.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/joowXfBUbOkmsDLjPKhcJkdl>)
Guest7282 has left #rust-embedded [Error from remote client]
pflanze has joined #rust-embedded
Guest7282 has joined #rust-embedded
<firefrommoonligh>
Hi! What is the diff between critical_section Mutex, and cortex_m:: interrupt Mutex? Ty!
<firefrommoonligh>
I suspect a re-export, but can't find the relevant code in cortex_m's github
<dirbaio[m]>
critical_section::Mutex can work on archs that are not cortex-m
<dirbaio[m]>
ad can be customized for weird cortex-m's, for example multicore.
<dirbaio[m]>
cortex_m::interrupt::Mutex is unsound on multicore
<dirbaio[m]>
s/ad/and/
<firefrommoonligh>
Thx!
<firefrommoonligh>
So, doesn't matter on cortex-m targets which you use?
<firefrommoonligh>
This came up bc I am learning ESP
<firefrommoonligh>
Another basics Q: How do ESP32s use the std lib? What is the cost? Ie, why is it convention there, but not other targets like Cortex-m?
<dirbaio[m]>
cortex_m::interrupt::Mutex will be gone in cortex-m 0.8, so prefer critical-section
<dirbaio[m]>
other than that it doesn't matter much
<JamesMunns[m]>
firefrommoonligh: How: They build on top of FreeRTOS
<JamesMunns[m]>
Why: It was a reasonable approach for relatively high end targets that had complex RTOS-requiring driver support for wifi (which used a threaded model), before they later decoupled it to work on RTOS threads or async tasks (or other scheduling models)
<JamesMunns[m]>
"what is the cost": you are locked into the base cost of FreeRTOS, which might be more or less than rolling everything yourself. It's using a posix-ish model, so you sorta pay to fit into those abstractions, for better or worse. In some cases it could be more expensive than it might appear, but likely not offensively so in most cases, though you have less flexible to cut corners you don't care about.
<JamesMunns[m]>
> why is it convention there, but not other targets like Cortex-m
<JamesMunns[m]>
Because no one else (yet) has generally done the work to build a std impl on top of FreeRTOS, Zephyr, etc. There's nothing stopping anyone from doing it other than effort tho
<dirbaio[m]>
a cost is code size, it's not uncommon to see 1MB+ esp32 binaries
<dirbaio[m]>
* esp32 binaries I think
<dirbaio[m]>
but they have huge external flashes so it works out fine for them :D
<dirbaio[m]>
and complexity. if you don't like async because it's harder to know what's going on underneath, esp-idf is that but on a whole other level :D
<firefrommoonligh>
<JamesMunns[m]> ""what is the cost": you are..." <- I appreciate the explanation!
<therealprof[m]>
Never forget our complex meeting schedule again.
Guest7282 has left #rust-embedded [Error from remote client]
JamesSizeland[m] has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh>
Can I assume there is a similar analogy (Re Mutex chat earlier) between critical_section::with and cortex_m::interrupt::free? I am on the same page of preferring the more universal one
<firefrommoonligh>
(Although not a big deal obvs)
<firefrommoonligh>
Is that also being deprecated in cortex_m?
<JamesMunns[m]>
I believe so to all questions, yes
Guest7282 has joined #rust-embedded
gauteh[m] has joined #rust-embedded
<gauteh[m]>
thejpster: I made a test that creates a bunch of files on an SD card using embedded-sdmmc, after 1024 files it seems to go slower in opening and writing files. I don't scan through the existing files on each open/write. any idea if that could be real?
JomerDev[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has left #rust-embedded [Error from remote client]
<thejpster[m]>
Yeah FAT sucks. It uses a linear unsorted array of directory entries in a directory.
<thejpster[m]>
I think a directory entry is 32 bytes so if your using 32 K clusters you have to do a second FAT lookup to get the block start address of the second cluster
hannes4761[m] has joined #rust-embedded
<hannes4761[m]>
Hey there folks, I have been looking online for a bit but haven't really found an answer yet. I was wondering which microcontroller(s) have the best rust support, as in drivers existing? WIFI support would be pretty important to me :)
<thejpster[m]>
Whilst you don’t iterate the directory, the open code has to to check for duplicate file names.
<GrantM11235[m]>
hannes4761[m]: If you want wifi, the ESP32 is the obvious answer
<thejpster[m]>
A better FAT implementation might cache the whole directory but embedded-sdmmc prioritises low memory and low complexity.
<thejpster[m]>
s/your/you’re/
<GrantM11235[m]>
There are a few different versions, the newer risc-v ones are better supported than the older xtensa ones
<hannes4761[m]>
GrantM11235[m]: gotcha thank you, I have a couple of the Xtensa ones lying around if that matters
<hannes4761[m]>
GrantM11235[m]: ah you beat me to it, any specific one that is known to just work ootb?
<GrantM11235[m]>
I'm not sure, I haven't done much with them yet. There is a room for rust on esp, they would know a lot more than me
<GrantM11235[m]>
here: #esp-rs:matrix.org
<GrantM11235[m]>
Another option would be the raspberry pi pico-w. The pico itself is well supported, but I'm not sure how well the wifi works
<gauteh[m]>
<thejpster[m]> "A better FAT implementation..." <- Thanks. Makes sense. I started testing out multiple directories, but I don't feel confident about those yet. I got some error when trying to scan through dirs, but fails to send a good message over RTT. Will have to debug further. For now I increased the file size so that I will have more, bigger files.
<vollbrecht[m]>
<GrantM11235[m]> "There are a few different..." <- the support is the same with the only exception of the old esp8266 is not supported, but everything else should work just as good. The only othere limitation in currently that for xtensa you need a compiler we provide seperatly because LLVM guys are a bit slow on accepting the patches such that we can have a upstream xtensa compiler. But we have a tool called `espup` that does
<vollbrecht[m]>
all the installing for the xtensa compiler just like rustup. Though for the riscv variants you just can use the normal rustup installed compiler
hyphened[m] has joined #rust-embedded
<hyphened[m]>
Is this room okay to ask about debugging a HardFault I'm getting? Or is there another forum to ask in?
<JamesMunns[m]>
If you're using Rust, it's probably fine!
<hyphened[m]>
Cool!
notgull has joined #rust-embedded
<hyphened[m]>
So the problem is with a function I'm using to test the coprocessor of an MCU. Currently I'm executing the function as an #[inline(never)] to help with locating the code and disassembling (I'm using objdump for this)
<hyphened[m]>
The code executes correctly but at the end of the function it suddenly fails, causing a Usage Fault that escalates to a HardFault. The Usage Fault reads the INVSTATE flag as active, which triggers when an invalid Thumb state change appears
<JamesMunns[m]>
ah, as far as we know THAT issue only occurs in opt-level=z
<JamesMunns[m]>
so it might not actually be your problem
<hyphened[m]>
JamesMunns[m]: It's not creating the OUTLINED_FUNCTION_X fucntions now, if it helps
<JamesMunns[m]>
yeah, if there is no OUTLINED_FUNCTION, then it's almost certainly not THAT bug.
<hyphened[m]>
Let me do a full rustup update and check again
<hyphened[m]>
Mainly because for the coprocessor I need the nightly channel
notgull has quit [Ping timeout: 252 seconds]
<hyphened[m]>
It's still happening. From what I've observed it is triggering on BLX instructions with the SL register or instructions that modify the PC
<hyphened[m]>
BTW does anybody what register is SL??
<hyphened[m]>
With opt-level=2 (and 3) I'm getting a bit of the unwind section
<hyphened[m]>
But it looks like it's trying to read from a wrong PC (or the PC is corrupted)
<hyphened[m]>
As it looks like a code generation issue with LLVM I'll leave it as is and come back once the fixes to LLVM are at least in the nightlies
<M9names[m]>
Might be worth asking in the lpc55 channel just in case?
<M9names[m]>
There's a few folks there that don't seem too active here
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<dirbaio[m]>
do the addresses you jump to with BLX or other PC-manipulating instructions have the thumb bit set (lowest bit)?
<dirbaio[m]>
do they look like valid code addresses at all?
andodeki2[m] has quit [Quit: Idle timeout reached: 172800s]
<hyphened[m]>
<dirbaio[m]> "do the addresses you jump to..." <- Depends on the opt-level, at opt-level 2 and 3 they look alright everytime I've breakpointed on them
<hyphened[m]>
At opt-level="s" sometimes the R9 or R4 registers are set to a random address in RAM, like in the middle of .data
<JamesMunns[m]>
You're not like sharing the defmt log between both cores?
<hyphened[m]>
And I can reach the end of the coprocessor function until this point, after which if fails and starts doing the random jumping to RAM or to address 0x0
<JamesMunns[m]>
e.g. using a single core mutex on a multicore system?
<hyphened[m]>
The master core is active the slave core is under reset