Mem/BusFault at internal memory regions (0xE0...)

[TNeub.1]

Hello,

I saw a not yet reproducable fault at adresses, which are part of the private/vendor-specific memory regions.

The fault happend on a STM32H7B0 runnig freeRTOS, ICache + DCache enabled:

Causing instruction address: 0x7.... (external flash)

Comming from address: 0xE0059256 (private peripharel bus memory region)

Faulty bus access address: 0xE0215C00 (vendor-specific device memory region)

The following bits were set:

• MUNSTKERR - If 1, fault on unstacking on exception return.
• MLSPERR - 1f 1, fault during floating-point lazy stack preservation.
• IBUSERR - If 1, fault on instruction fetch.
• STKERR - If 1, fault on stacking for exception entry.
• INVSTATE - If 1, execution in invalid state. E.g. Thumb bit not set in EPSR, or invalid IT state in EPSR.

Could anybody please tell me, how I can determine, which "peripheral/compontent" is on this memory region 0xE0059256 and 0xE0215C00?

I checked the ARM cortex-m7 processor technical reference manual and the STM32H7B0 reference manual. But there arn't much detail for this memory regions.

[FBL]

Hello @Community member​,

"how I can determine, which "peripheral/component" is on this memory region 0xE0059256 and 0xE0215C00?"

> You can find the memory map of Private peripheral bus - External in TRM cortex-m7 processor technical reference manual.

I suggest sharing your map file, hex file... You may need to disable the cache for instance to check if it is a cache coherency issue. Then try to disable FPU and see if it makes a difference.

[TNeub.1]

Hello,

thank you for your reply.

I cannot share any of these files since it is a commercial project. I also don't think the map file would be of any help. There aren't any symbols at 0xE...(since this is ARM/ST memory regions).

I sadly cannot reproduce this issue but I still have to invest, what is happening.

Do you now if 0xE0059256 and 0xE0215C00 are somehow related to the DCache or ICache? Or prefetching from external flash?

[FBL]

By examining the *.map file, you can see which sections of memory are used by your firmware and which symbols are mapped to those sections in order to check for overlapping and conflicting memory regions. Anyways, I understand your point. Indeed, these regions are private vendor-specific memory region.

You can try to isolate the problem by disabling certain peripherals or components that may be using the affected memory regions and observe whether the fault occurs again.

About your last question, depending on your implementation, if the stack pointer is corrupted or if the stack frame is improperly formatted, these flags can be triggered ...

Hope this helps you investigate further this issue!

[TNeub.1]

Well, thank you but I know what the map file is for.

So ST will not let us/me know, which internal peripheral (like the ICache?) is on these memory addresses? Since they are causing trouble in this case and knowing what they are used for could help to reduce the search.

[Gpeti]

what do you mean by "coming from adress" ?

[Gpeti]

Is the bit MMARVALID set ?

[TNeub.1]

This is content of the LR register.

[TNeub.1]

No, only the valid bit of the busfault register.

[FBL · Accepted solution]

Hello @Community member​ 

Refer to Arm Cortex-M7 Devices Generic User Guide, 0xE0059256 refers to PPB and 0xE0215C00 to vendor specific which belongs to eXecute Never region. So, probably the address is corrupted somewhere in the code.

Try to retrieve the LR register from the stack frame at the moment when the fault occurs to detect in which function the corruption occurs.