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 ..