Go Down

Topic: Problem with VidorDrawLogo (Read 2557 times) previous topic - next topic


Unfortunately, the only difference with the previous one is that it fails the check by having a different checksum.

Code: [Select]
Verify 680460 bytes of flash with checksum.
Verify failed
Errore durante il caricamento dello sketch

Then both on the video and on the serial behaves exactly like the other. The version is always FFFFFFFF.


hi guys,
i just found that on a samsung monitor there's a strange behaviour: if the board is not started immediately after it's turned on (for example due to the fact that the sketch is waiting for usb serial port to be connected) the monitor will not show an image anymore. this is likely due to the fact that we have a fixed 5V going to the monitor to flag signal is present but we are not outputting signal until FPGA.begin() is called.
for those who don't see a picture but see correct version and no timeouts please try either commenting out the serial related calls or unplugging and replugging the monitor after board is started.


Aug 09, 2018, 03:38 pm Last Edit: Aug 09, 2018, 04:46 pm by a2retro
I am in the same boat as Riccardo with the current and previous generation bitstream for VidorGraphics I get version FFFFFFFF but i do get a version number with VidorPeripherals bitsteam.

I seem to have got myself into a situation where the bootloader logo is no longer showing up on a double tap.

Update: I was able to restore the bootloader and see the graphics boot screen again. I uploaded a new VidorPeripherlsTest script successfully  . I then tried VidorGraphics again on a new windows 10 PC- stuck at 37% and now my bootloaders toast again - no graphics.


hi guys,
i think i'm narrowing down the issue to a single problem related to flash speed. for the brave and patient who want to test, i am attaching another beta here. this reduces the speed of the flash and should return version 1010105.
please let me know if this works for you.
if you don't want to receive verification errors you should also update signature in VidorGraphics.cpp as follows:

const unsigned char signatures[4096] = {
   //#include "signature.ttf"

   0x00, 0x00, 0x08, 0x00,
   0x44, 0x75, 0x06, 0x00,
   0xea, 0xb8, 0x9c, 0x25, 0x5d, 0x12, 0x98, 0x03, 0x9c, 0xaa, 0xb5, 0x7b, 0x31, 0xee, 0xfc, 0x58, 0xea, 0xbd, 0x14, 0x65, 0xfb, 0x70, 0x2f, 0x86, 0xbc, 0x78, 0xa2, 0xc0, 0x23, 0x21, 0xd0, 0x9d,
   0x01, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, // force flag, change to 1 if needed

thank you very much for your patience!


Always the same result. :(

If I understand correctly, the flash is written correctly, but then it is not loaded correctly in the SRAM of the FPGA?

How is the FPGA told to load the SRAM from a particular flash address?


Hi Riccardo,
my idea is that FPGA is loaded correctly however after bitstream is loaded nios needs to fetch instructions from flash and i am supposing, based on previous comments, that the FPGA is loaded, it's jumping to the firmware in flash but then it is not running because wrong instructions are fetched.
one of the potential issues was clock speed but with this last version it has been reduced. another potential issue is that flash needs to transition to quad SPI and if the command we give is not correctly accepted data output will be wrong. unfortunately i can't reproduce the issue on boards i have here so it's a bit of a trial and error.


Aug 09, 2018, 05:09 pm Last Edit: Aug 09, 2018, 05:18 pm by a2retro
Hi Dario, just concurring with Riccardo again. I have the same result.

What is different in this process then the VidorTestSketch - which works? Other the actual functionality of the bit stream of course. :)


it's the bitstream itself. peripherals is running entirely from internal RAM whereas graphics didn't fit and needs to execute code from flash.



same result for me :

Vidor bitstream version: FFFFFFFF
number of devices 0
and HDMI display is not change

When I try to spy FLASH access with a scope, I am able to see something which look like load of user configuration (3.64 s after poweron with a duration of 65ms).
With VidorPeripherals the access to the FLASH stops, and with VidorGraphics it continues with a 5ms pause and never ends.

But as dario explained in his previous post Graphic library need to read FLASH when working.
So it seems that configuration is correctly load, but  there is still something wrong with it.


Hi guys,
Not sure you already know but we just released a new version of vidorgraphics which solves the problem. It can be downloaded from library manager that now integrates all Vidor libs


Hi Dario, looks good. Thanks. What was the final issue?


What was the final issue?
Here's the explanation from the other thread:
the issue is that the flash needs to be programmed with a flag that enables it to use quad spi commands and vidorgraphics needs that as it runs part of the code from there. a piece of code that was supposed to do it stopped working due to a modification we did last minute and we didn't recognize it as once flash has been programmed once it'll retain the setting.

Go Up