tomverbeure/panologic-g2

LX100 G2 variant drops JTAG Vref during programing

ggsubs opened this issue · 13 comments

The G2 I tested with is an LX100 variant, and during flash readback or programming, it drops Vref on the JTAG thus the programming fail. Has programming of the LX100 Pano with standard 14.7 and DLCP9 clone succeeded for others?

This is how device status looks like. Is it possible eFUSES are blocking access?

'1': Reading bootsts register contents...
[0] VALID_0 - ERROR OR END OF STARTUP (EOS) DETECTED                       :         1
[1] FALLBACK_0 - FALLBACK RECONFIGURATION ATTEMPT DETECTED                 :         1
[2] RESERVED                                                               :         0
[3] WTO_ERROR_0 - WATCHDOG TIME OUT ERROR                                  :         1
[4] ID_ERROR_0 - FPGA DEVICE IDCODE ERROR                                  :         0
[5] CRC_ERROR_0 - CYCLIC REDUNDANCY CHECK (CRC) ERROR                      :         0
[6] VALID_1 - ERROR OR END OF STARTUP (EOS) DETECTED                       :         1
[7] FALLBACK_1 - FALLBACK RECONFIGURATION ATTEMPT DETECTED                 :         0
[8] RESERVED                                                               :         0
[9] WTO_ERROR_1 - WATCHDOG TIME OUT ERROR                                  :         0
[10] ID_ERROR_1 - FPGA DEVICE IDCODE ERROR                                 :         0
[11] CRC_ERROR_1 - CYCLIC REDUNDANCY CHECK (CRC) ERROR                     :         0
[12] STRIKE CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         1
[13] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         1
[14] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
[15] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
'1': Reading status register contents...
[0] CRC ERROR                                                              :         0
[1] IDCODE ERROR                                                           :         0
[2] DCM LOCK STATUS                                                        :         1
[3] GTS_CFG_B STATUS                                                       :         1
[4] GWE STATUS                                                             :         1
[5] GHIGH STATUS                                                           :         1
[6] DECRYPTION ERROR                                                       :         0
[7] DECRYPTOR ENABLE                                                       :         0
[8] HSWAPEN PIN                                                            :         1
[9] MODE PIN M[0]                                                          :         1
[10] MODE PIN M[1]                                                         :         1
[11] RESERVED                                                              :         0
[12] INIT_B PIN                                                            :         1
[13] DONE PIN                                                              :         1
[14] SUSPEND STATUS                                                        :         0
[15] FALLBACK STATUS                                                       :         0

I don't have a LX100 device, but I also haven't tested flash programming with my LX150 device.

I was able to program the flash through JTAG on my G1, but that's obviously not very useful here.

Tom

I am experiencing the same issues here. My device is LX100 (Rev C-05) and my cable is a DLCV10 clone (Digilent HS clone).

I wonder if it's related to multiboot. Described in xtp059.pdf

The good news is JTAG loading to the LX100 works fine. So, I wonder if a direct flash erase bitstream created and loaded via JTAG, then could it wipe the golden stream/bootloader from the flash?

I replaced the flash with IS25LP064. Still the same behavior - Vref drops on the JTAG thus the flash programming fails. So it's not in the bootloader unless there is something in the eFUSE. Any ideas?

The lx150 version I have also has the same issue G2-RevB

I've run into this issue as well, but I've found a way of getting past it, and it might be a clue to what's going on.

As far as I can tell, Vref drops when iMPACT tries to load the SPI access core to the device, and the device reboots into the factory bitstream. However, if you hold down the button on the Pano while you attempt to perform a flash operation, the SPI access core will load successfully.

I wonder if loading the SPI access core is inadvertently triggering some kind of soft power-off mode on the Pano? (What's the purpose of the SLEEP_REQ and POWER_SLEEP signals in the constraints file? I don't see them described anywhere.)

No luck with the pano button in my case. BTW, I replaced the flash with a new blank IS25LP064. The whole 2.5V power rail drops during the programming. It's done by pulling the enable input on U16 (LM2830) to GND, through Q8 NPN, which is driven from the board to board connector, by some kind of power ready signal. When the power drops the green LED next to the flash making a short flash. Disconnecting the 2.5V power disable signal and forcing 2.5V always on did not help, it made the JTAG inoperable.

Hmm, interesting. The device I'm working with is a Rev A, so maybe it behaves differently in this regard… I'll have to see if I can get my hands on a later revision and get it wired up.

I have a Rev C-05...

FYI: I've been able to flash both a rev A(B?) and a rev C device successfully using the original Pano updater utility over Ethernet. See https://github.com/skiphansen/pano_progfpga. Flash the multiboot image and leave the "golden" image in place and you'll be able to flash again by loading a bitstream via JTAG to run the golden image again.

I have successfully programmed the flash on a G2 rev C using a generic FTDI 2232H board which does not use the Vref line. However, the FT2232H board will drive the JTAG lines at 3.3V level so there is a risk of damage to the FPGA but I have not seen any problems sofar. One option is to add a small resistor (say 220 ohm) in series on the signals going to the FPGA, that will limit the current.
See (https://github.com/Saanlima/Pano_G2C/tree/master/fpgaprog) for more info.

I've tested xc3sprog on both revs and it works without problems with my diligent HS JTAG adapter. The problem with Impact is most like caused by pulling the "unused" outputs to ground, the xc3sprog bit file also had the same problem until it was changed to leave the unused outputs floating.

I've also has 100% success using Impact if I hold the Pano button while programming, but that is a pain.

Make targets and the needed bit files for xc3sprog are now included in Tom's repository.