<amusil[m]>
I have noticed one thing, after the first transfer both ADDIS and ADSTP get set, but I can't find why, there is no mention that hw would set those
<amusil[m]>
* -I have, * set those -
<amusil[m]>
* <del>I have, * set those </del>, wrong register nevermind
<M9names[m]>
<amusil[m]> "Is it enough context?..." <- you still haven't specified which chip you're using and which hal, which is going to make checking your register accesses and the hal functions pretty difficult.
<M9names[m]>
I'm going to guess it's some stm32 (maybe U5) but some confirmation would be nice.
<amusil[m]>
Ah I though I have written it's STM32G070, my bad, there is no hal just the stm32-rs layer
<amusil[m]>
Also funny thing, when I enable LTO half of the configuration disappears
<amusil[m]>
Ok, so the order is not actually reversed but the vref channel (13) is always first thing that is converted even if the sequence has lower numbers in it
pcs38 has joined #rust-embedded
<JamesMunns[m]>
<thejpster[m]> "I wrote two MPU drivers today..." <- Are you using cortex-mpu? Or something new? I'm guessing the cortex-m and cortex-r (does the R series have MPUs or MMUs?) work differently?
<amusil[m]>
Forward dir is vref(13), pa4(4), pa6(6), pa7(7), backwards is pa4(4), vref(13), pa7(7), pa6(6) any idea why is this happening is appreciated
<amusil[m]>
Starting to suspect that the chip is a little broken sadly I don't have another to check if that's the case
<M9names[m]>
> does the R series have MPUs or MMUs?
<M9names[m]>
yes
<M9names[m]>
but historically just MPUs
<JamesMunns[m]>
yeah, that makes sense
<M9names[m]>
the new ones have an MMU (i think thejpster was talking about one with this feature a while ago?) so you can do real-time and non-realtime on the same cpu core
<M9names[m]>
something something hypervisor to provide seperation
<JamesMunns[m]>
man, cortex-r gets all the weird fun architectural stuff
<bitts[m]>
Maybe it is easier to just invalidate the cache on every log (although that feels a bit icky)
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
<bitts[m]> "Maybe it is easier to just..." <- You could put the RTT channels into a specified link section, then exclude that linked section from MMU management at run-time
<bitts[m]>
<ryan-summers[m]> "You could put the RTT channels..." <- Yes, if I modify rtt_target, I can do that. Was just hoping I wouldnt have to modify rtt_target 😅
<diondokter[m]>
Maybe there's a way to do it with the linker script?
<diondokter[m]>
Not sure if you can place symbols based on the name somewhere specific
<diondokter[m]>
Does Rust have something similar to this?
<diondokter[m]>
In any case, if Rust outputs a section for each symbol, the linker can place it
<diondokter[m]>
* the linker script can place
<bitts[m]>
diondokter[m]: You have `#[link_section = ".mysection"]`, that could be added to rtt_target
<diondokter[m]>
Yeah, well your point was that you don't want to edit the source
<bitts[m]>
diondokter[m]: Yes that would work, although might be tricky without no_mangle(?). Not sure how random symbols are
<diondokter[m]>
Isn't the RTT buffer no_mangle?
<bitts[m]>
The control block is no_mangle, but not the buffer (you can have multiple depending on number of channels)
<diondokter[m]>
Ah hmm no
<diondokter[m]>
(Was looking that up just now too)
<diondokter[m]>
Ok, sad
<ryan-summers[m]>
<bitts[m]> "Yes, if I modify rtt_target, I..." <- Honestly there should be a way to forward external attributes into rtt-target for this, I know some probers macros do this too? Probably a good PR for rtt-target
<diondokter[m]>
Yeah, but how? Maybe have a feature in the crate so it can do a `cfg_attr` and place it in a special `.rtt_buffers` section?
<diondokter[m]>
That'd work, but I don't think there's a good way to specify the string yourself
<ryan-summers[m]>
I think that takes all external meta attributes for the macro and then allows you to redefine them on objects declared within the macro
<bitts[m]>
ryan-summers[m]: Not sure if I quite follow your suggestion, but having `rtt_target::rtt_init_with_link_section(".rtt");` should be easy enough(?)
<ryan-summers[m]>
I suspect we can modify the macros within rtt-target to include $(#[$outer:meta])* in the macro arguments and then propagate that into the generated RTT struct. That way, any generic attributes provided outside of rtt-target can be forwarded in easily
<diondokter[m]>
Oh right, I was thinking about defmt-rtt too much. With rtt-target it's indeed a macro which initializes it. That makes it much easier
<bitts[m]>
<ryan-summers[m]> "I suspect we can modify the..." <- Ah, gotcha. It is not one RTT struct, rather a few static MaybeUnints sprinkled here and there, so not sure if it would make sense to make it that generic, but yeah, it would be a neat solution
<thejpster[m]>
The R profile is strictly PMSA as far as i know.
<thejpster[m]>
PMSA - Protected Memory System Architecture. VMSA - Virtual Memory System Architecture.
n_vl[m] has joined #rust-embedded
<n_vl[m]>
Anyone familiar with how the defmt macros work can maybe help me work through why I hit an unreachable statement on derive? I created an issue for this here: https://github.com/knurling-rs/defmt/issues/939
<n_vl[m]>
The macro appears to follow the normal control flow as far as I can tell, only the end result is a compiler error..
berkus[m] has quit [Quit: Idle timeout reached: 172800s]
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
burrbull[m] has quit [Quit: Idle timeout reached: 172800s]
MrPashaPG[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
Having read through many pages of comments, I see you’ve closed the ticket as not an issue. It would have been nice to post here to say help was no longer required.
<n_vl[m]>
<thejpster[m]> "Having read through many pages..." <- Hey sorry, I still have it as a personal issue of my project. But my guess is this strongly tends toward can not reproduce for anyone else..
<n_vl[m]>
* Hey sorry, I still have it as a personal issue of my project. But my guess is this strongly tends toward can not reproduce for anyone else..
<n_vl[m]>
I'm still investigating. Overtime I've come to think it might be workspace related so I made all crates into a single one and now I still have a single problematic crate. The issue is it depends on other local crates which work fine so I'm not sure if this is only a me problem or an actual defmt problem
<n_vl[m]>
thejpster: were/are you actively looking into this?
<thejpster[m]>
I’m a defmt maintainer so it flagged as important for me
<thejpster[m]>
Hey everyone. Good news! I worked out why my SoC keeps crashing - which has taken a month of debugging.
<thejpster[m]>
The answer is painfully obvious. As these things are when you know the answer.
<thejpster[m]>
Reading or writing to a peripheral causes an exception. Unless cache is off in which case read works, but write still fails.
pcs38 has quit [Quit: leaving]
mabez[m] has joined #rust-embedded
<mabez[m]>
Is there an address space you can access the peripherals directly, instead of disabling the cache?
<JamesMunns[m]>
<thejpster[m]> "Reading or writing to a peripher..." <- Is this a multicore SoC?
<JamesMunns[m]>
(and if so, are peripherals mapped to only one of them on boot?)
<thejpster[m]>
Yes it’s multi core but I’m only on core 0
<thejpster[m]>
And the MPU is off
<thejpster[m]>
Except, you can’t turn the MPU off
<thejpster[m]>
You can only put it in default mode
<JamesMunns[m]>
ah yeah, the cortex-r programmers guide walks you through invalidating caches (multiple stages!) and setting up MPUs before you hit any other init code
<thejpster[m]>
That’s not a good region for peripherals to be in.
<thejpster[m]>
They require the “Device” attribute on their region.
<kline>
does anyone know from where embassy derives its linker scripts (or how they can be controlled/modified)? the stm32f103 example in the root embassy crate is unrunnable because it's assigned double the amount of flash and sram to the linker script (with the correct stm32f103c8 feature selected in Cargo.toml)
<kline>
disregard, i have an unrelated build error that i can fix first
<thejpster[m]>
Well the good news is the MPU driver I wrote for PMSAv8-32 works! Now I can talk to my peripherals.
DavidBrown[m] has joined #rust-embedded
<DavidBrown[m]>
Sigh, I was hoping this would be useful. In Zephyr, most objects have linked list pointers, where the empty list is the pointer pointing back on itself. This fairly aggressively makes them unfriendly with Rust's move semantics.... (full message at
<DavidBrown[m]>
What I've ended up doing, in the interim, is sticking the freelist into `Box<Queue>`. Right now, the bounded queue has all of the messages in a Box anyway (for basically the same reason, they can't move).
<DavidBrown[m]>
It seems that the general Rust answer to "it can't move" is to Box/Arc it. And sometimes, trying to make things static is a bit tricky.