I was wondering if anyone knows of a way to force the Cortex-M7 CPU to take a precise exception when a bus fault occurs. I'm writing an application that requires the bus fault handler to know the exact address of the instruction that generated the bus fault so it can take remedial action. Apparently this is possible in the Cortex-M3 and M4 CPUs by setting the DISDEFWBUF bit to 1 in the Aux Control Register, which disables the load/store buffer. I can't seem to find an analogous feature in the M7 (perhaps because the M7 has a cache and the M3/4 don't?). I would like to avoid writing code to search back through instructions to find one that may have caused an exception because that seems like it could get complicated. I'd also like to avoid disabling the cache.
Hi Joseph Yiu,
Sorry for digging up such old post, but while trying to find solution to a close issue like the one reported by naklingensmi I decided to reply to your answer.
As I noticed in my recent investigation, Cortex-M7 processors doesn't have any mechanism to force bus faults to be precise, which I understood by reading your explanation above. However, in my case, I am trying to know the exact address of an instruction that generated a bus fault while trying to write to the System Control Space (SCS) from an unprivileged mode. Looking to Cortex M7 TRM, SCS is located on PPB ROM Table. Following my understanding of Cortex-M7 functional diagram (Figure 1-3), there isn't a path between the Store Buffer (STB) and the PPB ROM table. Therefore, is there any other way and reason for me to be able to force a precise bus fault in this specific situation ?
Hi Daniel,
From memory (it was quite a few years ago), it is related to the pipeline design as well. If you look at the Cortex-M7 pipeline
https://community.arm.com/developer/ip-products/processors/f/cortex-m-forum/5219/how-long-are-the-cortex-m7-pipeline-stages
The load/store unit is spreaded across multiple stages (load/store #1 to #3).
By the time the store response reach back to the processor, the processor pipeline already advanced twice (hope I got this right). Given that Cortex-M7 is superscaler, it means by the time we get the error response it is possible that the Cortex-M7 already in the executing up to 4 instructions after the store. As a result the stacked PC (return address) will not match the address of the store instruction.
Load is different, as Cortex-M7 is fully in-order and the pipeline is not allowed to speculatively execute instruction until the read is done, the bus fault for read is precise. The pipeline is stalled for read accesses
- on AXI if cache missed,
- on peripherals/device regions including System Control Space (SCS), peripheral AHB and private peripheral bus.
Hope this helps.
regards,
Joseph
Thank you for the clarification Joseph. Now it is totally cleared!