1.5k views
in System Integration by

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.

2 Answers

0 votes
by

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.

by

Many thanks for your assistance in my project and quick answer as well! I do appreciate it.
looks like your suggestion is accurate, I actually had a test code for my SDRAM which works properly and because of that I assumed SDRAM is working alright.

But now I'm getting a lot of errors where data is being read, so I should work on it a little bit and I'll post the result here in a few days.

and this is my console outputs (I changed the test code a bit, because I was getting a lot of errors and can't print all of them! I just counted them, and I used EwPrintProfilerStatistic(1) and EwDumpHeap(1)  as well): https://ask.embedded-wizard.de/?qa=blob&qa_blobid=3918096943743305861
.
Thanks again,

by
Great! So once the SDRAM (including refresh) works as expected, the GUI initialization should work as well.

Let us know when the next step is done...

Best regards,

Manfred.
by
Hello,

I was actually busy solving SDRAM issues, and now as a result, I can use 8 MByte of 32 MByte SDRAM without any problem (I changed SDRAM_SIZE_BYTES value in ewconfig.h file to 0x800000)

I used both of your tests (single write/read + write/read including refresh)  for that 8 MByte, and even i wrote a more complicated test to make sure this section of SDRAM is working alright;

But still  i'm getting Hard Fault in the same location ("Initialize Graphics Engine" or sometimes "Embedded Wizard Root Object" ) and looks like it does not depend on SDRAM issues.

So it's not clear that what is wrong with my project.

 

Thanks for your attention,

Best regards.
by
Hello,

good to know, that there have been some SDRAM issues. Are you sure that these are completely solved now - at least for the first 8 MByte?

For the next step, let me recommend to use a very simple GUI application, without any bitmap resources or font resources. Just a few rectangles that are animated by an effect.

Does this work?

Best regards,

Manfred
by

The first 8MByte of SDRAM passed several tests and looks like it's working fine now, here is console output of that test you recommended (write/read with refresh.):

Initialize Display...                        [OK]
Check memory addr 0xC00BB800 size 0x00689000
Write test pattern to SDRAM...               [OK]
Read test pattern from SDRAM...              [OK]
Waiting..........
Read test pattern from SDRAM...              [OK]
Waiting..........
Read test pattern from SDRAM...              [OK]
Waiting..........
Read test pattern from SDRAM...              [OK]
Waiting..........
Read test pattern from SDRAM...              [OK]
Waiting..........
Read test pattern from SDRAM...              [OK]

And this another test which i wrote myself and got no error from that 8 MByte:

srand(time(NULL)); 

  uint32_t  testAddress;
  uint32_t  complementedAddress;
  uint32_t  randomWriteData; 
  uint32_t  tempData; 
  uint32_t  loopCount;
  volatile uint8_t dummyData;

  EwPrint( "Check memory addr 0x%08X size 0x%08X\n", EW_MEMORY_POOL_ADDR, EW_MEMORY_POOL_SIZE  );
  EwPrint( "Write/Read test pattern...               " );
  testAddress = EW_MEMORY_POOL_ADDR;
  loopCount   = EW_MEMORY_POOL_SIZE ;
  while ( loopCount )
  {
    // Generate a random number
    randomWriteData = rand(); 
    
    // Writing random data in the SDRAM at test-Address
    *(uint32_t*)testAddress = randomWriteData;
    
    // generating a diffrent address, by complementing 24 bits of the test-address (this address belongs to SDRAM too)
    complementedAddress = testAddress ^ 0x007FFFFF ;
    
    // Dummy reading different address of SDRAM
    dummyData = *((uint8_t*)complementedAddress);
    
    // read value of test-Address data and compare with just written data
    tempData = *(uint32_t*)testAddress; // reading data of the SDRAM from test-Address
    if ( randomWriteData != tempData)
    {
      EwPrint( "Error at address 0x%08X\n", testAddress );
    }
    
    // loop step
    testAddress += 4 ;
    loopCount -= 4 ;
  }
  EwPrint( "[OK]\n" );
    

That is it about that 8MByte SDRAM.

 

About simple GUI application that you recommend, I did that and still getting Hard Fault from "EwProcess()" in main() function now! this is console output: https://ask.embedded-wizard.de/?qa=blob&qa_blobid=6096610480886619700

Thanks again for spending time on my project.

by
Hi,

due to the fact that you got the message "System halted! [MemManage_Handler]" it is very likely that the MPU settings are not correctly. Please take care that the MPU settings are matching exactly to the memory layout of your custom board (SDRAM, SRAM, Flash, QSPI-Flash).

Best regards,

Manfred.
by

Hello,

Sorry about my late answer,

I checked my entire MPU settings and look like everything is alright, I was able to run some other projects (except EW projects of course, some samples and examples) on my board with these MPU settings as well.

This is my MPU settings btw if needed:  https://ask.embedded-wizard.de/?qa=blob&qa_blobid=16474378862301070444 

Another thing is I don't think its necessary to set MPU for internal Flash maybe, as I didn't see that in EW Build Environments as well so I only have MPU configuration for SRAM,SDRAM and QSPI.

Finally, the same issue still exist unfortunately;

Best regards.

 

by
Hello,

do you know the address that is accessed when the MemManager_Handler is called? Maybe this helps....

Additional things to check:

The MPU settings for SDRAM should be limited to 8MB because this is the region that works, correct?

Can you try to work without QSPI Flash in the first version? Set the flag EW_USE_EXTERNAL_FLASH to 0.

Do you have the same CPU (same internal Flash, same internal RAM) on your custom hardware as on Evalboard?

Best regards,

Manfred.
by

No, there is no address in MMFAR (MemManage Fault Status and Address Registers) , and meanwhile the "IACCVIOL" flag is 1 in MMFSR which described below:

IACCVIOL:

Instruction access violation flag: 

0 = no instruction access violation fault 

1 = the processor attempted an instruction fetch from a location that does not permit execution.

The PC value stacked for the exception return points to the faulting instruction. The processor has not written a fault address to the MMFAR. This fault condition occurs on any attempt of instruction fetches to an XN (eXecute Never) region, even when the MPU is disabled or not present. Potential reasons: 

a) Branch to regions that are not defined in the MPU or defined as non-executable.  

b) Invalid return due to corrupted stack content. 

c) Incorrect entry in the exception vector table. 

Yes it's correct about 8MB SDRAM, I modified it myself for testing and forgot to bring it back, but it doesn't make any difference by the looks of it.

And EW_USE_EXTERNAL_FLASH flag was 0 already.

As long as I know, Evalboard has STM32H743XI MCU and my custom board has STM32H743II MCU, which they have same SRAM and internal Flash I think.

this picture may help:

 

Best regards.

by
Can you inspect the PC? This should point to the fault location.

According to your project, the stack should be sufficient (not changed compared to our Build Environment). Correct?

I think there is still some access to QSPI flash. Is this located on a different address compared to the Evalboard? Did you adapt the initialization?
by

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.

by
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.
by

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.

by
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?
by
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.
0 votes
by
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.
by
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

Embedded Wizard Website | Privacy Policy | Imprint

...