Hello, Guest the thread was called1.6k times and contains 50 replays

last post from mega65 at the

MEGA65 nexys4.mcs "Program Configuration Memory Device" CRC Failure

    I recently bought a Nexys 4 Artix 7 (PSRAM not DDR version) and I'm trying to program the memory device so it boots directly into MEGA65.


    I've compiled the latest nexys4.bit and nexys4.mcs files using Vivado 2019.2. Programming the memory device appears to be successful until I do a "Boot from configuration memory device" and then "Refresh Device". It shows a BIT05_0_CRC_ERROR. JP1 is set to QSPI.


    According to the Xilinx forums:

    Quote

    CRC error - The CRC error bit indicates whether the bit stream has passed "0" or failed "1" the CRC checking.

    INIT_B will also go Low when CRC errors occur, unless JTAG configuration is being used.

    CRC errors are typically due to clocking or SI issues on the board.

    If a CRC error occurs, try slowing down the configuration speed, or investigating the SI characteristics of the configuration signals (in particular, the clock line).

    So I tried setting the frequency to the lowest setting (125000). I'm not sure what "SI characteristics" are?


    I also tried doing the same with the files from official repo in the "19-4a8842d" folder. Same errors.


    I've also successfully run the following commands:

    Code
    1. $ sudo ./nexys4ddr-write-flash.sh bin/nexys4.mcs


    Code
    1. $ sudo ./nexys4ddr-run-bitstream.sh bin/nexys4.bit


    Code
    1. $ sudo src/tools/monitor_load -b bin/nexys4.bit -k bin/HICKUP.M65


    Does anyone have any ideas on why I can't get the bitstream to program from flash upon boot?

    I'll point Paul towards this Thread, i am sure he can point you into the right direction, if he finds a minute.

    Hello,


    Sorry, I have been (and continue to be) quite busy moving back from our Outback Hideout to rejoin the real world. Whether that's actually a good idea, I leave for a separate debate ;)


    Can you please send me the bitstream you made? I have an original N4 board here as well, so I can test it here.

    Did you also try just pushing the bitstream via jtag directly, i.e., not via flash?

    Also, did you set the jumpers for "boot from QSPI flash"?


    Auch sag mir nur bescheid, wenn du bequemer auf Deutsch gehen möchtest.


    LG

    Paul.

    Thanks for chiming in Paul! I can only imagine how busy you are and I follow your blog so am aware of your move! It may or may not be a good idea but at least your mail won't take weeks if it ends up in the wrong town!


    I don't have any problems flashing a bitstream it's only writing to flash. I've also tried the official latest bitstream I could find (MEGA->MEGA65 filehost->ShareFolder->Bitstreams->Jenkins-Out->mega65-core->stable_base->13-73dee8e->nexys4.mcs) and get the same CRC error.


    Just to rule out my hardware I built the Nexys4UserDemo.bit (Nexys 4 Out of Box Demo) and then ran the following:

    Code
    1. write_cfgmem -format mcs -interface spix1 -size 16 -loadbit "up 0x0 ./bin/Nexys4UserDemo.bit" -file ./bin/Nexys4UserDemo.mcs

    I then flashed Nexys4UserDemo.mcs using the same method in my first post and it runs fine. I press PROG and it runs the demo and yes I have JP1 set to QSPI.


    Just for shits and giggles I tried changing the following in mega65-core\src\vhdl\nexys4.xdc

    Code
    1. set_property BITSTREAM.GENERAL.COMPRESS FALSE [current_design]
    2. set_property CONFIG_MODE SPIx1 [current_design]
    3. set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 1 [current_design]

    ie. I changed SPI width to 1 and turned compression off. But unfortunately it didn't make a difference so I set it back to your defaults.


    So I just buiit a new bitstream using:

    Code
    1. make bin/nexys4.bit

    And generated an mcs using:

    Code
    1. write_cfgmem -format mcs -interface spix4 -size 16 -loadbit "up 0x0 ./bin/nexys4.bit" -file ./bin/nexys4.mcs

    Flashed it and get the same CRC error. I'm not new to Vivado and so I believe I'm doing it right and the "Out of the Box" demo is working as expected. So I'm attaching these files to see what you get. Thanks for taking the time again it's really appreciated!


    nexys4.zip

    There's no difference between megaphone-write-flash.sh and nexys4ddr-write-flash.sh except the latter has the correct flash part (ie. s25fl128sxxxxxx0-spi-x1_x2_x4 not s25fl256sxxxxxx0-spi-x1_x2_x4). So the result is the same (I did try it anyway but did had to change the part number for it to work).


    I was doing more research and someone mentioned using per-frame crc checking so I tried adding the setting to nexys4.sdc (it also requires that compression is disabled).

    Code
    1. set_property BITSTREAM.GENERAL.COMPRESS NO [current_design]
    2. set_property BITSTREAM.GENERAL.PERFRAMECRC YES [current_design]

    After writing to flash and booting then doing a refresh I now no longer get BIT05_0_CRC_ERROR set but now BIT00_0_STATUS_VALID is no longer set!


    Incidentally my VGA to HDMI cable arrived today so I can now see the boot up screen from a regular programmed bitstream. I get this message when I boot:

    Quote

    (First sector not empty. Code $00)

    WARNING: Flash slot 1 is seems to be messed up (code $00).

    To avoid seeing this message every time, either erase or re-flash the slot.

    Press almost any key to continue...

    Great! I thought. MEGA65 can write to the flash for me! Perhaps this is the best way to write the bitstream to the QSPI flash.


    So I pressed CTRL-1 to erase slot 1. It says "Erasing flash slot..." and appears to hang. I looked it up and found your blog related to this and read:

    Quote

    You must have started the first bitstream from the QSPI flash, if you want it to reconfigure from the QSPI flash.

    Ugh! So it appears I'm back to square one.

    I used Vivado to erase the s25fl128sxxxxxx0 (with verify clear) and it still detects it as being "messed up".


    If I try to launch slot 0 it just freezes and does nothing. If I try to erase slot 1 it also freezes.


    adtbm sent me an older bitstream which I can boot from SD card and it runs the demo fine. I still couldn't flash it to QSPI though.

    Ok. Let me try to flash it here, and see how it goes. Latest bitstream for me boots fine to OpenROMs (I don't have an SD card in it). Confirming that it doesn't seem to load the bitstream for me here, either. I'll try to take a look when I get a moment. But you can build the same bitstream as me from the head of 138-hdmi-audio-27mhz branch.


    LG

    Paul.

    So I tried the 138-hdmi-audio-27mhz branch. When I launch slot 0 ("MEGA65 FACTORY CORE") it hangs.


    When I try to erase slot 1 I get:

    Quote

    Erasing flash slot...

    sector at $00400000 erased.

    ! Failed to erase flash page at $400000

    byte $0 = $cc instead of $FF

    Please reset and try again.

    When I reboot I get:

    Quote

    (First sector not empty. Code $cc)

    WARNING: Flash slot 1 is seems to be messed up (code $CC).

    To avoid seeing this message every time, either erase or re-flash the slot.

    Press almost any key to continue...

    So I cleared the flash again in Vivado:

    Quote

    Performing Erase Operation...

    Erase Operation successful.

    Performing Blank Check Operation...

    Blank Check Operation successful. The part is blank.

    Reboot and I get the same warning code $cc.


    I hope this helps is some way and thanks again for taking a look at this!

    Hi, iirc there was something with the timing in vivado that required adjustment, so that you're able to flash the generated bitstream to the QSPI.

    Quote from adtbm

    Hi, iirc there was something with the timing in vivado that required adjustment, so that you're able to flash the generated bitstream to the QSPI.

    I was originally getting CRC errors and one of the causes is "SI characteristics of the configuration signals (in particular, the clock line)." which may be the problem you're describing above. If you're aware of the changes I need to make to adjust the clock / timing please let me know.

    Paul is definetly the better person regarding this.

    I'll drop him a note and let him now

    Another thing I noticed is in nexys4.vhdl:

    Code
    1. slow_devices0: entity work.slow_devices
    2. port map (
    3. ...
    5. -- qspidb => qspidb,
    6. -- qspicsn => qspicsn,
    7. -- qspisck => '1',

    While in nexys4ddr.vhdl it's:

    Code
    1. slow_devices0: entity work.slow_devices
    2. port map (
    3. ...
    5. qspidb => qspidb,
    6. qspicsn => qspicsn,
    7. qspisck => qspi_clock,

    Should all the qspi signal connections be commented out like this?