Hi Rudolph,

Thanks for your response.

We did the open and save again trick with Gimp too and we also tried some jpeg analysis like you did. But we can't find the difference. Unfortunately this jpeg is only one of an ongoing jpeg stream so we can't just save the jpeg again with an external tool to display it. We need to know what we have to change at the stream source.

'The "notempty.bin" and "output.bin" are exactly the same for the length of "output.bin".'

Yes, of course, this does include the first 4k.

To clarify, are the first 4k bytes identical in all three of (1) the flash image, (2) the firmware blob, and (3) the read out data?

I just tried to feed my BT816 this image and it will not display for me either.
Then I opened it in IrfanView, checked the available information for it and saved it under a different name again
using the same 90% setting that is in your image.
And this one works just fine with the BT816.
I had both files in the µC memory and sent them over the SPI to be unpacked into gfx-mem.

There must be some difference.
But I can not find it.
Except for the new file beeing a little smaller which could be because of re-compression and therefore a binary compare is useless, there does not seem to be any difference.
I even used the services of fotoforensics.com and imageforensic.org and these both show the same data.
JPEG image data, JFIF standard 1.01
Baseline DCT, Huffman coding
No Meta-Data

So, no idea what the problem is, maybe something is added to the raw data that should not be there and is not picked up by pc software or the web-tools.
But re-save it with a tool like IrfanView and it works.
And you can even batch-process with IrfanView.

>You can supply the newblob command alongside the update command

Yes, I know that, this was not my point.
My point was that progflash.exe does look for a file named "unified.blob" even if you do not tell it to.
This file is required by progflash.exe and gets burned to flash every single time althogh it already is included
in the flash-file.
Progflash.exe should not even look for "unified.blob" by default and really should not burn it by default.
If beeing asked to do that, sure, this option sounds usefull. But flashing "unified.blob" or the generated flash image file should be mutually exclusive since the blob already is part of that flash image anyways.

>Can you verify if the blob in your flash binary (first 4096 bytes) is identical to the stock blob that you're writing?

'The "notempty.bin" and "output.bin" are exactly the same for the length of "output.bin".'

Yes, of course, this does include the first 4k.

And to repeat, my problem is not that the EVE Asset Builder is not working or the progflash.exe is not working.
My problem is, that progflash.exe keeps telling me that it fails to write the data to the flash while it works just fine.
It should not be necessary to read back the data every time from the flash only to confirm that progflash.exe thru out a false error message again.

Hi chris,
BRT Community asks about ElectroStaticDischarge ( I think you understood, but others might not ) as you told you were on the sofa.
Maybe you were not grounded when touching the screen.
Were you working with the bare board in your hands?
How did you power the Cleo "in mobility"?

Hi,

we are trying to display a jpeg image on a display connected to the BT815. But we got

ERROR: unsupported JPEG in cmd_loadimage()

followed by multiple

ERROR: display list overflow

The error message is clear but we can't find a reason why the jpg is not supported. The data sheet says that progressive jpeg is not supported but our jpeg is not progressive.

I attached the unsupported jpeg. What do we need to change to display the jpeg?

Hello Chris,

This could be an ESD issue if you are only experiencing this issue whilst not at your desk.

Is it the Cleo50 or Cleo35 modules you are using?

Best Regards,
BRT Community

Hello,

There is nothing built into I2C to do this, normally slave devices will have some externals pins that can be set to 0 or 1 to toggle a couple of the address bits to avoid this issue. There are some manufacturers that have 4 or 5 part numbers for a part, the only difference being its I2C address.

Best Regards,
BRT Community

You can supply the newblob command alongside the update command, to write a specific blob, as follows:
progflash newblob "unified.blob" update "flash.bin"
Can you verify if the blob in your flash binary (first 4096 bytes) is identical to the stock blob that you're writing?

Hi,

I am currently have 4 screens where this has occurred. I'm still not sure what the trigger is.

Do you want me to send them to you for inspection?

Thanks,

Chris