<re_irc>
<@ubik:matrix.org> I ended up doing something which no one suggested: flashing the st-link on my disco board with Black Magic Probe and using BMP to debug the RP2040
<re_irc>
<@ubik:matrix.org> It works
<re_irc>
<@ubik:matrix.org> Just a pity probe-run doesn't recognize BMP
<re_irc>
<@theunkn0wn1:matrix.org> probe-run would recognize the dappermine-flashed pico
<re_irc>
<@9names:matrix.org> that does mean you have to have 2 picos. ub|k might only have one
rardiol has quit [Ping timeout: 252 seconds]
<re_irc>
<@theunkn0wn1:matrix.org> fair.
emerent has quit [Ping timeout: 252 seconds]
starblue has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
starblue has joined #rust-embedded
PyroPeter has quit [Ping timeout: 245 seconds]
PyroPeter has joined #rust-embedded
dcz_ has joined #rust-embedded
rardiol has joined #rust-embedded
tokomak has joined #rust-embedded
<re_irc>
<@fragadaleta:matrix.org> what's the difference here except the price??
<re_irc>
<@k900:0upti.me> You can probably save on shipping if you find a retailer close to you
<re_irc>
<@adamgreig:matrix.org> gdamjan:spodeli.org: It might be a bit annoying because the g0 mpu has a larger minimum region size of 256 bytes instead of 32, and there's no memory management exception (but I don't think hubris uses this?), but otherwise maybe you just need to add one or two thumbv6 methods to the arm_m file...
kehvo has quit [Ping timeout: 256 seconds]
rardiol has quit [Ping timeout: 256 seconds]
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
<re_irc>
<@neltnerb:matrix.org> fragadaleta:matrix.org: I can confirm that I ordered my discovery board from digikey and it arrived quickly and was in stock.
dkm has quit [Quit: leaving]
<re_irc>
<@xnorman:matrix.org> I'm programming an stm32h750 (daisy seed) and I've gotten to a point where my firmware fails to run if I program via dfu-util but it runs fine if i program via jtag (black magic probe).. any ideas what could be going wrong? I'm collaborating with a friend who needs to use dfu-util to program
<re_irc>
<@xnorman:matrix.org> I should really program with dfu then try attaching with jtag i guess
<re_irc>
<@newam:matrix.org> xnorman:matrix.org: Yeah, it is difficult to say more without knowing the mode of failure.
<re_irc>
<@xnorman:matrix.org> yeah, at this point all i know is that the display i have isn't being drawn to and the LEDs aren't lighting.. but i'll see if I can find out more via jtag
<re_irc>
<@xnorman:matrix.org> so.. i've programed via dfu-util, then I hook up my jtag debugger, enable gdb, `gdb-multiarch -q -x blackmagic.gdb` then set the file `file ./target/thumbv7em-none-eabihf/release/xsched` and type `start`
<re_irc>
<@xnorman:matrix.org> after stepping over a bunch of lines like:
<re_irc>
<@xnorman:matrix.org> the datasheet says there is 128kB of flash.. but, does the dfu compatible bootloader take up some of that?.. dfu-util says i'm programming 83856 bytes
<re_irc>
<@adamgreig:matrix.org> if it's the ST dfu bootloader (the one you access with BOOT0 pin or by having your firmware jump to a special address?), it's built-in and lives in a different part of memory
<re_irc>
<@adamgreig:matrix.org> are you able to have gdb print src and dst for that copy_nonoverlapping call?
<re_irc>
<@adamgreig:matrix.org> odd that it works when flashed by jtag but just not via dfu though
<re_irc>
<@adamgreig:matrix.org> if you flash via jtag, then disconnect the bmp and power cycle, does it still boot ok?
<re_irc>
<@xnorman:matrix.org> yeah.. the dfu based program is via holding boot0 and hitting reset.. jsut a sec, i'll try to jump to the src
<re_irc>
<@xnorman:matrix.org> yeah.. jtag.. i reset, power cycle, all that and i get to my firmware running as expected
<re_irc>
<@adamgreig:matrix.org> so it can't be any state the bmp leaves the system in helping it work, and the two methods must be somehow flashing something different/to a different place?
<re_irc>
<@adamgreig:matrix.org> what dfu-util command are you running?
<re_irc>
<@adamgreig:matrix.org> and how do you generate the .dfu file for it?
<re_irc>
<@adamgreig:matrix.org> (or whatever other file you're feeding it)
<re_irc>
<@adamgreig:matrix.org> all seems ok... i had a vague thought that the d2 sram might not be enabled before you try to write to it but in that case I think it just ignores writes, not faults, so probably not that
<re_irc>
<@adamgreig:matrix.org> probably back to gdb for hints
<re_irc>
<@adamgreig:matrix.org> do you end up in the hardfault handler?
<re_irc>
<@xnorman:matrix.org> if i do `print` or `po` for src or dst I get : `No symbol 'src' in current context` etc..
<re_irc>
<@xnorman:matrix.org> i kinda flail with gdb though..
<re_irc>
<@xnorman:matrix.org> programming with jtag/bmp was using a debug build of my firmware.. i still get the segfault via bmp loading the firmware with --release
<re_irc>
<@xnorman:matrix.org> OKAY.. hmm, I failed to notice an important piece of the puzzle..
<re_irc>
<@adamgreig:matrix.org> what version of cortex-m-rt are you using?
<re_irc>
<@adamgreig:matrix.org> oh, 0.6.15, I see
<re_irc>
<@adamgreig:matrix.org> at least it's the same with both programming methods now!
<re_irc>
<@xnorman:matrix.org> yeah.. so dfu-util programming without `--release` now works
<re_irc>
<@xnorman:matrix.org> meaning.. the firmware runs
<re_irc>
<@xnorman:matrix.org> it seems as though, with a debug build, i'm close to the limit of the firmware size: 127456 bytes
<re_irc>
<@adamgreig:matrix.org> if you stick an infinite loop at the end of the rtic init function, so that it never finishes init and thus never enables interrupts, does it still segfault or does it get to the new loop and wait there?
<re_irc>
<@xnorman:matrix.org> trying.. 1 moment
<re_irc>
<@xiretza:xiretza.xyz> infinite loop debugging... been there, done that :)
<re_irc>
<@xnorman:matrix.org> it does not segfault there
<re_irc>
<@xnorman:matrix.org> ooh, oops.. END, i did it a the start, let me try that
<re_irc>
<@xnorman:matrix.org> also doesn't segfault
<re_irc>
<@adamgreig:matrix.org> hmm, so the segfault is after init
<re_irc>
<@adamgreig:matrix.org> it sounds dumb but i'd try knocking out interrupts one at a time (or sticking infinite loops into them) to see which interrupt is causing trouble, if it's just one
<re_irc>
<@xnorman:matrix.org> i just disabled lto and now i'm not segfaulting
<re_irc>
<@adamgreig:matrix.org> cool cool
<re_irc>
<@adamgreig:matrix.org> probably it's some sort of horrible UB
<re_irc>
<@xiretza:xiretza.xyz> xnorman:matrix.org: are you using any unsafe in your application code?
<re_irc>
<@adamgreig:matrix.org> even without unsafe, if you're using link_section anywhere or perhaps on something that expects buffers to be initialised to 0 or something...
<re_irc>
<@xiretza:xiretza.xyz> sure, was just going for low-hanging fruits first
<re_irc>
<@adamgreig:matrix.org> the 0xffff_fffe pc is suspicious because it's an exception return value that exceptions can load into LR
<re_irc>
<@adamgreig:matrix.org> maybe try `info reg` in gdb after the segfault and see what pc and lr are?
<re_irc>
<@xnorman:matrix.org> there are a couple of unsafes in there.. and more in the library code
<re_irc>
<@adamgreig:matrix.org> but it could be something else too
<re_irc>
<@adamgreig:matrix.org> if you can eliminate interrupts one by one it might help narrow down which bit of code is being cheeky
<re_irc>
<@xnorman:matrix.org> cool. i'll get that segfault back, just a moment
<re_irc>
<@xnorman:matrix.org> yeah.. so if i disable the timer interrupt that i use to poll inputs.. no segfault
<re_irc>
<@xnorman:matrix.org> there is an unsafe in there.. so, i'll double check that
<re_irc>
<@adamgreig:matrix.org> any big stack allocations? i don't fully see why sp/psp is 0 but your msp is like 58kB below the bottom of your ram which doesn't seem right
<re_irc>
<@adamgreig:matrix.org> looks like it hardfaults after returning from the interrupt, bottom bits of xpsr are 0 which would otherwise be the interrupt number
<re_irc>
<@adamgreig:matrix.org> but probably because it tried to start executing code from ffff_fffe, heh
<re_irc>
<@xnorman:matrix.org> there is a function that can be triggered in that interrupt that does do a big stack alloc
<re_irc>
<@xnorman:matrix.org> but.. it shouldn't happen until i trigger it via some menu diving
<re_irc>
<@jannic:matrix.org> Perhaps that function gets inlined for some reason and so the stack frame of the caller is getting huge? Could explain why it only happens with `--release`.
<re_irc>
<@xnorman:matrix.org> oh huh.. yeah, if i remove those.. no more segfault
<re_irc>
<@adamgreig:matrix.org> how big is the stack alloc?
<re_irc>
<@adamgreig:matrix.org> it's a bit alarming that something's swapped your stack pointer to psp, perhaps the interrupt returning or perhaps a deliberate write to CONTROL?
<re_irc>
<@xnorman:matrix.org> trying to figure that out.. basically, these methods load/store my entire program state.. that is passed back on the stack
<re_irc>
<@adamgreig:matrix.org> you could stick `#[inline(never)]` to stop it getting inlined, then see if it crashes when you go into that function from the menu, maybe
<re_irc>
<@jannic:matrix.org> Also, now that you know where the issue may get triggered, perhaps add a breakpoint at the beginning of the interrupt handler and step through it?
<re_irc>
<@dngrs:matrix.org> so last night I've been playing around with [libftd2xx](https://docs.rs/libftd2xx/0.32.0/libftd2xx/index.html) to try and see how far I can get with turning the [FT232H](https://sigrok.org/wiki/FTDI-LA) into an el extremely cheapo 60MHz logic analyzer. My extremely simple program for measuring chip->host reads is *extremely* jittery in terms of execution speed - reading tens of MB of data sometimes takes ~2...
<re_irc>
... seconds, but also up to 8. Could this be because of chip internal buffer overrun management, which does exist (it signals overrun on a pin) but I'm currently not handling whatsoever (I've just put output enable and write enable on permanent active low)?
<re_irc>
<@newam:matrix.org> Quick question: Does anyone have some code that uses smoltcp dhcp on an embedded system without alloc? Working through the trait bounds for static socket storage is slow going.
<re_irc>
<@xnorman:matrix.org> yeah.. i do segfault when i get into that func
<re_irc>
<@newam:matrix.org> dngrs:matrix.org: Author of the that crate, hi :D
<re_irc>
<@newam:matrix.org> If you're running on linux I would recommend giving `libftdi` a go, it is much better for all things linux.
<re_irc>
<@newam:matrix.org> I think it does have internal buffer management.
<re_irc>
<@newam:matrix.org> If you're on windows stick with libftd2xx.
<re_irc>
<@dngrs:matrix.org> I'm ... on macos! :D
<re_irc>
<@dngrs:matrix.org> love the crate btw.
<re_irc>
<@xnorman:matrix.org> adamgreig jannic newam xiretza thanks tons for the help.. I've gotta run but now at least I know where my problem is!! so helpful
<re_irc>
<@adamgreig:matrix.org> good luck!
<re_irc>
<@newam:matrix.org> dngrs:matrix.org: Should be fine either way on mac. I think there are some USB parameters you can tweak that may make a difference.
<re_irc>
<@dngrs:matrix.org> newam:matrix.org: Maybe it's time for me to draw a chart of the time it took for each read op. brb..
<re_irc>
<@dngrs:matrix.org> (FWIW I'm on an M1, so any kind of resource ceiling on the host is unlikely)
<re_irc>
<@dngrs:matrix.org> I think flow control and latency timer don't apply in fifo mode, but I'll read up again; the other two I'm doing
<re_irc>
<@newam:matrix.org> The vendor does have some futex's in weird places. It may be worth trying libftdi incase you're hitting one of the vendor oddities
<re_irc>
<@newam:matrix.org> if you launch an ELF linked to libftd2xx.so on linux it takes 100ms to exit just because they register some _really_ weird stuff with `atexit` that blocks on a futex
<re_irc>
<@dngrs:matrix.org> that's a good hint, thx!
<re_irc>
<@dngrs:matrix.org> I do measure between the first read and before close though 🤔 (see https://dpaste.org/qfui )
<re_irc>
<@dngrs:matrix.org> anyway, gonna calc some std deviationz
<re_irc>
<@dngrs:matrix.org> (for one single 64k byte read)
<re_irc>
<@dngrs:matrix.org> > When the pin is used to immediately flush the buffer (Send Immediate) a 250ns negative pulse on this pin is required.
<re_irc>
<@dngrs:matrix.org> ok that means I'll have to control at least this pin from within the app. But maybe that's better anyway if I also do it with `OE#` and `WR#`…
<re_irc>
<@dngrs:matrix.org> ah, the very first read is skewing my measurements, because there the fifo is already ready for pickup. Gonna skip that one then
<re_irc>
<@thejpster:matrix.org> Reminds me of a system I I've worked on for grabbing DSP debug data in real time. Pretty sure it used a USB3 version of that FTDI chip - it streamed at about 300 MiB/sec.
<re_irc>
<@dngrs:matrix.org> there is - I just don't have one
<re_irc>
<@thejpster:matrix.org> This was before SSDs were common, so you had to get one on special order.
<re_irc>
<@dngrs:matrix.org> gotta try and see what `SIWU#` does I guess.
troth has quit [Ping timeout: 256 seconds]
procton_ has joined #rust-embedded
<procton_>
Is it common knowledge in the rust community that in order to use rust in embedded that I need to use a nightly build of rust? I get this `#![feature]` may not be used on the stable release channel` when I try to compile `cortex-m`.
<re_irc>
<@burrbull:matrix.org> What feature do you need?
<procton_>
ah. I forgot to add that. asm.
<procton_>
Seems to be compiling with nightly though, but seems unlikely I would ever use that in production. :/
<Lumpio->
I haven't used nightly for a long while - what do you use asm for?
<Lumpio->
The solution in cortex-m at least is to just compile the assembly code separately and link it in
<re_irc>
<@newam:matrix.org> irc_libera_procton_:psion.agg.io: People do use nightly in production for embedded.
<procton_>
Ok. It is not my code. Hubris peeked my interest.
<re_irc>
<@newam:matrix.org> I keep a list of the RTOS' (and other execution frameworks) here: https://arewertosyet.com/
<re_irc>
<@newam:matrix.org> There's only two that compile on stable right now.
<procton_>
I really like the concept of zephyr, but I have not found a solution of how to run one software on board variants (i.e. when boards slightly differ, e.g. a GPIO being SPI on another variant).
<procton_>
Hubris do look interesting though. Simple concept to build a robust and secure applicatio, it seems.
<re_irc>
<@newam:matrix.org> Yeah I have been meaning to check it out as well.
<procton_>
Hubris compiles now atleast. Me just being a complete rust noob, was the problem. :)
rardiol has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> hmm, why is my interrupt latency _increasing_ if I swap target from eabihf to eabi 🤔
<re_irc>
<@adamgreig:matrix.org> procton_: the `asm` feature is expected to get to stable rust very soon (I think the release after next?), so hubris specifically allowed that nightly feature with the understanding it will soon be OK on stable
<re_irc>
<@adamgreig:matrix.org> for many users there's no need to use a nightly rust, the cortex-m crate provides some convenient asm functions
<procton_>
re_irc, Ok. Thanks! We are not likely to be using rust within a year though.
<re_irc>
<@adamgreig:matrix.org> but lots of companies are shipping builds using nightly rust - usually using a `rust-toolchain.toml` file to lock to a specific nightly version, which then isn't changed often (and carefully tested)
<re_irc>
<@adamgreig:matrix.org> (in particular it's also required for various async features which are not stable yet)
<procton_>
re_irc, Ok. I have not looked in to the hubris code yet. I will soon though, as I will port it to our MCU.
<re_irc>
<@adamgreig:matrix.org> which MCU is that?
<re_irc>
<@adamgreig:matrix.org> by the way, re_irc is a bridge between the IRC channel and the Matrix room, my username is adamgreig (or adamgreig)
<procton_>
LPC1768/9
<procton_>
If we ever use Hubris, it will likely not be on LPC1768/9. It will be on a MCU that we can actually order. :/
<re_irc>
<@adamgreig:matrix.org> hehe, who knows what that will be in even a few weeks' time, let alone months or years
* procton_
shivers.
<procton_>
gtg
<procton_>
later.
* re_irc
@adamgreig:matrix.org waves
tokomak has quit [Ping timeout: 252 seconds]
<re_irc>
<@therealprof:matrix.org> fragadaleta:matrix.org: Works great but if you want to have best support you might want to take the soldering iron to one...
<re_irc>
<@therealprof:matrix.org> It is very minimalistic, so not the best platform to start experiments.
tokomak has joined #rust-embedded
troth has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> Oh, wait. I confused that with the nrf52840 dongle. The makerdiary has SWD broken out but less useful other pins (unless you'd like to share them with the debugger) the Nordic dongle has the solder pads or tagconnect connector if you want to use a debugger; it's meant to be be used with the bootloader which is somewhat limiting.
<re_irc>
<@xnorman:matrix.org> back from earlier (was segfaulting because of what looks like a very large stack alloc)..
<re_irc>
<@xnorman:matrix.org> first, shouldn't i be hitting some sort of stack fault handler? or.. can i set something up for that?
<re_irc>
<@xnorman:matrix.org> second.. i have a big SDRAM to work with.. the fault i'm dealing with is when i de-serialize a big struct from flash.. `postcard::from_bytes::<SchedData>(&slice)` .. can i somehow deserialize that into this sdram instead of onto the stack? or.. advice on an approach for this?
<re_irc>
<@adamgreig:matrix.org> yes, it's odd, you'd expect it to have hit a HardFault handler
<re_irc>
<@adamgreig:matrix.org> it's possible that something is going wrong before an actual invalid memory access occurs
<re_irc>
<@adamgreig:matrix.org> (there's BusFault which handles invalid memory access but unless you enable it, it's promoted to HardFault by default)
<re_irc>
<@adamgreig:matrix.org> you could put your stack in the external sdram (the _stack_start variable in memory.x) or you could create a buffer in sdram (the link_section attribute) and deserialise into that, assuming you can deserialise into a specific buffer and not just the stack?
<re_irc>
<@adamgreig:matrix.org> but how big is this thing you're deserialising?
<re_irc>
<@adamgreig:matrix.org> the msp was set like 58kB below the bottom of your already quite generous stack...
<re_irc>
<@adamgreig:matrix.org> well, maybe you have a ton of other things in the dtcmram so your stack ends up quite small
<re_irc>
<@xnorman:matrix.org> trying to figure out how to print that out :)
<re_irc>
<@xnorman:matrix.org> the size..
<re_irc>
<@xnorman:matrix.org> tried to write a test but `can't find crate for `test``
<re_irc>
<@adamgreig:matrix.org> running tests on a no_std crate is a little complicated, can you estimate the size from knowing about the data involved?
<re_irc>
<@adamgreig:matrix.org> like is it hundreds of bytes, kilobytes, tens, hundreds of kilobytes?
cr1901 has quit [Remote host closed the connection]
<re_irc>
<@xnorman:matrix.org> 13668bytes
<re_irc>
<@xnorman:matrix.org> i printed it to my display :)
cr1901 has joined #rust-embedded
<re_irc>
<@xnorman:matrix.org> it will grow from there too.. i'm hoping to add some more features that'll expand the data needs
<re_irc>
<@adamgreig:matrix.org> that _seems_ like it should be fine, if a bit large
<re_irc>
<@adamgreig:matrix.org> but nowhere close to big enough to explain the value in msp when you hit that fault
<re_irc>
<@adamgreig:matrix.org> I wonder if the segfault and no apparent hardfault is because your gbp is capturing the fault handler
troth has quit [Ping timeout: 252 seconds]
<re_irc>
<@xnorman:matrix.org> oh huh.. i have hit hardfault in gdb before.. but i'm not sure if it was with this setup
<re_irc>
<@adamgreig:matrix.org> you could try writing a hardfault handler and putting something in it (like turn on an LED) and see what happens with and without gdb connected
<re_irc>
<@xnorman:matrix.org> cool, i can do that
<re_irc>
<@adamgreig:matrix.org> are you running a gdb script or any other commands when connecting?
<re_irc>
<@adamgreig:matrix.org> with bmp I usually just have "tar ext /dev/ttyUSB0; mon swdp_scan; att 0" and maybe "set mem inaccessible-by-default off"
<re_irc>
<@adamgreig:matrix.org> but maybe you've got a script or something that's catching vectors, the bmp/gdb supports doing so but doesn't by default iirc
<re_irc>
<@xnorman:matrix.org> i do also define a couple of commands for building and reloading..
<re_irc>
<@xnorman:matrix.org> i used to use the gdb dashboard but i have that disabled
troth has joined #rust-embedded
<re_irc>
<@xnorman:matrix.org> I'm curious how i use `link_section` to place a buffer in sdram.. right now the sdram just its initialized and then i have a big chunk of memory as a slice of bytes..
<re_irc>
<@xnorman:matrix.org> I'm using that slice when i deserialize, i actually read from flash into a buffer, then deserialize from that buffer.. but i have way more sdram than i need to do that
<re_irc>
<@newam:matrix.org> if you don't care where in RAM it goes `#[cfg_attr(target_os = "none", link_section = ".data")]` works.
<re_irc>
<@xnorman:matrix.org> yeah.. but, this is an external ram.. i need to set it up first, i guess i'm not sure how that all works when using these attributes
troth has quit [Ping timeout: 252 seconds]
<re_irc>
<@newam:matrix.org> For external memmapped RAM you link the code to the section where you want it to go, then copy it from flash to RAM in your bootloader.
<re_irc>
<@newam:matrix.org> You just don't reference any functions that get loaded into RAM within your bootloader.
<re_irc>
<@newam:matrix.org> There are some egregious hacks to have the linker allocate functions into external DRAM / internal SRAM depending on if the bootloader uses the associated function/data or not.
<re_irc>
<@newam:matrix.org> The simple way to avoid problems is to write two programs, your bootloader and your main application. You'll have duplicated code, but that's the price of easy.
<re_irc>
<@xnorman:matrix.org> ahh okay, so program that runs before the program.. hadn't thought of having to write a bootloader
troth has joined #rust-embedded
<re_irc>
<@xnorman:matrix.org> but, i could also jsut do something at run time and not use the attribute approach?
<re_irc>
<@newam:matrix.org> xnorman:matrix.org: yeah you can skip attributes if you write two separate prgorams.