MPU preventing EEPROM access on STM32L151/MTB_RAK811

[wmcelderry]

Description

STM32L151/RAK811 MPU update conflict with internal EEPROM.

Detection:
When working with the RAK811 (STM32L151CB), using an EEPROM library works prior to 5.11.0

Error symptom is a HardFault dump, which seems to be a Data access violation (from my reading of the Cortex-M3 TRM (page 8-32):

HFSR : 40000000
MMFSR: 00000082
BFSR : 00000000
UFSR : 00000000
DFSR : 00000000
AFSR : 00000000
MMFAR: 08080000

I created an absolutely minimal test from the STM32L151xx Reference manual (RM0038) to minimise the code that could have an impact when changing between commits.

Using git bisect identified the first 'bad' release as: 1821d37 (HEAD, refs/bisect/bad) Overhaul MPU for new requirements
That makes sense as writing to EEPROM is essentially using an unlock sequence and writing to the appropriate address (0x08080000 + EEPROM offset). It is possible to read from the address in later versions, but not write to it.

Looking at the debug message, it looks like the author was expecting such issues as they have provided comments to allow customising by ether defining MBED_MPU_ROM_END or a vector specific ARM MPU driver by defining MBED_MPU_CUSTOM.

While I may be able to hack something to get this working, it would be much better if someone who understands the issues can comment on
A) which method of customisation is appropriate (and what would it look like please)?
B) how would that be best integrated in to mbed-os for others to benefit from (targets.json for which devices?)?

target: MTB_RAK811 (suspect all STM32L1xx?)
toolchain: ARM_GCC
tools: mbed-cli (running on Linux)
first affected commit: 1821d37 (HEAD, refs/bisect/bad) Overhaul MPU for new requirements

Steps to reproduce:

Call the minimal_test() function from main() from https://gist.github.com/wmcelderry/87f1031db5c3e4a11350999bfc7e2ede#file-minimal_eeprom_test-cpp

NB: Apologies if something is missing! Please ask for any missing information or useful expansions. I have not been able to find any similar reports.

Big thanks to the contributors for all the hard work that's gone in to the system!

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

[wmcelderry]

I've just discovered the MPU API and used the ScopedRomWriteLock ( https://os.mbed.com/docs/mbed-os/v5.11/apis/scopedromwritelock.html ) to work around the problem and can confirm that 5.11.4 will work with that approach.

Not sure if unlocking the whole of the ROM is ideal for writing to EEPROM, so I'll leave this open for someone more knowledgeable about the implications for the whole system to comment.

[cmonr]

@ARMmbed/team-st-mcd

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-1055

[jeromecoutant]

@c1728p9 as MPU API developer :-)

[c1728p9]

Hi @wmcelderry I recommend using ScopedRomWriteLock as you have done. This is already done when reprogramming internal flash.

[wmcelderry]

Thanks for the feedback @c1728p9 & sorry for the delayed response.

I guess it may lead to a feature request down the line: it would be nice to be able to dynamically change an address space block, e.g. to reclassify the MPU for the EEPROM memory space, or specify that in certain chips memory mapped devices should be read/write without fully disabling the MPU, but I guess it's a (potential) feature request (and probably a low priority one), not a bug.

Is there any documentation (ideally examples) about how to use MBED_MPU_CUSTOM as I suspect that may do what I would ideally like, if I understood it?

I have searched the code for it and understand it has been used for some targets, but it seems like it may be a flag that triggers use of an API that I'm not sure I fully 'get' (having a work around it's not something I'm actively pursuing, but I'd like to come back to it some time).

[kjbracey]

If a target turns on MBED_MPU_CUSTOM, then it is responsible for the MPU.

Either it leaves DEVICE_MPU off, which means it has total responsibility, and Mbed OS will not make any calls. The MPU will need to uninitialised or initialised in a "friendly" state (RAM executable, ROM writable).

Or, it can turn on DEVICE_MPU, which means it implements the HAL MPU API: https://github.com/ARMmbed/mbed-os/blob/master/hal/mpu_api.h.

That is documented by the comments in the header. It's the necessary API to implement the application API visible in https://os.mbed.com/docs/mbed-os/v5.11/apis/mpu-management.html - booting with ROM read-only and RAM-non-executable, but providing the ability to temporarily override that.

If MBED_MPU_CUSTOM is off, then there is a default implementation for ARMv7-M or ARMv8-M.

Many targets have just turned on MBED_MPU_CUSTOM, because the default implementation doesn't suit them, but not provided an implementation, meaning the protection mechanism is just disabled. This is suboptimal.

memory mapped devices should be read/write without fully disabling the MPU

If you have a target-specific or HAL driver for a bit of hardware, and you have implemented MBED_MPU_CUSTOM, then you're free to internally have calls in your driver to adjust the restrictions on more specific areas. You could go nuts and have individual peripherals space non-accessible by default and unlocked manually by the driver before accessing registers.

The two APIs in Mbed OS are quite broad-brush, but it shouldn't be a huge deal, as each write/execute "lock" should only be taken very briefly - during 1 sector of programming, for example. These are more "catch and detect accidental error" checks than actual security barriers - there's nothing stopping code from making the "lock" call.

[jeromecoutant]

Could we close this issue ?

[wmcelderry]

Sorry, thought you'd closed it.