Corrupted icons in STM32F469I-discovery and STM32Cube_FW_F4_V1.14.0

[Matti Sillanpaa]

Posted on February 27, 2017 at 11:06

Hi.

Tried building (eclipse + openstm plugins) the demostrator SW supplied in the FW package and it has few problems. Apparently the naming policy has changed and fe gui.h has changed to GUI.h. Similar upper/lower-case naming issues were with many header files.

After solving these problems and successully flashing the dev board, there seems to be problem with the application icons and other graphical items. It seems like composition assumes 32bit content and menu icons are in 16 bit RGB565. I debugged this a bit, and didn't find any obvious problems.

#stm32f469-discovery #composition #stm32cube_fw_f4_v1.14.0

[S Abdes_O]

Posted on February 27, 2017 at 13:46

Hi,

Did you use ST-Link Utility to program the board?

[Matti Sillanpaa]

Posted on February 27, 2017 at 13:48

This doesn't seem to be problem with data format or stride length. I edited the audio_player_res.c and left the _acaudio1 -bitmap to heap instead of default flash storage. I used same bitmap for bmaudio1-5 and the image was OK. I think the problem is flash storage. I dumped input bitmap with debugger in LCDConf.c->DMA2D_CopyBuffer and the content in pSrc doesn't match the stuff in _res.c.

[Matti Sillanpaa]

Posted on February 27, 2017 at 14:46

Ok, I used the ST-link Flash utility for flashing and now the icons are OK.

However is there some fix for the debugger? I mean debugging is pretty vital feature and flashing with another tool isn't really that convenient.

[Matti Sillanpaa]

Posted on February 27, 2017 at 13:50

I use eclipse debugger for the flashing. It uses the AC6 tools set for flashing.

[S Abdes_O]

Posted on February 27, 2017 at 15:37

After programming the external QSPI memory, You still can update the code and debug the internal flash memory using your preferred debugger.