Skip to main content
frackers
frackers
Senior
August 26, 2019
Question

stm32f779 hardware jpeg decoder no interrupts

  • August 26, 2019
  • 2 replies
  • 740 views

Four months of trying to solve this on and off and still no closer to finding a solution.

The 'JPEG_DecodingUsingFs_DMA' example works great on the stm32f769i-disco board but porting it to custom hardware and I never get an interrupt of ANY kind from the jpeg block (HAL_JPEG_IRQHandler) or DMA (DMA2_Stream3_IRQHandler & DMA2_Stream4_IRQHandler).

Other peripherals (USART, DAC, ADC, QSPI) all generate DMA interrupts as expected but nothing from the JPEG hardware.

Does anyone know of any issues with the CubeMX initialisation of the jpeg hardware that the disco example does differently?

Any specific things to be done that are buried in the MSP file or have to be enabled in a header somewhere?

This topic has been closed for replies.

2 replies

frackers
frackersAuthor
Senior
September 30, 2019

I've now ported the Discovery 'JPEG_DecodingFromFLASH_DMA' example project successfully to my target hardware based on stm32f779ii MCU.

I've generated a minimal CubeMX project to drive the hardware JPEG block and have exactly the same problem as before - I never get any interrupts from the JPEG block.

I've tried using the Disco based initialisation in various sections of the init and msp code but to no effect and in any case, this doesn't help my main application which is now several 10's of 1000's of lines of code based on CubeMX.

Has anyone anywhere successfully used the hardware JPEG decoder with CubeMX initialisation?

frackers
frackersAuthor
Senior
October 1, 2019

Further progress!!!

I've stripped all my user initialisation code from my project and am just using the basic CubeMX generated init plus the minimal decode of a JPEG image from flash code. The decode now completes (and the header info is correct) but the image is corrupt.

Changing the 'configTOTAL_HEAP_SIZE' define in 'FreeRTOSConfig.h' from 0x20000 to 0x18000 and my data corruption has gone! The badness starts at about 0x1a000 and gradually increases as the allocation is increased. Note that I'm breaking the code before any tasks are started (the decode occurs inline with the initialise!)

This is running on a stm32f779ii processor with 0x80000 of RAM, my map file is reporting (in the initial value above) 0x48688 as my '_user_heap_stack' value so I'm not running out of memory.

Anyone care to comment on this weirdness?

Terms & ConditionsAccessibility statement