LDR instruction not executing and causing a Hard Fault

Question

I've run into an issue that has left me seriously scratching my head. Essentially, after moving to a new processor (with the chip shortage) I'm consistently getting a BusFault related to USB communications.

1. This is the fault panel in my IDE, showing the address causing the fault being 0x0040 0008.

2. Then is the main debugger window. The callstack suggests that the instruction that caused the fault is at at 0x9340 (below the red line in the disassembly window). This looks plausible as the current value in R2 (left side pane) is indeed 0x0040 0000 and, with an offset of 8, gives us exactly the address in BFAR.

3. But how can R2 have 0x0040 0000 in it when, just in the previous instruction, at PC 0x933E, its value is loaded from the address stored in R7, with a 0 bytes offset.

4. Looking at the value in R7, R2 should actually have 0x2000 FF48, which is what the memory view shows us. When I manually stepped through the function in a working instance, that 0x0040 0000 was actually the result of the operation above (ANDS R3, R2). It's almost like the underlined instruction, loading from the address stored in R7, into R2, never got executed.

The function in which this happens is called by the USB interrupt. Processor is a MK24FN1M0VDC12.

I've been battling with this for a few days now (over 40 hours I expect) and only last night I was able to properly observe this behavior. Looking for absolutely any idea, no matter how crazy it might sound. The chips were purchased from a broker, but other than this, all other peripherals work perfectly well. Given that in the process of switching I also had to move from using HS USB to FS USB on the current MCU, I'm hoping it's actually an issue in my code and not something else.

LE: Initial problem fixed. New ones appeared

After disabling the instruction/data caching and prefetching, according to K.netis' errata items, the hard fault no longer occurs in that area of the code. Similarly, after decreasing the core's clock from 120MHz to 96MHz, the faults seem to have stopped altogether. I will update this as I go along.

Thanks!

Answer 1

In order to have some sort of conclusion on this. After reducing the K.netis flash clock to 20MHz (from 24Mhz, confirmed using an oscilloscope), the hard fault disappeared. After further investigation into another issue (noisy ADC readings) we believe the problem is actually the design of the chip's power supply lines. Instead of a 3V3 plane with decoupling capacitors close to the pins themselves, our design has a single trace running from all the 5 supply pins to the outside of the chip and then the decoupling capacitors are all placed in parallel there.

We're currently doing another design iteration to confirm that was indeed the problem. Will update this post when that happens. Thanks all for your help!