GuineaWheek[m] has quit [Quit: Idle timeout reached: 172800s]
ivche_ has joined #rust-embedded
ivche has quit [Ping timeout: 252 seconds]
ivche_ is now known as ivche
sroemer has joined #rust-embedded
korbin[m] has joined #rust-embedded
<korbin[m]>
Robin Mueller: do you have a channel for the bare metal zynq stuff? i am running your `simple` example now on an EBAZ4205 with `openocd` (no vivado at all)
<korbin[m]>
(and no DDR for that matter - all from OCM - to evaluate these for MCU use)
Socke has quit [Ping timeout: 248 seconds]
Socke has joined #rust-embedded
i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
sroemer has quit [Ping timeout: 252 seconds]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
<RobinMueller[m]>
korbin: i dont have a channel yet but i am glad there is interest. I have not looked at running from OCM yet, because i‘d have to do some DDR/clock initialization as well. I was planning an creating something similar like the zynq-rs FSBL soon which also works with bootgen.
<RobinMueller[m]>
Also, cool that you made it work wirh openocd. How do you flash the FPGA?
<RobinMueller[m]>
* korbin: i dont have a channel yet but i am glad there is interest. I have not looked at running from OCM yet, because i‘d have to do some DDR/clock initialization as well, and I currently do that with a
<RobinMueller[m]>
TCL script. I was planning an creating something similar like the zynq-rs FSBL soon which also works with bootgen.
<RobinMueller[m]>
Also, cool that you made it work wirh openocd. How do you flash the FPGA?
<RobinMueller[m]>
* korbin: i dont have a channel yet but i am glad there is interest. I have not looked at running from OCM yet, because i‘d have to do some DDR/clock initialization as well, and I currently do that with a TCL script. I was planning an creating something similar like the zynq-rs FSBL soon which also works with bootgen, to allow creating bare metal boot packages for sdcard/nor flash etc.
<RobinMueller[m]>
Also, cool that you made it work wirh openocd. How do you flash the FPGA?
<RobinMueller[m]>
* korbin: i dont have a channel yet but i am glad there is interest. I have not looked at running from OCM yet, because i‘d have to do some DDR/clock initialization as well, and I currently do that with a TCL script. I was planning on creating something similar like the zynq-rs FSBL soon which also works with bootgen, to allow creating bare metal boot packages for sdcard/nor flash etc. Also, cool that you made it work
<RobinMueller[m]>
wirh openocd. How do you flash the FPGA?
pcs38 has joined #rust-embedded
<korbin[m]>
<RobinMueller[m]> "korbin: i dont have a channel..." <- would be good to get a channel going.
<korbin[m]>
i didnt have to do any init beyond what you are doing in the `rt` crate besides of taking the OCM out of reset (in openocd)
<korbin[m]>
the FPGA can be flashed with openocd too - otherwise you need one of the memory-mapped interfaces with enough space (2MB for the z7010) -- nor/nand/qspi flash or ddr
<korbin[m]>
<RobinMueller[m]> "korbin: i dont have a channel..." <- all i had to do to run from OCM was change the `memory.x` location and remove your data cache invalidation routine in `rt` (haven't debugged it but it crashes) - otherwise everything worked unmodified
<korbin[m]>
i've already had LLMs break down the ps7_init script that gets generated by vivado - it's just the DDR config registers, mio, emio, and the like - mostly things that are already in other embassy HALs (besides the config). vivado should be unnecessary (like STM32CUBE) if everything shapes up nicely
<korbin[m]>
i'd like to get probe-rs working for both the PS and PL
<korbin[m]>
* i've already had LLMs break down the ps7\_init script that gets generated by vivado - it's just the DDR config registers, mio, emio, and the like - mostly things that are already in other embassy HALs (besides the ddr config). vivado should be unnecessary (like STM32CUBE) if everything shapes up nicely
<RobinMueller[m]>
korbin: the data cache invalidation of L2? I just copied some parts from the xilinx startup files..
<korbin[m]>
i haven't stepped through it to see where it breaks
<korbin[m]>
the MMU table is quite large, my blinky binary is like 128K
<korbin[m]>
the MMU is sweet though - PSRAM/HyperRAM/block RAM in PL can be used with MMIO
<RobinMueller[m]>
korbin: yeah that is the l2 init. Maybe that could be put into user code anyway, i just assumed xilinx had areason to put it in startup code but i have not triied removing it yet for the RAM flashing. The MMU config is just linked into the binary statically. I assumed that RAM storage is not really an issue 😄
<korbin[m]>
RobinMueller[m]: these chips are $2 in china, they are usable as MCUs without DDR
<korbin[m]>
even just the PL is a steal of a deal
<RobinMueller[m]>
2 dollars is insane for these chips.
<RobinMueller[m]>
The zedboard still costs 300-500€.. korbin someone made probe-rs work for arty z7. I am not sure yet how to solve the issue that I always want to flash a new FPGA bitstream before flashing my regular app to RAM.
<RobinMueller[m]>
* 2 dollars is insane for these chips. The zedboard still costs 300-500€.. korbin someone made probe-rs work for arty z7. I am not sure yet how to solve the issue that I always want to flash a new FPGA bitstream before flashing my regular app to RAM.
<RobinMueller[m]>
* to RAM. Have you managed to make RTT work with openOCD?
nadja has quit [Ping timeout: 260 seconds]
<korbin[m]>
RobinMueller[m]: you have to load the bitstream from the PS or with JTAG from an external MCU. if you have embassy-boot or other first-stage bootloader you can do it before loading your "regular app" - having an MMU makes this super easy
<korbin[m]>
he zedboard is insanely overpriced, which is why i am fighting to use some of these leftover $5 ebaz4205 boards i have until i know if these will be usable for my application or not
<korbin[m]>
RobinMueller[m]: i dont like openocd, haven't tried to make RTT work, i want to get probe-rs working asap
<korbin[m]>
but you can read/write arbitrary memory with openocd, so i assume RTT will work just fine
<korbin[m]>
it's unfortunate that the PCAP doesn't have a non-DMA config option from what i can tell - a la JTAG
<korbin[m]>
because it seems like you can't get away from having the entire bitstream buffered in a memory-mapped place
<JamesMunns[m]>
<RobinMueller[m]> "I created https://matrix.to/#/!..." <- what's the room name? It's showing as the "raw" identifier for me so I can't join in my client :p
<JamesMunns[m]>
<cr1901> "Robin Mueller: I don't think I'..." <- Does sound a bit like a stack overflow, honestly, but could also be a codegen bug in debug that doesn't hit in release.
<JamesMunns[m]>
<cr1901> "Robin Mueller: I don't think I'..." <- For "well tested" backends like cortex-m I'd bet way harder on stack overflow, but I've seen some really goofy AVR miscompilations, especially around stuff like dyn trait (which shows up in formatting)
<RobinMueller[m]>
JamesMunns[m]: problem is, I can not reproduce is with a MCVE, and the UART example is generating quite a bit of code in debug mode already.. and I can not really read MSP430 code :D
<RobinMueller[m]>
* code :D 8kB of RAM is just soo small
<RobinMueller[m]>
* problem is, I can not reproduce is with a MCVE, and the UART example is generating quite a bit of code in debug mode already.. and I can not really read MSP430 disassembly :D 8kB of RAM is just soo small
<RobinMueller[m]>
* problem is, I can not reproduce it with a MCVE, and the UART example is generating quite a bit of code in debug mode already.. and I can not really read MSP430 disassembly :D 8kB of RAM is just soo small
<JamesMunns[m]>
RobinMueller[m]: Dunno if you know (or want to learn) enough ASM to do stack painting, that would make it easier to tell, especially if you have some way of checking the high water mark with a debugger
<RobinMueller[m]>
JamesMunns[m]: Yes I was already considering of ways to somehow check the stack usage. I would probably see relatively quickly whether it is getting close to the ROM offset.. never did this before though
<RobinMueller[m]>
JamesMunns[m]: I also have GDB access, that might help?
<JamesMunns[m]>
<cr1901> "Robin Mueller: I don't think I'..." <- Generally "stack painting" means writing a fixed/repeating pattern to all potential stack locations, usually in a pre-main init function (and if you want it to be sound, probably with ASM).
<JamesMunns[m]>
Then you let the code run, and go back and read how many of the bytes still have the pattern in them, or have been overwritten
<JamesMunns[m]>
<cr1901> "Robin Mueller: I don't think I'..." <- You could maybe do it manually in gdb: set a breakpoint at main, manually write a value to the whole stack, resume, then break at a later point and figure out how high the stack got
<JamesMunns[m]>
<cr1901> "Robin Mueller: I don't think I'..." <- or yeah, put a breakpoint near where it crashes, and just single step, looking at the stack pointer
<JamesMunns[m]>
<cr1901> "Robin Mueller: I don't think I'..." <- stack overflows can be tricky tho, sometimes an overflow EARLIER can cause a crash LATER, because some global variable got corrupted and it screws something else up later that actually crashes.
<RobinMueller[m]>
JamesMunns[m]: SP is 0x3bba, and the stack start is 0x3C00 shortly before it crashes 🤔
<JamesMunns[m]>
RobinMueller[m]: Do msp430 stacks grow downwards or upwards, and is "stack start" the "full stack" point or "empty stack" point?
jfsimon1981a is now known as jfsimon
<RobinMueller[m]>
JamesMunns[m]: downwards. stack start is empty stack point I think
<JamesMunns[m]>
<cr1901> "Robin Mueller: I don't think I'..." <- so you're using 70 bytes of stack? What is your "stack full" point? It'll be where your other global variables (.data, .bss) end.
<JamesMunns[m]>
<cr1901> "Robin Mueller: I don't think I'..." <- doesn't sound very stack overflowy, but who knows maybe you only have 128 bytes of stack accidentally lol
<RobinMueller[m]>
<JamesMunns[m]> "Do msp430 stacks grow downwards..." <- .data and .bss start at 0x1C00 (bottom of RAM) and take 4 bytes 😅
<JamesMunns[m]>
<cr1901> "Robin Mueller: I don't think I'..." <- Cool, so it doesn't sound very stack overflow-y, unfortunately, which makes it sound a lot more like a miscompilation
<JamesMunns[m]>
<cr1901> "Robin Mueller: I don't think I'..." <- it might be interesting to dump the asm in debug and release mode and diff the two around where the crash occurs, but without understanding msp430 asm I'm not sure what to do about that, other than to report it to cr1901 or the llvm project
<RobinMueller[m]>
I'm just trying to create an ever smaller MCVE, but that is actually tricky. I started with an extremely small excample involving the code I though was the culprit, and of course it worked :D
<thejpster[m]>
For reference, Arm stacks are Full Descending, which means the stack pointer points at a full word, not an empty word, and everytime you increment the pointer, the stack pointer goes down by 4. This means to set up PSP, I had to set it to point to `start_of_buffer + buffer.len()` - effectively pointing just beyond the buffer. An Empty Descending stack would be set to `start_of_buffer + buffer.len() - 1` so it points at the top
<thejpster[m]>
most empty slot in the stack.
<thejpster[m]>
You can also have ascending stacks but I can't remember the last time I worked with one. My MIPS and my SPARC machines both have descending stacks.
<thejpster[m]>
actually I wonder if it's a config option for the target - can I tell Rust I want an ascending stack instead? The hardware absolutely supports it.
<JamesMunns[m]>
If it'd be configurable, it'd be an llvm target option
<JamesMunns[m]>
a quick search doesn't show anything tho, which isn't promising lol
<dirbaio[m]>
> The hardware absolutely supports it.
<dirbaio[m]>
when the NVIC pushes the exception frame it assumes a descending stack
<dirbaio[m]>
I think all exceptions/interrupts switch to MSP, then push the exception frame to the MSP
<jason-kairos[m]>
That would make sense (except my handler is reading the thread's exception frame from PSP - I need to double check my assumptions, maybe the frame gets copied over earlier without me realizing).
<dirbaio[m]>
the pushed frame doens't include the SP
<dirbaio[m]>
I think there's some magic instruction to get/set the PSP from privileged mode
<JamesMunns[m]>
yep
<jason-kairos[m]>
I just checked, I'm pretty confident that the assembler handler isn't doing anything like that.
<jason-kairos[m]>
Somehow the exception frame is where-ever PSP points to then the hardfault occurs.
<jason-kairos[m]>
I'd have to dig into one of the arm manuals (more than what ST publishes) to make sure, but I'm starting to think that hardfaults might have the potential to go south
<RobinMueller[m]>
<JamesMunns[m]> "it might be interesting to..." <- debug and release generate completely different code. compilers are insane 😄 im trying instructiuon stepping now. I just did si through the __muldi3 method, and at some point, it just jumps to the RESET instruction
<jason-kairos[m]>
* I just checked, I'm pretty confident that the assembler handler isn't (edit: copying msp contents to psp address)
<jason-kairos[m]>
Somehow the exception frame is where-ever PSP points to then the hardfault occurs.
<jason-kairos[m]>
I'd have to dig into one of the arm manuals (more than what ST publishes) to make sure, but I'm starting to think that hardfaults might have the potential to go south
<jason-kairos[m]>
* I just checked, I'm pretty confident that the assembler hardfault handler isn't (edit: copying msp contents to psp address)
<jason-kairos[m]>
Somehow the exception frame is where-ever PSP points to then the hardfault occurs.
<jason-kairos[m]>
I'd have to dig into one of the arm manuals (more than what ST publishes) to make sure, but I'm starting to think that hardfaults might have the potential to go south
<jason-kairos[m]>
There a big long comment in Hubris's hardfault handler bemoaning that certain debug registers are not accessible by the processor. I'll have to double check which ones.
<JamesMunns[m]>
M0+ is such an unfortunate architecture
<diondokter[m]>
Do we actually know how much cheaper an m0+ core is compared to an m4 core? (Assuming all else remains the same like peripherals and memory)
<JamesMunns[m]>
afaik it's mostly a space thing
<JamesMunns[m]>
the m0+ is a much smaller silicon footprint, and afaict more amenable to low power designs
<diondokter[m]>
Well yeah, but on a die space = money
<JamesMunns[m]>
no idea if it's ALSO priced lower, IP wise, which is why it is used so often
<diondokter[m]>
Ah yeah, there's that too
<wassasin[m]>
You can download the M0+ core from ARM for free for your FPGA btw
<finga[m]>
I am trying to run the usb_serial example from the stm32f1xx_hal crate on an STM32F107. But currently I am wondering whether I am doing something wrong or this is not (yet?) implemented as only STM32F103xx is mentioned in the code as far as I can see.
<jason-kairos[m]>
That's interesting. I would not have found that. Those gate count differences are larger than I expected. I think I can forgive the designers of the M0+ for their transgressions.
<JamesMunns[m]>
the processor datasheets for M0 and M0+ from ARM actually say that the minimum and typical footprints for M0+ are actually SMALLER than M0?
<JamesMunns[m]>
<wassasin[m]> "Time to play "why does this..." <- reset pin not tied the wrong way either?
<wassasin[m]>
nrst is looking good
pcs38 has quit [Ping timeout: 276 seconds]
pcs38 has joined #rust-embedded
<RobinMueller[m]>
cr1901: Never mind. I think I found the issue. I need to use the F5 series mul support; I assumed that this is only for F5XX devices, but it also applies for FRxx. I tried theF5 series mul support, but got a crash due to an unrelated issue, so i did not try it again. Now, I see in the disassembly that the mul code with correct base addresses is generated 🫣
M9names[m] has joined #rust-embedded
<M9names[m]>
<wassasin[m]> "You can download the M0+ core..." <- oh really? i knew you could get access to m0, didn't think m0+ was an option
<wassasin[m]>
Now that I am googling it, can not find that, so I must be mistaken
<thejpster[m]>
a horror story from one of my colleagues. Set up a nice buffer of u16s on the stack, take a pointer to it and pass the pointer to the DMA engine. There's a compiler fence in there, as the embedonomicon says there should be.
<thejpster[m]>
Compiler is apparently eliding some of the buffer writes because it determines the buffer is never 'read'.
<thejpster[m]>
using the buffer as an argument to an empty asm! block fixes the issue 🙃
<wassasin[m]>
I was using an incorrect GDB, my STM32G0B1 is running, but setting sysclk to 64MHz somehow does not work
<wassasin[m]>
Or at least defmt_rtt seems unhappy
<JamesMunns[m]>
<thejpster[m]> "a horror story from one of my..." <- can you share a snippet of what the code looks like?
<wassasin[m]>
Okay I am an idiot, disregard :')
<wassasin[m]>
Of course defmt will only show me stuff by default if there is an error :'''')
<thejpster[m]>
<JamesMunns[m]> "can you share a snippet of..." <- I'll ask
DominicFischer[m has joined #rust-embedded
<DominicFischer[m>
Yeah the compiler is annoying for that. It optimizes so much more aggressively due to the aliasing rules.
<DominicFischer[m>
I've been thinking recently that DMA buffers should be stored as pointer+size rather than a slice to prevent the compiler from making assumptions
<DominicFischer[m>
* more aggressively compared to C/C++ due to
<JamesMunns[m]>
AFAIU, taking a mut pointer to the slice, and adding compiler fences, should be enough for the compiler to consider the pointer "escaped", but wrapping the buffer in an `UnsafeCell` would be a much stronger signal to the compiler IMO.
<thejpster[m]>
can you make a mut pointer from a shared slice?
<thejpster[m]>
and are all ways of taking pointers to a slice equivalent? There's the new expose_provenance API - maybe that works differently here? I asked the question to the author - will update later.
<thejpster[m]>
this was some_slice.as_ptr() as usize
<DominicFischer[m>
What I had in mind was to start with a `&'static mut [u8]`, get pointer (via `.as_mut_ptr()`) and size, throw away the reference. Then use `slice::from_raw_parts` every time I needed to write to it
<diondokter[m]>
thejpster[m]: Yeah, feels like this should be an unsafecell
<JamesMunns[m]>
if it needs to be shared, yes it needs an UnsafeCell
<JamesMunns[m]>
if it's a mut slice, you should use as_mut_ptr from an &mut ref, not through an & ref
<JamesMunns[m]>
DominicFischer[m: you can use GroundedCell for that if you want
<JamesMunns[m]>
<thejpster[m]> "this was some_slice.as_ptr() as..." <- But yeah, if you are making a const ptr from a shared slice, I am not surprised there are miscompilations - that is UB
<JamesMunns[m]>
* shared slice (edit: and writing through to it,, * , DMA or not), I am
<DominicFischer[m>
<JamesMunns[m]> "https://docs.rs/grounded/latest..."; <- The const generic is a smidge to inconvenient and the benefits aren't immediately obvious to me.
<JamesMunns[m]>
<JamesMunns[m]> "https://docs.rs/grounded/latest..."; <- Fair! The goal of grounded is to handle some of the basics of UnsafeCell/MaybeUninit, and have methods with specifically documented unsafe invariants, so that folks have a more direct checklist when writing safe libraries on top of it.
<thejpster[m]>
<JamesMunns[m]> "But yeah, if you are making a..." <- reading from it - the DMA is transmitting
<diondokter[m]>
thejpster[m]: Well, the compiler won't expect it's being written to, so it probably concludes that it doesn't have to get read from and can assume the intiitial values are still in there
<thejpster[m]>
User code writes to the buffer, and DMA reads the buffer. The compiler assuming that no-one is reading the buffer and the writes are being elided.
<thejpster[m]>
* The compiler is assuming that
<thejpster[m]>
We need to tell the compiler "hey, I'm reading this thing even if you can't see me read it". A 'virtual' read_volatile, without actually reading it.
<diondokter[m]>
That's what an unsafecell is for
<JamesMunns[m]>
Gotcha, in the case of transmit dma, the ptr being created on a shared slice should still be correct if the ptr is passed to dma, that should do the "ptr escaping", but yeah seeing the code would help, and having an unsafe cell tells the compiler "don't assume anything that does/doesn't happen between making references of the storage
emielvs[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
In this case I have no idea. If you made an `UnsafeCell<[u8; 16]>` you could use the pointer from that.
<jason-kairos[m]>
All of this makes me wonder about things I'm doing with DMA and static mut buffers as well. I think I've got enough pointer operations and other things that make it safe from the compiler.
<jason-kairos[m]>
Compiler fences never appeared to do anything for me for any problem I tired to apply it to.
<jason-kairos[m]>
I guess, when in doubt, pass it as an argument to an assembly block, or do a volatile read.
<thejpster[m]>
<JamesMunns[m]> "In this case I have no idea..." <- The problem being that UnsafeCell is !Sync, so you can't use it in a static variable.
<JamesMunns[m]>
yes, it's a building block, not a solution, for sure.
<thejpster[m]>
2. Put a data type in cortex-m that does this for you
<thejpster[m]>
I guess option 3 is have cortex-m pull in grounded or something, but I don't love that option.
<JamesMunns[m]>
it's not a lot of code, you're welcome to copy paste the thing wholesale.
<thejpster[m]>
The type isn't hard - I pasted a copy into the ticket.
<thejpster[m]>
it's more about where it should live
<JamesMunns[m]>
(I offered to move grounded into wg-embedded a year ago, so it could be used for more foundational things, no takers yet, and I haven't had much more time to work on it)
<thejpster[m]>
I feel like everyone has to use cortex-m, so I'm loathed to make their dependency tree larger.
<thejpster[m]>
the correct answer is that the Project puts some kind of unsafe mutable pointer-only array type into libcore.
<thejpster[m]>
or stops threatening static mut with extinction
<JamesMunns[m]>
it exists and is called syncunsafecell and it's not stable for reasons I don't remember, probably bikeshedding
<JamesMunns[m]>
and at least personally I think static mut should have been done away with already
<JamesMunns[m]>
grounded was an attempt to have safer statics (hah), and ideally guide folks having better collections to choose, instead of just telling them they are bad for using static mut
<JamesMunns[m]>
* guide folks towards having better