STM32F769-Evalboard download project doesnt seem to work!?

Question

Further to my linker question - How to relocate the generated code to specific linker section? 

As we have moved to EW version 9 and my reported half screen fault with linker changes for QSPI use; I made no progress resolving this half screen chequer problem. I attempted RGBA8888 and RGB565 in multiple project with code merged in from multiple projects always returning back to the evalboard projects and working reference i already have with EW8.3.

This morning i downloaded the latest eval board project as per question - i note it has the linker settings as queried which confirms my implementation in part.

I generated 3 different example projects with RGBA8888 and RGB565 only to find they produce the same fault i experience with my migration of a large project.

With much tooing and froing thinking this was related to our large project or my implementation of EW 9 RTE etc drivers, I discovered if i comment out the linker settings for QSPI in the evalboard project supplied it works too.

In short can i assume this is proven in Atollic True Studio - the settings look ok and the project will run without an issue if all symbols are defined for the font and bitmap resource pragmas but the linker section is removed. As soon as the linker section is uncommented i get half screen problem.

The linker section i comment out:

.SectionEwResource :
  {
    . = ALIGN(4);
    *(.SectionEwResource)
    . = ALIGN(4);
  } >QSPI

Answer 1

Hello,

yes, the Atollic True Studio project within our Build Environment is prepared for using the QSPI flash.

The project is compiled with 

EW_BITMAP_PIXEL_SECTION_NAME=.SectionEwResource
EW_FONT_PIXEL_SECTION_NAME=.SectionEwResource

and the linker file contains the following section

  /* The Embedded Wizard resource rodata goes into external FLASH */
  .SectionEwResource :
  {
    . = ALIGN(4);
    *(.SectionEwResource)
    . = ALIGN(4);
  } >QSPI

I just verified this on a STM32F769 Evalboard with the provided examples. Can you confirm that the examples are working on your environment?

In case there is a "half screen pixel garbage" on the screen, what is the reported message on the terminal (via serial connection)?

Additional remarks:

• Please avoid any mixture between sources / libraries from version 8.x and 9.x - also do not make any mixture from sources of different color formats.
• If you are using the template project for Atollic TrueSTUDIO, please make sure to use the provided PostProcess.

Best regards,

Manfred.

 

Comments

Thank you for taking the time to reproduce this.

Firstly the kit i have is the STM32F779-EVAL which for other examples ST and EW this has not been an issue.

I used the ST 769 eval project you provided without changes - i acknowledge your comments for swapping files however this was due to missing header files on my projects that i have an issue with; but i have the same issue with your project - unchanged.

With reference to the post process can you explain the point of this as it seems it copies the header files from the same location that is an include path for the .c files that are required for the project. So its pointing at them (as a search path) anyway. The EW project i had did not have the post process configured/included but my EW8.3 examples did have it so that was an inconsistency.

This post process had no effect on the outcome despite a clean and rebuild. Given the project built previously it already knows where the colour format files are and will likely override unless there are duplicates which would be the case if you copy them to the subfolder in generated file location.

To re iterate this half screen problem only occurs when i uncomment the linker section so can this still be related to header files given i have a build and no missin files without running postprocess.

---

Hello,

the PostProcess ensures that all necessary libraries (or sources) and include paths (depending on the color format and screen rotation) will be set automatically. That's all.

But to summarize: This means that the original examples from our Build Environment for STM32F769-Evalboard do not run on your STM32F779-Evalboard, correct?

Since I have no STM32F779-Evalboard, I cannot test that. Within the latest STM32F7 Cube Firmware (V1.12) I do not find separate drivers for the STM32F779-Evalboard, so I assume that everything should be identical (except the crypto features).

Do you get a message on the terminal (via serial connection)?

---

The project works fine without the linker section as mentioned so the drivers are fine.

I will check the serial port.

---

Here is the clue: (For info there is a slight delay, couple of seconds before the System Halted is output)

Create UI thread...                          [OK]
Initialize Display...                        [OK]
Initialize Touch Driver...                   [OK]
Initialize Memory Manager...                 [OK]
MemoryPool at address 0xC00BB800 size 0x01E89000
Initialize Graphics Engine...                [OK]
Create Embedded Wizard Root Object...        System halted! [MemManage_Handler]
 

Issue reported in 'fault analyser' is an issue within EWDecompress() at 0x8015f78. This is called from EwBmpLoadFrame() at 0x8014414. this seems to be where it hangs and ultimately MemManage_Handler

---

I assume that the MCU is trying to read data from QSPI flash which does not work in this configuration...

Just to be sure that we are talking about the same:

You take an unmodified STM32F769 Build Environment and build one example with the Atollic TrueSTUDIO project and get the hardfault on your STM32F779 Evalboard. Correct?

Which example are you using?

Can you (just to exclude Atollic TrueSTUDIO as reason) try the same by using the provided GCC compiler (just use StartGccBuildEnvironment.bat and 'make install') - do you get the same hardfault?

---

The GCC does work. - Hello World Example is used.

There is no subfolder in the generated code area, the linker file does contain the SectionEwResource and teh Makefile does set the QSPI_FLASH to 1. The map file confirms the Font/Logo and SectionEwResource as succesful.

I will start from clean for the True Studio. and attempt to confirm the above by comparison i.e. map file and post process.

---

Using the True Studio post process i get this output:

Method invocation failed because [System.Object[]] doesn't contain a method nam
ed 'replace'.
At C:\Users\Paul.Greatrex\Desktop\EW test\STM32F769-Evalboard\STM32F769-Evalboa
rd\Application\Project\TrueSTUDIO\STM32F769-Evalboard\TrueSTUDIO_ew_post_proces
s_power_shell_script.ps1:65 char:28
+ (Get-Content $Path).replace <<<< ('"&quot;${ProjDirPath}/../../../../Platform
Package/RTE&quot;"', '"../../../../PlatformPackage/RTE"') | Set-Content $Path
    + CategoryInfo          : InvalidOperation: (replace:String) [], RuntimeEx
   ception
    + FullyQualifiedErrorId : MethodNotFound
 

i had to modify the powershell script to get it to stop:

for other readers..

to the end of .ps1 file add:

 Read-Host -Prompt "Press Enter to exit"

or

for the cmd file add -noexit:

PowerShell.exe -NoExit -ExecutionPolicy Bypass -Command "& '%realativepath%\TrueSTUDIO_ew_post_process_power_shell_script.ps1'"

 

---

i will try this:

https://stackoverflow.com/questions/17144355/how-can-i-replace-every-occurrence-of-a-string-in-a-file-with-powershell

reference to V2 and V3 - looks like they have been making changes to basics again..

Replaced the .replace with  -replace

then i get these:

You cannot call a method on a null-valued expression.
At C:\Users\Paul.Greatrex\Desktop\EW test\STM32F769-Evalboard\STM32F769-Evalboa
rd\Application\Project\TrueSTUDIO\STM32F769-Evalboard\TrueSTUDIO_ew_post_proces
s_power_shell_script.ps1:113 char:20
+ $target.AppendChild <<<< ($addElem) | Out-Null
    + CategoryInfo          : InvalidOperation: (AppendChild:String) [], Runti
   meException
    + FullyQualifiedErrorId : InvokeMethodOnNull
 

i wont look any further until i hear further suggestions.

---

We had similar (or same?) problem in the past when the version of the Windows Powershell is not 4.0 (or higher). Therefore we added a certain check.

Which version are you using?

---

Im running on Windows 7 version 2.0

Just to add i am starting my setup again.

Yesterday i deleted all projects from True Studio. closed the environment and reopened, reimported the evalboard project as supplied. Built a project with linker settings in place for RGB565, then instead of creating a seperate manage configuration for RGBA8888 i just modified the default BUILD and it worked so something strange with the second config; if you make errors your macro indicates the wrong source files etc so it wasnt anything to do with colour format path or libraries. I will repeat this again this morning.

So basically the evalboard project worked last night with code generated from Hello World for RGB565 and RGBA8888 - without postprocess as this does not run on my version as reported earlier.

Importing our EW project which is ~2.2M resulted in the same problem i have produced in the past ~10 experimental/attempts at creating a project i.e. half checquer screen.

However - it built first time and ran when using the GCC script - with all resources in the correct location as per linker.

The main difference i saw in the Makefile for GCC is FreeRTOS = 0  however in TrueStudio project its = 1.

changing this to 0 resulted in a build issue which meant i had to exclude the FreeRTOS folder of course.

It built and the same thing happens. With FreeRTOS enabled it fails in EWDecompress as reported above.

with FreeRTOS=0 the console only displays the last succesful message - halting the debugger indicates it is sat in the memfault.

After reproducing this above, if succesful i will then manually create a project from the GCC script as this is proof.

---

I'm wondering why there is no error report due to the old version of the PowerShell...

Is it possible to make an update? Powershell update can be found here.

Of course, you can create your own Atollic TrueSTUDIO project based on proven GCC script settings. The idea of the post process scripts are, to allow the user to change the color format or the screen orientation without changing the project settings. Within a real project this is typically not necessary, because the color format and the screen orientation is fixed.

---

Due to the colour format differences the supplied TreuStudio project includes search paths for the respective folder.

Your post process makes sense to me now of course - but the project needs to modify the inclusion/search paths for the .c files so it knows which ones to use. unless they are #ifdef colour format therefore you could include them all in the project and the macro would allow them to be ignored - i will review this but the IDE does moan if it is the wrong format so i dont believe the post process is the complete solution to the intended flexibility..

---

I have put together another Atollic project from 'new'. This builds and results in the same problem i.e. it sticks in EwDecompress.

I have debugged this and my findings are it (the while loop) runs to the end of memory - it seems there is no boundary check or give up clause. i have taken numerous screenshots of the debugged values. I will continue to run the breakpoint on ignore 50000 iterations - which seems unneccesary to me however i want to confirm it in facts runs to the end of mem and ultimately triggers the mem fault handler. Without trying to understand what exactly it is looking for the  while ( curCode != 257 )  END_OF_DATA is never found; There must be a way to detect basically if you have not found it by 'X' gracefully giveup - this seems to persist and run to infinity.

What other than an END_OF_DATA missing could cause this or rather how can END_OF_DATA be missing.

I have spent a significant amount of time on this so we need to resolve it.

THe other puzzle is the same project works with the GCC command line - but that is shipped with the eval.

Optimsations have been modified and are set as per makefile, i use the same drivers and code as the evalboard project so the only noticable difference is the compiler (between the shipped GCC and the Atollic tools).

---

Hello,

I'm very sure that EwDecompress() works correctly - as long as the provided data are valid.

What I can see from the schematics, the STM32F769 evalboard and the STM32F779 evalboard are identical and there is no separate tree within the CubeF7 firmeware. This means, that the binaries should work on both (as long as there is no crypto feature used).

This is a binary of HelloWorld - created with GCC. Can you confirm this is working on your hardware (when flashed with ST-LINK)?

This is a binary of HelloWorld - created with TrueSTUDIO. Can you confirm this is working too?

---

I have tested the hello world examples on both previously - this was my issue where i restarted my PC and then update the linker file etc. and they are fine.

We are looking at regenerating our GUI design in parts to see if one of the bitmaps can cause a problem.

Very sure it works correctly functionally - as long as the data is valid!  your function EwDecompress running to infinity as it seems means it is not escaping or giving up. There needs to be a size or max mem reference,  it may find the code its looking for in another area of memory - i.e. overrun.

aDest & aData are incremented with no limit check;  the algorithm assumes the curCode==257 will definately be found!

I have repeateble code in many projects and as you said as long as the provided data is valid. The data comes from the generator and the EwDecompress() code is part of you professional add on. 

Something to add is the GCC is using static library however i only added the professional add on so i could debug it - the results are the same with our large project with library or professional add on code.

Where can the provided data become invalid? if the source is from the generator?

Do you have a large project with many resources to the order of 2.2M that you can use on this platform so we can attempt to narrow down potentials?

---

Hello,

concerning EwDecompress(): This is not a generic decompression function. It is intended to be used only with generated resources. All generated resources are finite. Prerequisite is, that the data are read valid from the memory. If this is not reliable, other parts of the software will behave unpredictable too.

Concerning the problem: I assume that there is some other problem - EwDecompress is just the location where it is noticeable.

Unfortunately I still do not have a complete picture of your environment - Is it possible to have a short call?

---

unfortunately i have not been able to flash your hex files as the external loader for the eval board is failing  with a timeout.

I have been working on a cut down project which took our steps right back to a hello world project in terms of removing number of pages and back to a hello world project with our largest bitmap. Then to the original evalboard project only to find my original reported fault of the hello world project not working unless I comment out the linker file.

I have reset the environment, rebooted my PC and moved onto another eval board.

I would like to do this before we talk as i do not believe i have exhausted all variables on my side.

to add when cutting down a project we removed a toggle button that was out of screen area which made no difference to the result i.e. half checquer screen, but the fault (EwDecompress()) then moved to the bitmap load on  our startup screen. The bitmap is 800x480. But i have been unable to resolve anything further as previously mentioned something was fundamentally wrong as the hello world didnt work at the end of the test so i have to restart all of the shrinking complexity with new board.

---

The downloaded evalboard project have stopped working with the linker section included. Excluded they work. GCC command line works as delivered and the output confirms it is with RGBA8888.

The QSPI device add on driver to use in ST link:  MT25QL512A_STM32769I-EVAL

This is as per GCC command line 'make install' etc.

The 2 hex files linked (This is a binary...) worked.

To recap today:

1. Changed Evalboard
2. Imported the untouched/downloaded evalboard project into Atollic.
3. Changed the path names etc to RGBA8888.
4. Generated Hello World code for this colour format.
5. Build and run in Atollic - half screen - FAIL
6. Set Free RTOS = 0. exclude Free RTOS from the project.
7. Build and run in Atollic - half screen - FAIL
8. comment out EwSection in linker file
9. Build and run in Atollic - display and touch events - PASS
10. Open command line/ batch file StartGccBuildEnvironment - PASS (same project folder so the same code)
11. delete all files in generated code folder.
12. Copy our project generated into the generated code folder
13. Build and run in Atollic - half screen - FAIL
14. Open command line/ batch file StartGccBuildEnvironment - PASS (same project folder so the same code)
15. repeated replacing generated code with some modified hello world i.e. adding the larger bitmaps
16. same problems. GCC works for all. Atollic only works if linker section is commented out.

Unable to debug with this set of exercises as the code was untouched and professional add on was not added to the project.

 

---

Can you send us a non-working Atollic project (either sample or your minimized project) as a complete project, so that we are able to reproduce / debug the issue?