Fault problems with STM32F7

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Fault problems with STM32F7


      I will start out by saying that I am indeed using STemWin 5.40 on the F7 DISCOVERY board(ST-LINK) with FreeRTOS in Visual GDB.
      I have been working on this project for a year now and I am almost ready to release the product for testing but I have run into a mind boggling problem.
      I hesitated to ask any questions here since I am using a free version and I think I was able to solve part of my problem reading posts here.

      The release version _seems_ to run fine with the ST-LINK attached but if I restart it.. some windows FAIL repeatedly at the same places.

      I am using the DISCO board's SDRAM for the LCD buffer and the GUI_MEMORY.

      I had OS_SUPPORT on but I also went over the code to make sure only 1 thread was calling emWin routines. So now, it functions the same with OS_SUPPORT on or off.
      I had been experiencing random hard faults in debug mode always related to GUI_Alloc_LockH or UnlockH.
      I am not very savvy with this but it appeared an odd address was being returned from those routines.
      I have about 10 windows that are switched back and forth, each having one to 3 sub-dialogs that are created and deleted by their respective windows.

      Switching between the main windows would intermittently result in a hard fault.
      I had been allocating gui memory simply by declaring a pointer to the SDRAM and calling GUI_ALLOC_AssignMemory();

      aMemory = (U32*)SDRAM_BASE;

      After reading a post here I decided to create a linker section for the SDRAM which I had set ALIGN(4) ( not necessary or error?) I have also tried without any ALIGN instruction.Which is proper?
      Then I declared an array as the post suggested.
      static U32 aMemory[GUI_NUMBYTES / 4] __attribute__((section(".sdram_data")));//= {0}; can't init it because the SDRAM driver

      GUI_NUM BYTES is 1MB , I've also tried up to 3MB. At 2MB WHen I check for how much gui mem is used, it shows only 9056 and 1.56 MB free ( attempting to create/unhide only one offending window.. I am re-orienting the display so I understand that there is an extra buffer created for that. ( hence the 1.56 MB fee)

      I don't know why but in debug mode, that seemed to solve or lessen the number of hard faults.
      I could run an automated test routine that sent each button message to create/hide windows (hide/unhide, after they're created)
      which would run for 20 minutes without a hard fault. Unfortunately , my VS2019 restarts about every 20 minutes on its own.
      But it was better than it had been. So,. I thought I had fixed it.

      Then, I created a release version and ran it with the ST-LINK debugger attached, but it does run from the bootloader anyway. All seemed fine.

      However, when I remove the debugger cable and run the app ( it is always powered by the HS USB connection) I have a few windows which fail to start and apparently case a hard fault. I was able to see that, if I am not wrong, it was in the GUI_ALLOC routines. I used "Attached to running embedded firmware" to try and see what was going on.


      I had two windows that were creating their sub-dialogs at the beginning of WM_INITDIALOG, after I had set the global window handle for each window to pMsg->hWin.
      This worked fine with the STLink connected.
      But not without ..

      So, I moved those to the end of the WM_INITDIALOG area after the buttons, etc were initialized. ( since I need them active, I wasn't sure where else to do this, maybe in the CreateDialog() area ?

      At any rate, right now, my release version seems to be working and running through all of its windows with out crashing.

      If you DO read this entire post and have any more insight.. still.. greatly appreciated. SO sorry it is so long!

      Unfortunately, I am still seeing crashes when the STLink is not attached. Moving the sub-dialog creation seemed to work only for a moment. I have no idea how to approach this.

      The post was edited 9 times, last by jona: formatting ().

    • I thought I should post what I hope is my solution in case anyone else runs into this.

      I had been running from my bootloader for the STM32F7 DISCO board.
      I ran the release version at 0x08000000,replacing the bootloader, and it ran fine. No hard faults from GUI_ALLOCLock/Unlock
      So, the problem must be in the BL.
      I went and modified the BL, adding HAL_DeInit and disabling the cache before jumping to the application.
      I also noticed that I had not been invalidating the I & D caches in the APP (not BL) before enabling them. So I added Invalidate before enabling each cache.
      (* that may have been all I needed to do.. but the de_inits can't hurt.)

      At the moment, those features are running as they should. At least for the last 15 minutes anyway!
      I don't fully understand why the ST-Link might have effected STemWin that but as long as it seems to be running now.. I'm good.

      I am still curious whether I should set "ALIGN(4)" in the linker file for GUI_MEM.

      Thank you.