Problem in running my embedded wizard project on a custom board

Question

Hello

I designed a simple demo to check which GUI solutions, or platform is suitable for my purpose;
I did test this demo with LVGL library, TouchGFX, and now Embedded Wizard, I want to compare these solutions and then decide which one is good for me.

When i finished designing the same demo in Embedded Wizard, I could run that on STM32H750B Discovery board without any issues and everything was alright;

But the problem is, I want to run the same application on my custom board, which uses STM32H743II MCU and LCD is 480 * 800, and I face to Hard Faults (while I could use mentioned board with LVGL and TouchGFX).

I used STM32H743-Evaluation Build environment as a template and tried to modify Driver codes (source files located in \TargetSpecific subdirectory); after that i tested every driver e.g. LTDC, SDRAM,... to make sure everything working alright, but now i'm getting random Hard Faults in few lines of EW functions, everytime i run the project; and i can't do anything about it because they are pre-compiled functions and i have no idea where the issue is.

I am getting  hard fault from "EwNewObjectIndirect" function some times, from "EwInitGraphicsEngine" sometimes as well; at the end i cant reach the application at all.

and CFSR register doesn't give any information, only IMPERCIZERR flag is 1 and all others bits are 0. 

here is my build environment : https://ask.embedded-wizard.de/?qa=blob&qa_blobid=15151986219382722151

Schematic of my custom board: https://ask.embedded-wizard.de/?qa=blob&qa_blobid=3817782607853900746

Would be much appreciated if anybody helps.

thanks in advance;

Best Regards.

Answer 1

Hello,

first of all, thank you for the good preparation of your question - and for sure, Embedded Wizard is the best choice ... ;-)

I had a short review of the configuration and initialization of your application. According to your settings you have 32 MByte SDRAM.

According to the reported errors (and similar situations in many customer projects), let me recommend to test the SDRAM more intensively before continuing the bring-up of the GUI application. For that purpose, please try our SDRAM memory test and repeat the read sequence many times with a delay of 10 seconds or more (to be sure that refresh is correctly).

Let me know if this works on your hardware.

Additionally, let me know the console outputs.

Thanks and best regards,

Manfred.

Comments

Hi, 

This is PC value after MemManage Fault: "0xCC5DAC3A", which is unusual.

Yes, I didn't change stack size of the Build Environment project, the only thing I have changed in the Linker file, was that I placed "SectionEwResource" in the ROM_region section (internal flash) instead of QSPI.

I actually didn't initialize QSPI in my project at all, and didn't change its address as well, as you can see in my ".map" file: https://ask.embedded-wizard.de/?qa=blob&qa_blobid=1916576727280445292

And this is my Linker file if needed: https://ask.embedded-wizard.de/?qa=blob&qa_blobid=1165189880074340589

Regards.

---

According to your MPU settings you have allowed an access between 0xC0000000 and 0xD0000000 - but if there is no physical memory it might cause an hardfault in case of speculative prefetches.

Please check once more your MPU settings - and you can additionally exclude all unused areas.

---

Hi,

my project's MPU is completely same as the EW build Environment's MPU, I just changed the SDRAM address from 0xD0000000 to 0xC0000000 according to the memory layout of my board.

And I don't have full allowed access between 0xC0000000 and 0xD0000000, if you mean this part: 

  /* Configure the MPU attributes for SDRAM_Banks area to strongly ordered
     This setting is essentially needed to avoid MCU blockings!
     See also STM Application Note AN4861 */
  MPU_InitStruct.Enable           = MPU_REGION_ENABLE;
  MPU_InitStruct.Number           = MPU_REGION_NUMBER4;
  MPU_InitStruct.BaseAddress      = 0xC0000000;
  MPU_InitStruct.Size             = MPU_REGION_SIZE_512MB;
  MPU_InitStruct.SubRegionDisable = 0x0;
  MPU_InitStruct.TypeExtField     = MPU_TEX_LEVEL0;
  MPU_InitStruct.AccessPermission = MPU_REGION_NO_ACCESS;
  MPU_InitStruct.DisableExec      = MPU_INSTRUCTION_ACCESS_DISABLE;
  MPU_InitStruct.IsShareable      = MPU_ACCESS_NOT_SHAREABLE;
  MPU_InitStruct.IsCacheable      = MPU_ACCESS_NOT_CACHEABLE;
  MPU_InitStruct.IsBufferable     = MPU_ACCESS_NOT_BUFFERABLE;
  HAL_MPU_ConfigRegion(&MPU_InitStruct);

As it mentions above, it's for configuring SDRAM banks to strongly ordered, as you can see "AccessPermission" has this value: "MPU_REGION_NO_ACCESS"

the main SDRAM MPU config is the bellow section, which I have allowed access for the first 8 MB only:

  /* Configure the MPU attributes for SDRAM 32MB to normal memory Cacheable */
  MPU_InitStruct.Enable           = MPU_REGION_ENABLE;
  MPU_InitStruct.Number           = MPU_REGION_NUMBER5;
  MPU_InitStruct.BaseAddress      = 0xC0000000;
  MPU_InitStruct.Size             = MPU_REGION_SIZE_8MB;
  MPU_InitStruct.SubRegionDisable = 0x0;
  MPU_InitStruct.TypeExtField     = MPU_TEX_LEVEL0;
  MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
  MPU_InitStruct.DisableExec      = MPU_INSTRUCTION_ACCESS_ENABLE;
  MPU_InitStruct.IsShareable      = MPU_ACCESS_NOT_SHAREABLE;
  MPU_InitStruct.IsCacheable      = MPU_ACCESS_CACHEABLE;
  MPU_InitStruct.IsBufferable     = MPU_ACCESS_NOT_BUFFERABLE;
  HAL_MPU_ConfigRegion(&MPU_InitStruct);

I even tested MPU of STM32H750B-Discovery board's project (which is working properly) and I changed a lot of SDRAM MPU setting and still was able to run my demo without any issue on the STM32H750B-Discovery (And even ignored the MPU_Config() function and commented it in the code and still was able to run my demo). 

So looks like the problem is not about MPU in my custom board's project.

Regards.

---

Please note that your code contains two functions that are doing MPU settings: MX_MPU_Config() and MPU_Config(). The second function is provided in our Build Environment - but the first one is used.

Can you double-check this?

---

Yes that's true, but that project you have is not updated and it's a bit old;

Now I'm using the MPU_Config() instead of MX_MPU_Config() since few days ago, which is your Build Environment's MPU config function.

Answer 2

Hello again,

First of all, I want to appreciate all of Manfred Schweyer's answers and times he spent on my project, I'm very thankful.

But now, my problem still exist and I wasn't be able to solve it;

I want to ask everyone who can help, would be much appreciated if you follow our above conversation with Manfred and see if you can realize where my problem is or where I'm making a mistake or something;

And if there was any question that I didn't mention above, I'll try to answer it ASAP.

Thanks in advance,

Best regards.

Comments

Hi,
I just would like to ask you, if you did the SDRAM testing with some delay between writing to the SDRAM and reading as Manfred suggested? This delay is needed to verify, if the SDRAM refresh is working correctly.
You should wait at least one minute before reading.

Furthermore, you should set a MPU region with size 256MB beginning from 0x9000 0000 and MPU_REGION_NO_ACCESS, if no QSPI flash is used.

Regards,
Martin