search

MEGA65 / mega65-tools

Tools and Utilities for the MEGA65 Retro Computers
GNU General Public License v3.0
30 stars 31 forks source link

Injecting a bitstream in the FPGA won't work if there is a core loaded in slot 1 #126

Closed paich64 closed 2 years ago

paich64 commented 2 years ago

Test Environment (required)

Describe the bug M65connect provides the ability to inject a bistream inside the FPGA using m65 -q

To Reproduce Steps to reproduce the behavior:

  1. Ensure a core is loaded in SLOT1
  2. Power Off / Power ON the MEGA65
  3. Launch M65connect v2
  4. Click on "BIT" button
  5. Select a .bit file (version must be different from the core loaded in slot 1)
  6. Click on "Send"
  7. Wait for the bitstream to be injected which results in the MEGA65 self-rebooting
  8. Enter the MATRIX (MEGA/TAB) and check the active bitstream version : It's identical the the one which is loaded in slot 1
  9. Close M65connect
  10. Power off / Power On the MEGA65, holding NO/SCROLL
  11. clear slot 1 (CTRL+1, clear)
  12. Power off / Power On the MEGA65
  13. Launch M65connect v2
  14. Click on "BIT" button
  15. Select the same .bit file used to show evidence of the issue
  16. Click on "Send"
  17. Wait for the bitstream to be injected which results in the MEGA65 self-rebooting
  18. Enter the MATRIX (MEGA/TAB) and check the active bitstream version : It matches the version of the injected bitstream

The test was done using 2 different bitstreams from mid 2022

Expected behavior Even if there is a core loaded in slot 1, injecting a different bitstream into the FPGA with m65 -q should result in having this injected bistream active after the MEGA65 self-reboots.

Screenshots If applicable, add screenshots to help explain your problem.

Additional context M65connect uses "m65 -q" to inject the bitstream.

lydon42 commented 2 years ago

Is this windows bitstream pushing via libusb or using vivado?

paich64 commented 2 years ago

My mistake, in the description i wrote "Launch MEGA65 V2" while i meant M65connect V2. The bitstream is pushed using m65connect V2 which uses m65 -q to push the bitstream.

paich64 commented 2 years ago

when you say "Is this windows bitstream pushing via libusb or using vivado?" do you mean that if vivado is installed, then by default it will be used to push the bistream ? Because yes, vivado is installed on My win 10 PC.

lydon42 commented 2 years ago

m65 can use libusb (as far is I know), but only if you have installed it (which seems to be a tedious process). So the question is valid: which one is it? There should be something in the m65 log about "writing vivado.bat"

paich64 commented 2 years ago

When I send to bitstream (using M65connect) i can't find any log file for m65.

The only information i have is in the M65connect console :

=========== XC3SPROG (c) 2004-2011 xc3sprog project $Rev$ OS: Windows Free software: If you contribute nothing, expect nothing! Feedback on success/failure/enhancement requests: http://sourceforge.net/mail/?group_id=170565 Check Sourceforge for updates: http://sourceforge.net/projects/xc3sprog/develop

Using devlist.txt Using cablelist.txt Cable ftdi type ftdi VID 0x0403 PID 0x6010 dbus data 00 enable 0b cbus data 00 data 00 Libusb not found, expect failure Could not open FTDI device (using libftdi): usb_find_busses() failed Using FTD2XX, Using JTAG frequency 1.500 MHz from undivided clock JTAG chainpos: 0 Device IDCODE = 0x13636093 Desc: XC7A200T Created from NCD file: container;COMPRESS=TRUE;UserID=0XFFFFFFFF;Version=2021.1 Target device: 7a200tfbg484 Created: 2022/03/05 00:27:45 Bitstream length: 49253696 bits done. Programming time 33016.0 ms USB transactions: Write 3036 read 25 retries 0 ial Monitor build GIT: master,20220622.03,2384553

In this example i tried to send the bitstream from March 2022 178.0 | mega65r3-dev.bit | 6.2 MB | From Jenkins-CI: development branch(development@ee4f29d), build 178

paich64 commented 2 years ago

Is it possible to push the bitstream by directly using m65.exe ? I can't find any m65.exe option to log to a file.

paich64 commented 2 years ago

Just found this In m65connect embedded documentation :

Important note: If you have an existing Bitstream in Slot 1 it will be started instead the loaded Bitstream by x3C. But you can skip this by holding NO SCROLL while transferring the Bitstream, so that it stops in the Flash Menu on restart. Then you can just press RUN/STOP to boot normally the loaded Bitstream without trying to load from the Flash menu.

I tried it, but the result is the same : After the bitstream has been uploaded, the Mega65 resets, and when checking in the Matrix the version of the active core is the version of the core loaded in slot 1.

lydon42 commented 2 years ago

So this is no mega65-tools bug, but a side effect of M65Connect using XC3SPROG on windows for flashing.