RandomExplosion[ has quit [Quit: Idle timeout reached: 172800s]
i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
swork[m] has quit [Quit: Idle timeout reached: 172800s]
m5zs7k has quit [Ping timeout: 276 seconds]
m5zs7k has joined #rust-embedded
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
I am in the process of getting the stuff for mspm0-rs (https://github.com/mspm0-rs) setup on GitHub (won't see anything here for a several days).
<i509vcb[m]>
I thought it would be funny if the logo is Ferris with a cowboy hat and lasso. Does anyone have someone I can commission or would volunteer to do that as a logo for the org?
Dr_Who has quit [Read error: Connection reset by peer]
<thejpster[m]>
mnmm, if you use the install scripts then everything works. But the rust installer requires you to have patchelf installed. The mind boggles.
<JamesMunns[m]>
I wonder if the folks shipping that are here 👀
<corecode[m]>
did it happen in interrupt context or user context
<corecode[m]>
I think you can see that in lr
<ben[m]>
0x005A0012 last time
<corecode[m]>
does it vary?
<corecode[m]>
is that address from the exception frame?
<ben[m]>
Yes - but actually I'm not sure if that's just because I've tried changing something so it's been recompiled. I'm re-running right now to generate a fault again.
<ben[m]>
corecode[m]: The contents of the PC reg yes
<corecode[m]>
oh you're catching the hard fault in the debugger?
<corecode[m]>
not entering the hard fault handler?
<JamesMunns[m]>
Also do you have panic-immediate-abort enabled with nightly?
<JamesMunns[m]>
if you do, panics become hard faults
<JamesMunns[m]>
(well, they become UDF instructions, which become hard faults)
<JamesMunns[m]>
if you have a gdb session attached, you can have gdb follow the link registers back with bt
<JamesMunns[m]>
it should show you what entered that, it looks like you are panicking, and the defmt panic handler is causing a hard fault. So now you need to figure out what part of your code (or your deps) are panicking
<JamesMunns[m]>
* if you have a gdb session attached, you can have gdb follow the stack frames back with bt
<JamesMunns[m]>
also very much could be stack overflow
<JamesMunns[m]>
you can also see the stack pointer with gdb if you have that attached, or you can add flip-link and see if that check triggers
<JamesMunns[m]>
you can use cargo nm --release -- -nS to see your memory layout, if the stack pointer is into your static variables, it's definitely that.
<ben[m]>
flip-link is enabled, at least I have "-C", "linker=flip-link", in my rustflags
<ben[m]>
JamesMunns[m]: ok , thanks will check
<ben[m]>
<ben[m]> "Yes - but actually I'm not..." <- ok - just re run and it's a different address LR and PC are 0x005A3C54 this time
<chrysn[m]>
I see that cortex-m-rt has the stack painting, but panic-probe check for whether that painting is still there?
<chrysn[m]>
I'm running into what I'd guess is stack overflow issues when using embassy (admittedly, an older version) with nRF Softdevice.
<chrysn[m]>
Are there any tools around that can help me confirm this?
<chrysn[m]>
Or is there a tool with which I can install a guard page easily?
<JamesMunns[m]>
wait, can you post the full output into a gist ben ?
<JamesMunns[m]>
that output looks like you have like... zero bytes of stack?
<JamesMunns[m]>
Also, do you have flash code at 0x005A3C54? That seems like an unusual address to be at for code
<JamesMunns[m]>
(it's like 5.6MiB from where most flash starts at 0x0000_0000)
<JamesMunns[m]>
<chrysn[m]> "Or is there a tool with which..." <- closest I'm aware of is `cortex-mpu`, which might be out of date. the way to make a guard page is to sacrifice some chunk (1k, 4k, etc) as an MPU protected region with no permissions, and see if you get an MPU fault
<JamesMunns[m]>
dunno if probe-rs run knows how to read stack painting, you could definitely write a tool that does it though. I think probe-run used to do that? not sure, might be better to ask in #probe-rs:matrix.org
<chrysn[m]>
JamesMunns[m]: Thanks, I'll ask over there.
<JamesMunns[m]>
ben[m]: Okay so your valid code range is: `0x08000000` to `08018e00`
<JamesMunns[m]>
Ah, okay, I didn't realize `nm` would include the flip-link stuff, then that looks right, flip-link just isn't moving `_stack_end` properly. You should have ~79KiB of stack available, since stack starts at `0x13cb8`
<JamesMunns[m]>
fyi, the first column is addresses, the second column is sizes in bytes
<JamesMunns[m]>
s/0x13cb8/0x20013cb8/
<JamesMunns[m]>
So, if your program counter was 0x005A3C54, then something is definitely going off the rails
<ben[m]>
So I'm probably doing something stupid when buffering the samples and creating copies that hang around?
<ben[m]>
Anyway - thanks all for the help. I've got something to go away and look into now.
<JamesMunns[m]>
I dunno! The PC jumping off into nothing is not usually "normal bad", it means that something is getting pretty significantly corrupted. Do you know what version of the compiler you are using?
<JamesMunns[m]>
There was (a while back) a miscompilation with opt-level=z, which would cause a similar error.
<ben[m]>
Increasing the ADC sample rate speeds up the time-to-fault so I guess there's some cumulative effect in the data pipeline. I'll experiment with disabling parts to narrow it down. Thanks again for everyone's help.
<thejpster[m]>
what is MENU_BUFFER?
<ben[m]>
static mut MENU_BUFFER: [u8; 64] = [0u8; 64]; it stores bytes from the uart to use in the serial console.
<Dlaw[m]>
<corecode[m]> "atomic maybe?" <- Maybe an AtomicPtr? Another option is to use RTIC which handles management of static resources for each interrupt for you.
m5zs7k has quit [Ping timeout: 265 seconds]
<ben[m]>
* `static mut MENU_BUFFER: [u8; 64] = [0u8; 64];` it stores bytes from the uart to use in the serial console.
<ben[m]>
But the serial console isn't in use when the data logging is happening - it was just an easy way to have commands to start/stop/ change sample rate etc.
m5zs7k has joined #rust-embedded
bitts[m] has joined #rust-embedded
<bitts[m]>
I have some functions in .S files that I include with global_asm!. It builds and runs just fine - however if I try to build with --release, I get undefined symbol errors for those functions. Does this ring a bell with someone?
<bitts[m]>
I'm guessing they are prematurely optimized away - if so, is there a way to prevent that?
marmrt[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
Who's doing Rust things at Embedded World this year? I see One Variable, Tweede Golf and Sarif are running a "Rust on Embedded" stand. I'll be there with Ferrous, right next to Slint and KDAB. I believe AdaCore are going.
<thejpster[m]>
<ben[m]> "static mut MENU_BUFFER: [u8; 64..." <- I know, I wrote it. I was just checking you weren't taking a mut reference to a non-mut variable or something naughty.
<diondokter[m]>
thejpster[m]: Yeah, definitely drop by! Everybody is welcome
mabez[m] has joined #rust-embedded
<mabez[m]>
<thejpster[m]> "Who's doing Rust things at..." <- Espressif will be there, and at least a couple of people from the Rust team will be at our booth :)
<thejpster[m]>
I think the types for GPIOA.lckr and GPIOB.lckr are different and they don't implement any traits in common, so there's nothing you can put there
<thejpster[m]>
you could make a trait locally and implement on those types
<dirbaio[m]>
in stm32-metapac they're the same type :)
<trreeaz[m]>
Hmm, I hoped that I could write a generic function, because the fields are all of type `crate::Reg<lckr>::LCKR_SPEC`
<dirbaio[m]>
yeah with stm32f3 they're different types, you can't do it easily. Easiest is probably make the closure take *mut u32 and cast each register to a raw pointer.
<dirbaio[m]>
you could also make your own trait and make the closure generic on that but I think it'll be more work
<dirbaio[m]>
or you could use macros
<trreeaz[m]>
Hmm, *mut u32 would be OK for this simple case.
<trreeaz[m]>
But what I want to have later is a function that can take moder, otyper, ospeedr, pupdr as arguments, and I would like to use the functions on those.
<trreeaz[m]>
(I have a lot GPIOs to initialize, would like to do it in a nice table form, instead of spread out over 200 LOCs)
<dirbaio[m]>
not possible
<dirbaio[m]>
this is why the stm32-rs HALs use such huge macros
<trreeaz[m]>
hmm, ok.. in C this was easy with some macros.
<trreeaz[m]>
perhaps i just write a code generator to translate gpio.csv -> Rust :)
<dirbaio[m]>
this is a very common design shortcoming of stm32f3 and the other stm32-rs PACs
<dirbaio[m]>
and one of the reasons I made stm32-metapac
<dirbaio[m]>
with stm32-metapac each GPIO block is the same type, so you can do this easily
<dirbaio[m]>
you don't need macros nor generics
<trreeaz[m]>
Ok, i'll have a look. for the moment, i think I will just copy/paste my lock code 3 times.
<JamesMunns[m]>
fwiw the more current vibes are: "use generics on the constructor, ditch them on the struct"
<JamesMunns[m]>
so if you want the user to prove they have all those, make them pass in a non-generic struct that has all of those items in them, then ditch it
<JamesMunns[m]>
but i'm not sure what the generics are getting you at all here, honestly.
<bogdan[m]>
<JamesMunns[m]> "but i'm not sure what the..." <- I've been using them to enforce at compile that the user cannot misconfigure the clock tree. For example, not allowing disabling the XO if it's currently used
<bogdan[m]>
but of course I'm discovering all kinds of edge cases where the HW desides to be helpful and enable/disable some clocks in certain situations :)
<JamesMunns[m]>
just worth noting that the resulting structure is going to be... unpleasant to use
<bogdan[m]>
yes, that's the kind of feedback I need :)
<bogdan[m]>
unpleasant is bad
<JamesMunns[m]>
If you write any code that contains that struct, it will also need every one of those generics
<bogdan[m]>
it's even more unpleasant to modify ...
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
You could try making a normal config struct and have a const fn to validate it. That way you can still check the config at compile time
<bogdan[m]>
GrantM11235[m]: I will also try that approach
<bogdan[m]>
<JamesMunns[m]> "so if you want the user to prove..." <- but if you ditch them, then you can't give them back (i.e. no reuse). So then you either accept that you HAL eats up resources, or you provide the user some other way of re-creating the resource (gpio pin, clock, whatever). But if you do that then what's the point of the initial constraint that the user must "prove" they have the resource if they can always recreate it
<bogdan[m]>
or mayge I misunderstood what you mean by non-generic struct
<bogdan[m]>
s/mayge/maybe/
<GrantM11235[m]>
You can use a mutable reference to the resource. That allows you to reuse it when you are done
<bogdan[m]>
But is definitely better than the struct I originally showed above :)
ivmarkov[m] has joined #rust-embedded
<ivmarkov[m]>
Some HALs have the T generic erased in the meantime...
<bogdan[m]>
Yea that's a good point
<GrantM11235[m]>
It does erase the pin types though. I believe the plan is to eventually get rid of the instance generic too
<ivmarkov[m]>
Yes, that's what I would do if I was contributing to those HALs. esp-hal has it removed in the meantime (since ~ yesterday or so)
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
newam[m] has quit [Quit: Idle timeout reached: 172800s]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
romancardenas[m] has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
barafael[m] has joined #rust-embedded
<barafael[m]>
Somehow, I'm not getting any interrupt from my timer? I set up the alarm in the init code and unmask the irq. Then, I schedule the alarm (which is a shared resource), whenever a button is pressed. But the interrupt never fires. Maybe you can have a look...
<barafael[m]>
I'm hacking on this tiny RTIC firmware for RP2040 where I try to explain how futures and async/await work without using async/await.
<Arne[m]>
or did I just fry my esp32 while soldering? That would suck, but would not be the worst case here. How would I be able to test it?
<Arne[m]>
* or did I just fry my esp32 while soldering? That would suck, but would not be the worst case here. How would I be able to test it?
<Arne[m]>
(Ok I just tested that the esp32 seems to send something on pin 21 and 26, so I'm guessing it's not completly fried..)
<dngrs[m]>
"waiting for download" means it's in DFU mode
<Arne[m]>
Oh, is that something that gets initiated by pin configs, or could it be, that it just didn't get the necessary firmware where I bought it, so that I have to follow along these steps:
<dngrs[m]>
Arne[m]: yes, certain pin configurations will boot into DFU. I don't think Espressif has any chip where there's a boot loader flashed to firmware, it's all ROM
<Arne[m]>
so gpio0 is constantly pulled down
<dngrs[m]>
probably
<dngrs[m]>
oh also I should have better said "it's in bootloader mode"
<dngrs[m]>
DFU has special meaning and the page you linked indeed mentions firmware that can be spoken to with dfu-util.
<Arne[m]>
Hm... I don't see why it should be pulled down all the time? You can say that GPIO0 is Boot in this picture
<dngrs[m]>
you could try manually invoking `espflash` or `esptool.py` and see what happens when you try and flash some firmware to it
<dngrs[m]>
in particular I like to run `esptool.py chip_id` to get some rudimentary information out of a board. But setting up `esptool.py` can be a bit of a hassle (don't have instructions at hand)