Running on custom board

Question

Hi

We have the graphics running fine on an ST discovery board (32ST756).

However when we run it on our custom board, although sdram works, LCD works (We can directly write stuff to the LCD frame buffer and see it on the screen). The GUI is not displaying anything.

The code is identical between the 2 boards , bar some GPIO settings as the pins are different.

What we find strange is that the "EwEndUpdate (aViewport, updateRect);" has no effect at all. Then just after we wrte directly to the FrameBuffer and we see things.

All addresses are the same between the 2 boards.

Any thoughts?

Thanks, Adrian

Answer 1

Hi Adrian.

Some questions:

Do you get any messages on a connected terminal via EwPrint()?

What are your settings concerning the framebuffer configuration - especially EW_USE_DOUBLE_BUFFER?

Maybe you can try to avoid double buffering in the first step and see if it works.

Comments

I am getting build errors in tlsf.c  :(We have a professional edition)

/* This code has been tested on 32- and 64-bit (LP/LLP) architectures. */
tlsf_static_assert(sizeof(int) * CHAR_BIT == 32);

 

CHAR_BIT is undefined... I did a project text search and it does not appear anywhere

I could not find STM32FxUseDMA2D either...

---

ooops... Sorry my fault.   

It has built but with missing references to STM32FxFillDriver )and 2 other similar missing references).  I assume i am using production versus debug libraries?

We are running version 7.10, we also have version 8.0, but have not yet used it...

---

Maybe there are way too many steps...

Let's try the following:

Take a simple example (like HelloWorld), ensure that you can compile and link it, then try to execute it on the working board. If you have a terminal, that could help to get messages.

Then compile the same application for your other board and try to exectue it on the non-working board. It would be helpful (as always) to have a serial connection in case there are error messages.

If the application is not working: What are the differences from hardware perspective and from software perspective?

If you think it could be related to memory: Make a simple memory test to write/read/compare the content of a huge memory area within the SDRAM.

Just a few ideas....

---

Hi,

Late last night I finally found the issue: The DMA2 clock was not enabled.

Once the following code:

  __HAL_RCC_DMA2D_CLK_ENABLE();

was added to the project, everything came back to normal.

It would seem that the discovery board and the evaluation board chips have this running on reset or power up, whereas the chip on our prototype board does not. As I said, the projects are strictly identical, except for pin definitions.

I would have expected the DMA2D clock to be enabled by your library since your library is using it. So I can only guess that you have had boards where the DMA2D is also enabled on reset or power up, so you did not see the isuue.

Or there might be another initialisation issue we are not aware of? 

Did we read your documentation properly on this aspect? 

What are your thoughts?

Thanks, Adrian

 

 

---

First of all, great that you have it now up and running!

In general, the libraries (Graphics Engine and Runtime Environment) do not make any hardware related settings. The different files of the Build Environments are tested for a certain environment (e.g. Discovery Board) and have to be considered as templates in order to simpify the adaptation.

The DMA2D clock has to be enabled - no doubt. Since version V8.00 the entire access to DMA2D is managed within one module (DMA2D.c), where you will find the following code:

void HAL_DMA2D_MspInit(DMA2D_HandleTypeDef *hdma2d)
{
  /*##-1- Enable peripherals and GPIO Clocks ##*/
  __HAL_RCC_DMA2D_CLK_ENABLE();

  /*##-2- NVIC configuration ##*/
  /* NVIC configuration for DMA2D transfer complete interrupt */
  HAL_NVIC_SetPriority(DMA2D_IRQn, 8, 0);
  HAL_NVIC_EnableIRQ(DMA2D_IRQn);
}

Maybe it is not a bad idea to update from V7.10 to V8.00 or (coming very soon) V8.10.