2018-12-12 12:42 AM
This is not a question asking post, just something I want to share. Hope will help people who meet the same problems I solved.
Last I asked lots of question about how to build a TouchGFX project.
You can find the original ask in [Does CubeMX 5.0.0 Ready to Build a TouchGFX Project?]
After few weeks work, I finally make this right. Now I'd like to share some information with you.
About my situation:
Host project builder: STM32CubeMX 5.0.0
Firmware package: STM32Cube FW_F4 V1.23.0
GUI builder: TouchGFX Designer 4.10.0 within the firmware package
ToolChain/IDE: TrueSTUDIO for STM32 9.0.0 convert from SW4STM32
Hardware: Custom PCB with STM32F429IG
LCD Panel: 1024 * 600, RGB565 interface parallel
Touch Screen: Capacity Multi-touch, IIC interface
Q1. How to build a host project for TouchGFX graphic solution using TrueSTUDIO toolchain?
A1. You can follow UM1718 tutorial 10 or my posts which have more details and screen shots in my original ask. BUT before you hit the generate code button, make sure the Toolchain/IDE setting is select to SW4STM32. Since there are some generation problems when using TrueSTUDIO as its Toolchain/IDE. Later then you can use TrueSTUDIO to open .project files and do some automatic conversion.
Q2. How to build a GUI project within the host project? Why I try to build the host project and tons of missing files error are showed?
A2. After you hit the generate code button and the generation is completed.You'd better not to open .project file so far. Go back to CubeMX's GRAPHICS configuration page. Now the TouchGFX's Execute button should be available then click it. You could do some quick design just for test in the opening TouchGFX designer.After dragged some widgets or change background image, you have to save the GUI project and click the Generate Code button. The the status bar or Detailed Log will tell you if code generation is finished.
Q3. What if I meet a code generation error in GUI project?
A3. Close the TouchGFX designer and then reopen project in yourhostprojectname/TouchGFX/yourhostprojectname.touchgfx file. And then try again. In most cases, it can be generated after close and reopen procedure. But if it didn't, at least you can give a try that delete all files and directories except yourhostprojectname.ioc file and try again.
Q4. Error in compile main.cpp?
A4. You may need to change
void MX_FREERTOS_Init(void);
to
extern "C" void MX_FREERTOS_Init(void);
in line:89 or /*Private function prototypes*/ section in main.cpp.
Q5. Error in compile freertos.c?
A5. You may need to change
void GRAPHICS_MainTask(void)
{
touchgfx::HAL::getInstance()->taskEntry();
}
to
extern "C"{
void GRAPHICS_MainTask(void)
{
touchgfx::HAL::getInstance()->taskEntry();
}
}
in the bottom of BoardConfiguration.cpp.
Q6. Fall into an infinite loop in startup file after tastEntry() function called?
A6. Make sure you enable interrupts related to LTDC and DMA2D in CubeMX NVIC configuration.
Q7. LCD display some glitch-style content and program run into the Hardfault_Handler() function?
A7. Check in MX_FREERTOS_Init() function which is declared in freertos.c, and double the defaultTask stack size (in bytes) parameter. 128 to 256, 256 to 512 ,512 to 1024. The 1024 bytes stack size work for my situation.
Q8. LCD display the test design well but want more design?
A8. Make sure you close the host project in TrueSTUDIO project resource manager. And open your GUI project like A3. Finish your design and generate GUI code. Now reopen your host project and completely rebuild it. If you meet some errors said that no such file things, you were probably do some "delete" design before.If you just do "add" design, usually won't come up these errors. You have to find out which files didn't exist in file system anymore but still in your host project structure, and remove them from it. And do a completely rebuild again. Please don't click the Execute button again, unless you want start a totally new GUI design.
Q9. Want to use LCD width or height beyond 1000 pixels?
A9. I don't know why the width or height limitation is 1000? Because LCD display panel commonly have 1024 pixels in width or height. You can do some hacks to override the limitation, but at your own risk. Firstly, use notepad to open *.touchgfx file, change
...
"Resolution": {
"Width": 1024,
"Height": 600
},
...
value to what you want before you do any design else. Secondly, change values in BoardConfiguration.cpp -LCD_GetXSize(void)\LCD_GetYSize(void)\touchgfx_init(). Thirdly, change value HW_Init.cpp -MX_LCD_Init() - HAL_LTDC_SetPitch().
I will keep share if I found something is valuable.
2018-12-18 08:21 AM
Hello @elguezzar . Took the same CubeMX project and:
a) removed the use of the SPI mapping from the LTDC definition using the same tool (Graphics -> Platform Settings -> removed SPI_PIN definition and left as UNDEFINED).
b) next, selected SPI5 and configured to DISABLE. This is through Connectivity -> SPI5 -> pull down menu -> select DISABLE.
c) Requested the tool to GENERATE CODE. IAR detected the changes to the source code. Clean -> Rebuild all. This resulted in 14 raised errors, all linked to the missing SPI port.
d) Went back to the CubeMX tool and re-enabled SPI5 port and configured to Half Duplex Master. Left the LTDC Platform settings to UNDEFINED. Generated code again. Now all ok (except for the duplicate LCD_Delay code which is expected and requires to be commented out).
IAR built the code after the above LCD_Delay code block correction -> LCD and Touch Panel continue to function.
Summary:
a) the BSP applied from the STM32F429i-DISC1 demands the enabling of the SPI port
b) the LTDC and applied TFT panel on this kit do not care for the SPI port to be enabled
If you review the schematics of the kit, the ILI9341v controller is strapped to enable the I2C port (SDA/SCL) usage so the results appear to be logical. Have not studied the source code for this portion of the design in detail but will do so soon, now that we have a stable development platform.
On an aside but may be of value, the TFT display onboard this kit appears to be from SAEF. The vendor and this design are making use of a 0.7mm pad pitch flex PCB. Respectively, this flex PCB is soldered directly onto the main PCB. For us, this is not suitable so we have searched for a compatible 0.7mm pad pitch SMD ZIF socket. Apparently more rare than Elvis sightings. Rather the common pad pitch is 0.5mm or 1.0mm for such flex cables IF you wish to source a compatible ZIF socket. We are now working with a vendor who is able to change the flex PCB to offer 0.5mm pad pitch and same pinout with the same ILI9341v controller. Just a FYI if you are considering a design that will see any production. Summary, 0.7mm is an oddball pitch so consider 0.5mm or 1.0 mm else face approximately $2k USD in tooling + 50k MOQ for the custom SMD ZIF socket!!
2019-01-04 03:03 AM
Happy new year to all of you folks,
Zhi Pang, Thank you for the enlightening tutorial. It me helped a lot. I am using the 32F746GDISCOVERY though.
I would like to ask about an issue if anybody is facing the same.
When I power up the circuit the first screen is rubbish and then the normal screen appears.
When I reset with the RST button the first screen shown is the screen shown before reset.
Any ideas of how I can resolve this issue?
Thank you in advance
Apostolos
2019-01-04 04:33 AM
2019-01-06 05:16 PM
Hi @aplastiras ,
I don't know what hardware architecture does 746DISCO board use. But speaking generally, the "image" which shows on screen is stored in graphic memory. Usually is internal/external SRAM/SDRAM. It means the memory is volatile.
So you can't guarantee what data will exist since the power is off. But the LTDC will transfer those random(or maybe not?) data to screen in pixel format, RGB888/RGB565......,once you power up the device and LTDC is initialized.
1.Long time not power up - SDRAM data is random.
2.Power on - LTDC initialized - transfer rubbish data to screen.
3.Few seconds pass - Main program running - SDRAM data update - LTDC transfer normal data to screen.
4.Press reset button - SDRAM doesn't loss power in this process , it will store the last frame on 3.
5.LTDC initialized - transfer last frame before the reset button pressed to screen.
6.Just like 3.
If the problems you faced just like I described, it may not an issues. It just a normal process for graphic shows. You can try to fill the graphic memory area with zero (color black) before reset or power down to clear out the screen. Or maybe delay the LTDC initialization time until main program update the graphic memory area.
2019-01-07 03:38 AM
Thank you all for your answers
@Mon2 this is a very good pdf that organize the procedure for Touchgfx. It does not mention anything about my problem. Thank you anyway
@Zhi Pang it is obvious that is exactly as you describe it. The problem is that shutdown is usually done by power off. When power on is present again rubbish is the first screen an the client is not very happy.
How is possible to write straight to this memory manually in order to zero the the memory area?
If this is possible a solution could be to do this on init.
Any clues about how I can do something like that?
Any help-guidance would be appreciated.
2019-01-07 03:44 AM
How about write zero to the graphic memory area immediately after SDRAM init?
2019-01-07 04:57 AM
Try a full Chip Erase and see if that helps.
2019-01-08 05:19 AM
Dear @Zhi Pang
MX_SDRAM_InitEx() is where the SDRAM initializes.
After that is the place where I can put the code.
I have found stm32f7xx_hal_sdram.h that contains functions to access the sdram. There different ones like HAL_SDRAM_Write_32b,HAL_SDRAM_Write_16b orHAL_SDRAM_Write_DMA.
The address as I can see is 0c0000000 and the size should be 480*272*16 bytes.
What is the best method to write to SDRAM.
I have test some combinations but the program freezes and does not run at all.
Any suggetsions?
Any code samples?
Thank you once again
2019-01-08 05:38 AM
So the solution is found
Talking about the CubeMX generated project after GRAPHICS_Init();
I placed the code above in order to fill the frameBuffer with zeros.
const uint32_t SZ = 480*272;
uint16_t buffer[SZ];
static uint32_t address = 0c0000000;
for(uint32_t i = 0 ; i < SZ ; ++i)
buffer[i] = 0;
HAL_SDRAM_Write_16b(&hsdram1, (uint32_t*)address, buffer, SZ);
The result that in case of the random data it shows a black screen when it starts.
Thank you all for the support
Apostolos