Mathias[m] has quit [Quit: Idle timeout reached: 172800s]
starblue has quit [Ping timeout: 244 seconds]
starblue has joined #rust-embedded
ivche has quit [Ping timeout: 244 seconds]
ivche has joined #rust-embedded
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
pcs38 has joined #rust-embedded
HumanG33k has quit [Ping timeout: 260 seconds]
HumanG33k has joined #rust-embedded
<RobinMueller[m]>
thejpster: It is vaguely documented, but there actually is a standard set of things to do. The ARM ref manual recommends doing an exception return. Most vendor code and exception handlers I saw in the wild branch to some (user) provided C handler. Or both combined.. How does your debug script look? I was not sure whether breakpoints in the global assembly even work (at least in the GUI), I tried setting one in the startup
<RobinMueller[m]>
routine and I think it did not work.
<thejpster[m]>
My scripts are TRACE32 specific and they set breakpoints on the vector addresses.
<thejpster[m]>
In GDB it would be break *0x00000008 etc
korken89[m] has joined #rust-embedded
<korken89[m]>
I've been bit by a really sneaky vector table alignment issue max(128, round_up_to_power_of_two(sizeof(vectortable))), where we only had 128 in our checks. So I thought I'd update the link.x.in to add this check for vector table. Does it make sense to add it? I would expect cortex-m-rt to give an error if it places the vector table in an unaligned location.
<JamesMunns[m]>
Is it the same for all cortex-m? I can't remember if there were different alignment rules for different series
<korken89[m]>
I checked armv7-m and armv8-m so far
<korken89[m]>
I'll check armv6-m now3
<korken89[m]>
s/now3/now/
<korken89[m]>
v6 has only the 128 byte requirement, but with it only having max 32 vectors it fits in the other check as well
<korken89[m]>
I'll see if I can linker script magic this math
<diondokter[m]>
Maybe the hardware does `(VTOR | (IRQ_NUM * 4)` to find the vector address?
<diondokter[m]>
s/*/<</, s/4/2/
<diondokter[m]>
* The VTOR is the full 32-bit.
<diondokter[m]>
Maybe the hardware does `(VTOR | (IRQ_NUM << 2))` to find the vector address?
<diondokter[m]>
If the vector table is aligned, that should work
<korken89[m]>
We've seen very weird behavior when this was wrong, and specifically in our case a specific interrupt never came which was critical to the operation of the radio peripheral
<adamgreig[m]>
<korken89[m]> "It not catches our 4 week bug..." <- whewwww, thanks for adding!
<diondokter[m]>
UWB radio peripheral? Which chip are you using? One of those from NXP?
<korken89[m]>
Yeah, OL23D0
<adamgreig[m]>
<diondokter[m]> "The VTOR is the full 32-bit...." <- is it? in cortex-m4 at least it has 7 reserved bits
<diondokter[m]>
adamgreig[m]: Ah! Cortex-m crate apparently also doesn't have a setter for it. Just the raw `Reg<u32>`
<adamgreig[m]>
korken89[m]: yea that's much clearer lol
<diondokter[m]>
s/Reg/RW/
<korken89[m]>
But this is what cause my error to start with, I read it as Exceptions (the first ARM defined interrupt vectors)
<korken89[m]>
They mean Exceptions as in the entire size of the vector table
<JamesMunns[m]>
all interrupts are exceptions, not all exceptions are interrupts :D
<korken89[m]>
Which makes perfect sense, just sometimes it goes too fast xD
<RobinMueller[m]>
I have a weird issue with my Zedboard again when trying to debug this issue with the divison by Zero. It panics, but I have this weird issue again that the stack frame looks very broken.. I had a simillar issue with my main routine ,which disappeared when I exported the main function with the name main ..
<DavidBrown[m]>
Personally, I use a Jlink, and on most of my boards I bypass the built-in debugger. I will typically use either probe-rs, or for boards where gdb with that a bit broken (rp2040), I run the jlink gdb server, and defmt is able to connect to the TCP port it provides the RTT channels over.
<DavidBrown[m]>
I mostly do this as I have a lot of boards and kind of got tired of having to have a different debug solution for each one. I also work with a lot of new boards, where openocd support is often not merged into main yet.
<DavidBrown[m]>
My general setup involves three terminals, this is probably not ideal if you're using vscode, but it could probably be done there, not sure? In one terminal I start the gdbserver. In another, I run defmt-print to print the info. And, a third, I run gdb to connect.
<DavidBrown[m]>
Gdb over the jlink server is able to flash the image directly.
<danielb[m]>
I've never seen that error you have 👀
<ckrenslehner[m]>
Thanks for the insight!
<Noah[m]>
Hmm its also extremely odd that the error would only happen with J-Link and not ST-Link
<ckrenslehner[m]>
danielb[m]: Me neither, but my embedded rust experience is limited to playing around with the nrf boards so far
<danielb[m]>
is that a real j-link pro probe, by the way, or one of the cheap blue chinese "j-link pro" things?
<ckrenslehner[m]>
I will try reinstalling the tools and maybe change the wiring. Flashing and debugging my C firmware project works however so there should not be a connection issue
<ckrenslehner[m]>
A real one
<danielb[m]>
there is a chance we don't handle those well
<danielb[m]>
i personally never saw one, or someone who has one :D
<ckrenslehner[m]>
Well my company has one not me :-D
<danielb[m]>
close enough. rare question, if you have the CLI probe-rs-tools installed, what's the output of probe-rs info with that j-link?
<danielb[m]>
okay well I guess someone broke something here, but the probe itself seems to work 😅
<ckrenslehner[m]>
I will try an older version, lets see :-)
<danielb[m]>
that may be a good idea - the error you have is very weird, it shouldn't ever occur I think, and I think if you made a typo somewhere probe-rs wouldn't parse the config correctly and die sooner
<ckrenslehner[m]>
I will test 0.26 too and open an issue. Thanks for your quick response and thanks David Brown for the insight in your debugging setup. I really appreciate it :-)
<DavidBrown[m]>
Sure thing.
<DavidBrown[m]>
* Sure thing. I think I tend to overly customize how I debug, and sometimes end up fighting with other tools that try to help me, though.
<DavidBrown[m]>
Zephyr, especially, it has a build target to run the jlink server, but it adds arguments to make it exit when gdb does, which I don't really understand. So I have to drop a patch onto Zephyr while I'm working to prevent that.
<danielb[m]>
ckrenslehner[m]: any chance we could get a bisection to the exact commit that broke this, please? 🥺
<ckrenslehner[m]>
I think I spent almost a whole day configuring cortex-debug with openocd. Its a tedious topic
<DavidBrown[m]>
I really should try to figure out why probe-rs gdb doesn't work on the rp2040.
<ckrenslehner[m]>
danielb[m]: I wil try my best!
<danielb[m]>
DavidBrown[m]: would be great, it always hurts to read someone needs to pick a different tool
<ckrenslehner[m]>
Okay so 0.25 works fine and 0.26 does not work for me. I was using cargo binstall
<ckrenslehner[m]>
* cargo binstall to install probe-rs
<danielb[m]>
that's interesting, at least 0.26 is a relatively small release
<thejpster[m]>
Sorry, I've just written two press releases about how well Rust works with SEGGER's Ozone and Lauterbach's TRACE32 PowerView.
<thejpster[m]>
to be fair, Ozone's tracing timeline is amazing, and Lauterbach support some very high-end CPUs that you don't - plus TRACE32 is fully scriptable so I can just edit the scripts that poke the memory controller before doing a download into RAM.
<thejpster[m]>
but for my training I'm usually using probe-rs and people like the simplicity.
<ckrenslehner[m]>
<thejpster[m]> "Sorry, I've just written two..." <- This sounds very interesting. Do you include the Segger System View files in rust?
<ckrenslehner[m]>
This sounds very interesting. Do you include the Segger System View files in rust?
<DavidBrown[m]>
If you use the systemview crate, it brings in Segger's library.
<ckrenslehner[m]>
nice
<DavidBrown[m]>
What does Ozone have as hardware requirements? Does it need SWO?
<ckrenslehner[m]>
At least the things i used so far
<DavidBrown[m]>
I find the traces from System View pretty nice. I also have some local patches to embassy-rp to add irq tracing, which helps (although systemview doesn't seem to distinguish irqs).
<DavidBrown[m]>
System View helped me get my keyboard firmware from like 70% CPU utilization to now less than 1% when not typing. I have a TODO to fix even that, and it should just sleep until a key is pressed.
<JamesMunns[m]>
What was it? :D
<DavidBrown[m]>
My original firmware was just a bit loop that processed events and called a bunch of 'tick' handlers every 1ms. Turns out very little needs to happen at that frequency.
<DavidBrown[m]>
Now it is all async, and most things are triggered by interrupts. The key scanning goes to idle after a short period.
<DavidBrown[m]>
The remaining is a 10ms poll to the layout manager. But, that manager does know when it needs to be called next, although that changes when key events come in. Once I figure that out, it should be idle most of the time.
<DavidBrown[m]>
The hope then is to be able to move to nRF and try a BLE version.
<ckrenslehner[m]>
The async way of handling things using embassy is just amazing
pcs38 has quit [Quit: leaving]
<thejpster[m]>
To get Instruction Trace in Ozone you just need a J-Trace Pro.
<thejpster[m]>
and a chip with the trace output pinned out. STM32F407 does trace, but most boards don't wire it out. RP2350 can do it too.
<thejpster[m]>
Nothing to change from the software side. And you can do rprintln over RTT, or defmt over RTT, at the same time.
<thejpster[m]>
that's an RTICv2 async task that was pending on a timer and got woken up after the timer interrupt fired.
<thejpster[m]>
it printed a log, blinked an LED, and went back to sleep.
<DavidBrown[m]>
Does Ozone work with a regular JTrace for non-commercial work? I also couldn't get a clear answer out of them if upgrading a JTrace BASE to Pro would actually work with it.
<DavidBrown[m]>
But, it does sound like it requires trace to be wired out. I wasn't sure if rp2350 did. Hopefully I'll be able to get a discrete rp2350 at some point, and I can make up a version of my mezzanine board with it.
<DavidBrown[m]>
As of today, the rp2350A does show up in Digikey's catalog. But, requires ordering in units of 500.
<thejpster[m]>
On 2350 it’s an alt function on some pins
<thejpster[m]>
Ozone works with any j-link - even the one on my nrf52-dk. But you he’d a J-Trace to do trace, naturally.
<thejpster[m]>
s/he’d/need/
pcs38 has joined #rust-embedded
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
<DavidBrown[m]>
Hmm, those do have more digits in the price than the "base" that I have.
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
<realroot[m]1>
how add a simulator to watchful? to run it on a desktop etc.
pcs38 has quit [Ping timeout: 244 seconds]
pcs38 has joined #rust-embedded
towynlin[m] has joined #rust-embedded
<towynlin[m]>
Hey folks, I am hiring a staff firmware engineer at Sofar Ocean. We don't use rust in our production firmware yet, but when the opportunity arises, I'd like to. I love this community, and I'd be excited to talk to anyone in this channel who's interested. Also of course please pass along to great engineers you know who are looking.