STM32F769 calculates wrong NMCU during header processing?

[h2obrain]

Dear All,

when I parse a simple jpeg (300x100px, 4:4:4 subsampling), the nmcu value reads 468 (?=floor(300*100/64)) instead of 494 (=floor((300+7)/8)*floor((100+7)/8)) after the header processing finished interrupt.

All the image data is processed correctly, so this is not a big problem, it was just very confusing during testing of my implementation.

So my question in the end is, is this a bug in the hardware or is my math wrong?

I am confused..

Oli

[waclawek.jan]

Are you talking about some "library"? If it's Cube, it's open source, isn't it?

JW

[h2obrain]

I am using libopencm3.

The problem/confusion I have is with what is written to the JPEG_CONFR2 register by the hardware JPEG codec.

[h2obrain]

The problem should also be reproducible with CubeMX using my jpeg.

[waclawek.jan]

Okay, so it's a bug in the "libraries", assuming all pictures will be multiples of 8x8?

In case of libopencm3 you can/should fix it yourself, I guess, perhaps feeding back to the project.

I'm not sure anybody responsible for Cube/CubeMX is listening.

JW

[waclawek.jan]

Ah, it just dawned to me, you are probably referring the hardware header decoder (I don't use the 'F7 nor the HW JPEG decoder) .

The RM appears to account for this case:

For decoding: this field indicates the number of complete MCU units minus 1 to be

decoded (this field is updated after the JPEG header parsing). If the decoded image size

has not a X or Y size multiple of 8 or 16 (depending on the sub-sampling process), the

resulting incomplete or empty MCU must be added to this value to get the total number of

MCUs generated.

which sounds that you have to fix NMCU for that case "manually".

JW