What is a like cause of the error "The canvas is already initialized with a graphics engine bitmap"?

294 views
asked Oct 19, 2017 in System Integration by kylenz
I am running a simple UI (just a couple of images) on a custom STM32F469 board. I am getting this on output:

Initialize Serial Output...                  [OK]
Initialize Display...                        [OK]
Initialize Touch Driver...                   [OK]
Initialize Memory Manager...                 [OK]
MemoryPool at address 0xC007F800 size 0x00780800
Initialize Graphics Engine...                [OK]
Create Embedded Wizard Root Object...        [OK]
Create Embedded Wizard Viewport...           [OK]
The canvas is already initialized with a graphics engine bitmap
PANIC: System halted

It's breaking on:

Update( viewport, rootObject );
GraphicsCanvas__AttachBitmap( canvas, (XUInt32)bitmap );

if ( _this->Super1.bitmap != 0 )
    EwThrow( EwLoadString( &_Const0004 ));

Any suggestions on where to start to look would be great, thanks!

1 Answer

0 votes
answered Oct 19, 2017 by Manfred Schweyer
Hi,

let me ask you some questions in order to find the root cause:

1.) Does the PANIC situation happen directly after the starting the system (this means within the first call of Update()) or after a while?

2.) You mentioned to use a "custom STM32F469" board. What are the differences compared to a STM32F469 Discovery board?

3.) Did you made changes within the provided Build Environment (especially in main.c)?

4.) Are you able to run other examples (starting from "HelloWorld") on your hardware?

Best regards,

Manfred.
commented Oct 19, 2017 by kylenz

Hi, thanks for helping.

1. The error is thrown when the bitmap is found not to be empty:

if ( _this->Super1.bitmap != 0 )
    EwThrow( EwLoadString( &_Const0004 ));

in:

GraphicsCanvas__AttachBitmap( canvas, (XUInt32)bitmap );

called from:

Update( viewport, rootObject );

 

2. A different LCD (480x272) using parallel vs DSI of the disco. It has SDRAM and QSPI eeprom (not implemented). 

3. I actually modified the STM32F429 example to work since it doesn't use DSI and had the smaller screen. I managed to change all the BSP and get the SDRAM, LCD interface working (I think), and I2C communicating to the touch controller. The LCD displays the correct background colours if I modify the initialised RGB values after I initialise the LTDC. After the layer is initialised the screen went "static" so I tried initialising the SDRAM to 0 and now it goes white. Then blue after a while, not sure what that is yet??

4. I am currently trying to get a slightly modified version of the hello world example due to the smaller screen size.

I can add some code or schematics tomorrow if that helps. I just don't understand the process well enough yet to figure out why that bitmap is not empty and what the correct values of the viewport, rootvalue, and graphics engine are.

Thanks!

commented Oct 19, 2017 by Manfred Schweyer

Thanks for the information - still question 1 is open: If the PANIC happens the during the first call of Update() or in a later call. You can add a 

EwPrint( "Update called...\n" );

within the Update() function and let me know the result of the console.

 

In order to search on the right location, let us do first a memory check to ensure that the content of the SDRAM is correctly. Just place the following lines before the call to tlsf_create_with_pool() in main.c

{
  unsigned char* ptr;
  unsigned char  data;
  unsigned long  count;

  EwPrint( "Check memory at address 0x%08X size 0x%08X\n", MEMORY_POOL_ADDR, MEMORY_POOL_SIZE );

  EwPrint( "Write test pattern to SDRAM...               " );
  ptr = (unsigned char*)( MEMORY_POOL_ADDR );
  data = 0x00;
  count = MEMORY_POOL_SIZE;
  while ( count-- )
  {
    *ptr++ = data++;
    if ( data >= 253 )
      data = 0;
  }
  EwPrint( "[OK]\n" );

  EwPrint( "Read test pattern from SDRAM...              " );
  ptr = (unsigned char*)( MEMORY_POOL_ADDR );
  data = 0x00;
  count = MEMORY_POOL_SIZE;
  while ( count-- )
  {
    if ( *ptr++ != data++ )
      EwPrint( "Error at address 0x%08X\n", ptr-1 );
    if ( data >= 253 )
      data = 0;
  }
  EwPrint( "[OK]\n" );
}
commented Oct 19, 2017 by kylenz

Sorry, I misread your first question. Yes, I happens on the first call.

Ran the memory check, SDRAM seems ok. I even added in a delay after the write to check if the data was holding, then looped through it a bunch of times and it was still ok.

Initialize Serial Output...                  [OK]
Initialize Display...                        [OK]
Initialize Touch Driver...                   [OK]
Check memory at address 0xC007F800 size 0x00780800
Write test pattern to SDRAM...               [OK]
Read test pattern from SDRAM...              [OK]
Initialize Memory Manager...                 [OK]
MemoryPool at address 0xC007F800 size 0x00780800
Initialize Graphics Engine...                [OK]
Create Embedded Wizard Root Object...        [OK]
Create Embedded Wizard Viewport...           [OK]
The canvas is already initialized with a graphics engine bitmap
PANIC: System halted

Main.c: https://pastebin.com/hbjSptQc

commented Oct 19, 2017 by kylenz

I managed to get it working, kindof. I changed the color profile from 

-DEW_FRAME_BUFFER_COLOR_FORMAT_RGB565

to 

-DEW_FRAME_BUFFER_COLOR_FORMAT_RGBA8888

and changed the respective included platform package and library.

The colors have a yellow tinge to it which must be due to the 888 -> 565 conversion.

Do you have an idea why the 565 setup might not have been working? It seemed to be from the pixel byte width.

commented Oct 20, 2017 by kylenz

There still seems to be a color issue. I created a test screen with one side at 128 alpha and in the editor it looked like this:

and on the LCD itself it looks like this:

Note the alpha gray looks like light blue and the alpha black looks yellowy.

commented Oct 20, 2017 by Manfred Schweyer
Maybe there is some mixture of the color format sources and libraries. When changing the color format, the Graphics Engine library, the file ewextgfx.c and the display initialization has to match together.

Within our provided Build Environments, this selection is done automatically, when changing the color format of a UI project.
commented Oct 20, 2017 by Manfred Schweyer
Concerning the LCD colors: I do not think this is related to 888->565 conversion, since this is not really a conversion, just omitting the last bits.

In order to ensure that the hardware is connected correctly, you can display four color gradients: black to white, black to red, black to green and black to blue. Then you can see it this is shown linear or if there are some strange steps.
commented Oct 23, 2017 by kylenz
Thanks for your help. I had missed the last port of pins to initialise which included a couple of blue pins and the LCD_EN. It's working great now.

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint

...