Suspending and resuming touchgfx task.

[AKG]

I am trying to use the external QSPI flash to store some contents while touchgfx is running.

I believe the correct procedure to do is:

Suspend touchgfx task.

Disable interrupts(LTDC and DMA2D)

switch QSPI to indirect mode

perform write to QSPI

switch QSPI to memory mapped mode

enable interrupts (LTDC and DMA2D)

Resume touchgfx task

I am following above procedure but the device restarts approximately after 90 seconds of suspending the touchgfx task. Even though there is no write operation to QSPI.

I would like to know if the above mentioned procedure is correct ?

also what would be correct place to suspend and resume the task ?

Note: we are using EMBOS.

@Martin KJELDSEN​ it would be helpful if you could provide some tips here.

[Xzhiy.1]

void TouchGFXHAL::taskEntry() will NEVER return:

 for (;;)

  {

    OSWrappers::waitForVSync();

    backPorchExited();

  }

Use a flag to control the  loop run or skip ?

I want to know the right answer either.

[AKG]

@Xzhiy.1​ : thanks for your hint.

I tried to override taskEntry() function and the device doesn't run anymore. Looks like there is something more taskEntry() function is doing.

Are you sure the taskEntry() function does only this much ?

@Martin KJELDSEN​  or @Romain DIELEMAN​  :

do you think its a good idea to override taskEntry() and control the touchgfx task ?

[Xzhiy.1]

void TouchGFXHAL::taskEntry() //found in TouchGFXHAL.cpp

{

  enableLCDControllerInterrupt();

  enableInterrupts();

  OSWrappers::waitForVSync();

  backPorchExited();

  // Turning on display after first frame is rendered

  HAL_GPIO_WritePin(GPIOK, GPIO_PIN_7, GPIO_PIN_RESET);

  /* Assert display enable LCD_DISP_CTRL pin */

  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_2, GPIO_PIN_SET);

  /* Assert back light LCD_BL_CTRL pin */

  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_1, GPIO_PIN_SET);

  for (;;)

  {

    OSWrappers::waitForVSync();

    backPorchExited();

  }

}

I guess the function backPorchExited() render the FrameBuffer after each Vsync received, if you bypass this function, then LCD maybe freezed for the reason of no new picture data rendered to the FrameBuffer, So may modify like some sort of following.

  for (;;)

  {

    OSWrappers::waitForVSync();

if(bypasss_flag) //global, first should be false to make GFX render correctly

{

     backPorchExited();

}

}

it has very rare chance to work, I'm a begginer.

[Martin KJELDSEN · Accepted solution]

You actually don't have to suspend the TouchGFX task completely. You can simply disable the interrupt that drives TouchGFX forward (perhaps in endFrame() to be sure that TouchGFX is done), set qspi in non-mapped mode, write, etc.

[manto.1]

How do I find out what interupt drives TouchGFX so I can disable it?

[Martin KJELDSEN]

I don't know your concrete project, but in the case of LTDC - look for the LTDC interrupt configuration and implementation in one of the TouchGFX HAL cpp files. The synchronization with the display transfer is usually what drives TouchGFX forward (sometimes it might be a timer).

[alexandre.dotto]

My case is similar to the one described above. And just call: void TouchGFXHAL::disableInterrupts(), then change qspi to normal mode. After writing the data, go back qspi to mapped mode and then call: void TouchGFXHAL::enableInterrupts() and everything went well.

[mids400]

Where should this functions be called? within main.c or in application code?

Thanks

[Smartembedded]

But what about code execution, I would assume that this code need to reside in bootloader or ram in case where application exitst in QSPI ?