2021-11-02 10:35 AM
Hi,
When I generate the code with STM32CubeMX version 6.3 for STM32H747XIHx something like this happens:
I have also noticed that when I chose TouchGFX component I am able to use it only with M4 core (this configuration was forced by CubeMX) what is also weird. This shouldn't matter which core uses LTDC/DSI and GFX library...
This is full "log"
FreeMarker template error (DEBUG mode; use RETHROW in production!):
The following has evaluated to null or missing:
==> data.parameters.tgfx_video [in template "TouchGFXGeneratedHAL_cpp.ftl" at line 81, column 6]
----
Tip: It's the step after the last dot that caused this error, not those before it.
----
Tip: If the failing expression is known to legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use [#if myOptionalVar??]when-present[#else]when-missing[/#if]. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)??
----
----
FTL stack trace ("~" means nesting-related):
- Failed at: #if data.parameters.tgfx_video == "So... [in template "TouchGFXGeneratedHAL_cpp.ftl" at line 81, column 1]
----
Java stack trace (for programmers):
----
freemarker.core.InvalidReferenceException: [... Exception message was already printed; see it above ...]
at freemarker.core.InvalidReferenceException.getInstance(InvalidReferenceException.java:134)
at freemarker.core.EvalUtil.compare(EvalUtil.java:198)
at freemarker.core.EvalUtil.compare(EvalUtil.java:115)
at freemarker.core.ComparisonExpression.evalToBoolean(ComparisonExpression.java:78)
at freemarker.core.OrExpression.evalToBoolean(OrExpression.java:36)
at freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:48)
at freemarker.core.Environment.visit(Environment.java:370)
at freemarker.core.IteratorBlock$IterationContext.executedNestedContentForCollOrSeqListing(IteratorBlock.java:291)
at freemarker.core.IteratorBlock$IterationContext.executeNestedContent(IteratorBlock.java:271)
at freemarker.core.IteratorBlock$IterationContext.accept(IteratorBlock.java:244)
at freemarker.core.Environment.visitIteratorBlock(Environment.java:644)
at freemarker.core.IteratorBlock.acceptWithResult(IteratorBlock.java:108)
at freemarker.core.IteratorBlock.accept(IteratorBlock.java:94)
at freemarker.core.Environment.visit(Environment.java:334)
at freemarker.core.Environment.visit(Environment.java:340)
at freemarker.core.Environment.process(Environment.java:313)
at freemarker.template.Template.process(Template.java:383)
at com.st.microxplorer.codegenerator.CodeEngine.freemarkerDo(CodeEngine.java:324)
at com.st.microxplorer.codegenerator.CodeEngine.genCode(CodeEngine.java:245)
at com.st.microxplorer.codegenerator.CodeGenerator.generateOutputCode(CodeGenerator.java:4774)
at com.st.microxplorer.codegenerator.CodeGenerator.generateSpecificCode(CodeGenerator.java:4133)
at com.st.microxplorer.codegenerator.CodeGenerator.generateSpecificCodeFile(CodeGenerator.java:1435)
at com.st.microxplorer.codegenerator.CodeGenerator.generateCodeFiles(CodeGenerator.java:1666)
at com.st.microxplorer.codegenerator.CodeGenerator.generateCode(CodeGenerator.java:1285)
at com.st.microxplorer.plugins.projectmanager.engine.ProjectBuilder.generateCode(ProjectBuilder.java:2347)
at com.st.microxplorer.plugins.projectmanager.engine.ProjectBuilder.createCode(ProjectBuilder.java:1939)
at com.st.microxplorer.plugins.projectmanager.engine.ProjectBuilder.createProject(ProjectBuilder.java:618)
at com.st.microxplorer.plugins.projectmanager.engine.GenerateProjectThread.run(GenerateProjectThread.java:54)
Arek
2021-11-23 12:52 PM
I have had an issue I was unable to resolve otherwise. My SDRAM needed to be written in 32 bit words. However the RGB888 attempted to write in less than 32 bit and the data was useless. The code around writing to the Framebuffer is not provided in source code so I could not edit it. I assumed ARGB8888 in an attempt to be efficient would write in 32 bit words and I was correct! :) Been working on this way too long...
2021-11-23 12:58 PM
FIX!!!
Turns out the "Video Decoding" going away when ARGB8888 was selected is the issue (with the tool). The template used to generate the code as written requires "data.parameters.tgfx_video" to be defined or an error is generated. I changed all the places this error was generated, about a dozen, and code generation works, compiles and runs as needed!
Looks like the STM32CubeMX tool needs updated to fix this bug. Please fix, I spent way too many hours trying to make this work.
Raymond
2021-11-24 05:32 AM
Hello @RLarr.1 ,
Could you please tell me where did you find exactly this line [#if data.parameters.tgfx_video == "Software" || data.parameters.tgfx_video == "Hardware"]". I looked everywhere and I couldn't find it.
And what did you do exactly to fix the issue. I need some details to reproduce the scenario and figure out the source of the issue.
Thanks,
Sara.
2021-11-24 08:08 AM
The full error message is in the first entry at the top. The file name shown in the error is "TouchGFXGeneratedHAL_cpp.ftl". This is the template file used to create dynamic source code. On my computer I find this file in "C:\Users\YourUserName\STM32Cube\Repository\Packs\STMicroelectronics\X-CUBE-TOUCHGFX\4.18.0\CubeMX\templates\Target". Substitute "YourUserName" with the user name used to log into your computer.
In the template file I replaced [#if data.parameters.tgfx_video == "Software" || data.parameters.tgfx_video == "Hardware"]" with "[#if BitsPerPixel == "2"]". BitsPerPixel is defined and not "2" so it skips the code that would be inserted if using tgfx video. This replacement was made in several places in the template file.
To get the errors to happen:
To clear the errors:
What I see is when ARGB8888 is selected in STM32CubeMX the options for "Video Decoding" disappear. I suspect this causes data.parameters.tgfx_video to be not defined.
I have attached my modified file. I had to change the file name to end with a ".c" as an ".ftl" file was not allowed to be uploaded by this system.
2021-11-26 03:48 AM
Hello @RLarr.1 ,
I reported the issue internally to be checked (I already mentioned it in this thread Design limited to 32 bit Writes to SDRAM, uint16_t* frameBuffer0 in HAL.hpp is configured as uint16_t).
Regards,
Sara.