STM32F7 and MPU
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-04-03 7:56 AM
Hello everyone,
I apply STM32F746BE with externel SDRAM 32MB (MT48LC16M16A2P-75 IT:D) and externel FLASH 16MB (MX25L12845GM2I-10G), Ethernet (LAN8710AI-EZK), LCD.
Vector' table is located at 0x20000000. Firmware is runned from externel FLASH 0x90000000
How me configure correctly MPU? What parameters should be changed?
MPU_InitStruct.Enable = MPU_REGION_ENABLE;
MPU_InitStruct.BaseAddress = 0x20000000;
MPU_InitStruct.Size = MPU_REGION_SIZE_8KB;
MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;
MPU_InitStruct.Number = MPU_REGION_NUMBER0;
MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
MPU_InitStruct.SubRegionDisable = 0x00;
MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
// Descriptors for Ethernet' driver
MPU_InitStruct.Enable = MPU_REGION_ENABLE;
MPU_InitStruct.BaseAddress = 0x20001400;
MPU_InitStruct.Size = MPU_REGION_SIZE_1KB;
MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;
MPU_InitStruct.Number = MPU_REGION_NUMBER1;
MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
MPU_InitStruct.SubRegionDisable = 0x00;
MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;
// Buffer RX for Ethernet' driver
MPU_InitStruct.Enable = MPU_REGION_ENABLE;
MPU_InitStruct.BaseAddress = 0x20001800;
MPU_InitStruct.Size = MPU_REGION_SIZE_8KB;
MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;
MPU_InitStruct.Number = MPU_REGION_NUMBER2;
MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL1;
MPU_InitStruct.SubRegionDisable = 0x00;
MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;
// Buffer TX for Ethernet' driver
MPU_InitStruct.Enable = MPU_REGION_ENABLE;
MPU_InitStruct.BaseAddress = 0x20003800;
MPU_InitStruct.Size = MPU_REGION_SIZE_8KB;
MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;
MPU_InitStruct.Number = MPU_REGION_NUMBER3;
MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL1;
MPU_InitStruct.SubRegionDisable = 0x00;
MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;
// LCD buffer
MPU_InitStruct.Enable = MPU_REGION_ENABLE;
MPU_InitStruct.BaseAddress = 0x61F00000;
MPU_InitStruct.Size = MPU_REGION_SIZE_1MB;
MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;
MPU_InitStruct.Number = MPU_REGION_NUMBER5;
MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL1;
MPU_InitStruct.SubRegionDisable = 0x00;
MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;
// QSPI at memory-mapped mode
MPU_InitStruct.Enable = MPU_REGION_ENABLE;
MPU_InitStruct.BaseAddress = 0x90000000;
MPU_InitStruct.Size = MPU_REGION_SIZE_16MB;
MPU_InitStruct.AccessPermission = MPU_REGION_PRIV_RO_URO;
MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;
MPU_InitStruct.Number = MPU_REGION_NUMBER6;
MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
MPU_InitStruct.SubRegionDisable = 0x00;
MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
Thank you,
Anton
- Labels:
-
STM32F7 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-04-03 1:14 PM
Please read this: http://infocenter.arm.com/help/topic/com.arm.doc.dui0646c/BIHJJABA.html
And then, read that piece of code again...,
-- pa
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-04-04 6:22 AM
Message deleted
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-04-04 6:35 AM
Hello, Pavel A.
I am familiar with http://infocenter.arm.com/help/topic/com.arm.doc.dui0646c/BIHJJABA.html and https://www.st.com/resource/en/application_note/dm00272912-managing-memory-protection-unit-in-stm32-mcus-stmicroelectronics.pdf
But I have doubts about the correct MPU settings in my case. Can you recommend a specific configuration option?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-04-04 8:03 AM
The code you posted doesn't actually do anything except write/overwrite a bunch of values to memory. You have to actually call HAL_MPU_ConfigRegion and HAL_MPU_Enable.
> But I have doubts about the correct MPU settings in my case.
There is no correct setting. It's up to you to decide what is right for you application.
> Can you recommend a specific configuration option?
I would recommend you don't use the MPU unless you have a good reason to.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-04-05 11:16 PM
Hello TDK,
Anton is my colleague. Thank you for your answer.
Anton ask if there are any wrong settings for MPU?
Your recommendation to not to use MPU seem to me very strange. It's like:"You have a car, do not use it, it's too complicated". MPU is protecting memory for wrong accesses and handles cached and not cached memory accesses.
Regards, Andrey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-04-06 6:17 AM
> Your recommendation to not to use MPU seem to me very strange. It's like:"You have a car, do not use it, it's too complicated".
I don't think that straw man argument accurately reflects what I'm saying. The MCU will work perfectly fine without engaging the MPU. And since the OP lists no other reasons for using it other than:
> How me configure correctly MPU? What parameters should be changed?
My recommendation is to not bother with it until you need to.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-04-07 7:12 PM
It is a good question. I too could not easily understand which MPU settings are best for external SRAM or flash.
Settings for ethernet descriptors for DMA have been already discussed here.
Simple attributes like "no code execution" or privileged vs nonprivileged are easy to understand.
Bufferable and shareable maybe are palatable as well.
But then there are various TEX levels that change meaning of the shareable/bufferable/cacheable flags ...
and what are the defaults for the "background region" ?
-- pa
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-04-08 3:30 PM
AN4667, AN4838, AN4839.
And here are an especially ignored topics by ST...
https://developer.arm.com/ja/docs/ddi0489/latest/memory-system/speculative-accesses
My consolidated report on practical usage for Ethernet, but very useful for everything:
https://community.st.com/s/question/0D50X0000C4Nk4GSQS/bug-missing-compiler-and-cpu-memory-barriers
By the way it seems that compiler barriers, memory barriers, speculative accesses and instruction reordering seems to be the topics ignored not only by ST's brainless code-monkeys, but by almost everyone...
P.S. For problems with ST's implementation of Ethernet/lwIP look at my other topic:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-04-08 5:45 PM
> By the way it seems that compiler barriers, memory barriers, speculative accesses and instruction reordering seems to be the topics ignored [snip] by almost everyone...
Except of hackers looking for vulnerabilities ;)
So are these "speculative access" topics applicable to STM32? to which families?
-- pa
