Using an Arm Cortex M4. We've noticed that when a certain function triggers our RTC interrupt, we get a usage fault interrupt instead.
After some debugging and sifting through registers, we noticed that our RTC vector address is 0x46 and our usage fault vector is 0x06. We're thinking something may be masking the 0x40 off.
For builds that have the usage fault (and this is key), We've confirmed that triggering an RTC interrupt causes the usage fault interrupt to fire. Also from inside the usage fault, I change PC to the start of the RTC handler, I see normal operation. This seems to confirm that for some reason the IRQ service is jumping into the vector table incorrectly.
Another odd thing, if we see this issue, and just add some random lines of code that do nothing, the fault goes away. At first we thought this was resolved per this IAR article:
https://www.iar.com/knowledge/support/technical-notes/general/unexpected-usagefault-or-hardfault-exceptions
Basically compile with --no_unaligned_access...but that proved to not resolve the problem.
Just curious if others have seen this problem, or any ideas how to resolve this.
Nothing "masks away" the 0x40, you really get an exception. So there is something going wrong in your code. Maybe wrong mode or strange address.
Thanks for the quick reply. I understand what you're stating. The only perplexing thing to us is the problem goes away if we add a few extra lines of dummy code in a completely different unrelated module. So to me that nullifies the "wrong mode" comment. Please correct me if my assumption is wrong.
I'll keep an eye out for address issues.
If you add code somewhere, you move code somewhere else. It is more likely that your code is somehow buggy then the chip, though it might seem so. Did you check the stack contents to find out where the exception occurs?
Yeah, it happens right after the RTCC compare interrupt is enabled. If it's not enabled, the usage fault does not occur.
Actually commented out all the code in the RTCC handler, except for the clearing of the flag. And usage fault still happens.
I guess I'll just focus my efforts around the RTCC configuration for now, maybe I'll see something.
Did you check that the vector has bit 0 set? It sounds as if the exception happens "while" jumping to your ISR, not inside.
I went on a tangent and just increased the data alignment from 256 bytes to 512 bytes for the vector table. Now I don't get usage faults anymore (so far) and my interrupt happens without issue. I don't know why this works. There are 76 interrupts in that table.
At least: 76*4>256 ;-)
Yes, that's why I figured to change it since the table has a total of 300+ bytes. BUT this is a setting from the manufacturer of the chip, so I'm a little perplexed why that particular setting didn't work out of the box. I would figure they'd catch that in testing interrupts. Of course, I'm using a OS that we upgraded and a lot of other code; so maybe something just started stepping on the vector table and this carved out more room for it. Actually looking in the map file, the linker moved it to a totally different memory location.
Either-way, thank you for your help. It was educational.
From the ARM ARM:
The Vector table must be naturally aligned to a power of two whose alignment value is greater than or equal to (Number of Exceptions supported x 4), with a minimum alignment of 128 bytes.
> this is a setting from the manufacturer of the chip
How/where? I checked out a couple of ARMs I work with, and didn't actually see any alignment details for VTOR contents, other than the ones derived from the core_cm4.h file from ARM (which doesn't take into account any implementation-defined interrupts.)
I use the Silabs Gecko. It's part of the startup_[chip].c file for the __vector_table[]