Programming Lattice MachXO2: "Password key required"?

[jrx07]

Hi everyone,

I am running into an issue programming a Lattice MachXO2 LCMXO2-1200ZE. I am using Lattice Diamond 3.12 and an FTDI C232HM-DDHSL-0 cable to program over JTAG.

Context: I made a data acquisition PCB using the LCMXO2-1200ZE CPLD (I loved using the TinyFPGA AX2 and wanted to make something with lower standby power consumption). I was able to successfully program the board initially, but when I modified the Verilog and tried to reprogram the chip, I received the following error:

"A Password Key is required. Please select a different operation in the Advanced Security Programming Mode."
ERROR: pgr_program failed.
ERROR - Process Operation Failed.

If I change the Programmer "Access Mode/Operation" to "Advanced Security File Programming/Security Read Status Register" I find that "PWD Enable" is set to '1' and "PWD Protect" is also set to '1'

I did not intentionally enable these and I don't have/can't find a password key.

My questions:

• Is it possible to disable the PWD protection?
• Where in Lattice Diamond are these settings controlled? If I bricked this chip, I just want to make sure I don't repeat this mistake in the future

[laugensalm]

If you're using a third party JTAG cable, make sure that signal integrity is met, i.e. TCK has a very fast rise time (< 6 ns) and that the cable length is very short.
To do a cheap signal integrity check, you might poll the device IDCODE for a few hours and see if a bit flips.

Unfortunately, there is no real protection against accidental misconfiguration on the MachXO* devices, I've seen a few cases getting the wrong settings by a funny sequence caused by their JTAG daemon 'lserver', however those device were in a chain of the MachXO3 types.
The internals for XO2 are documented a little sparse, but you should find the details in the Lattice tech notes describing the 'Feature Row'.
I don't recall the exact procedure, but I think I got recovery for the XO3 problem just by issueing a full 'ISC_ERASE' sequence. As long as you haven't messed with any OTP fuses, I wouldn't consider it 'bricked'.

[jrx07]

Thanks for the tips laugensalm. I did double check the signal integrity with a scope, and the signals seem OK. I like your idea of polling the IDCODE for a few hours though.

I'm a bit new to JTAG debugging. Do you have any recommendations for software tools to issue commands/read back data over JTAG?

[laugensalm]

From the OpenSource world, I'd check for OpenOCD or urjtag derivatives, at least OpenOCD should allow some TCL-scriped IDCODE polling.
That should probably suffice for the paranoia check, plus could also help you with issuing the proper erase sequences in a more low level controlled environment than the sometimes flaky Diamond Programmer. Did you succeed in restoring the feature row?

[SiliconWizard]

My questions:

• Is it possible to disable the PWD protection?
• Where in Lattice Diamond are these settings controlled? If I bricked this chip, I just want to make sure I don't repeat this mistake in the future

I've never used the protection features on MachXO2, so I may be missing something. That said, according to the "MachXO2 Programming and Configuration Usage Guide" (TN1204):

ONE_TIME_PROGRAM
The MachXO2 has One Time Programmable (OTP) fuses that can be used to prevent the on-chip memory from
being erased or programmed. The MachXO2 device has three OTP security fuses, one for each of the following
memory sectors: SRAM, Configuration Flash, and UFM. This preference provides options to set the OTP security
for each memory sector.

If you ever set those security bits by mistake, there's nothing you can do, as they are OTP.

As to how to avoid doing this, I guess if you never use any of the advanced programming modes, you should be fine. What was the programming mode you used?

[jrx07]

From the OpenSource world, I'd check for OpenOCD or urjtag derivatives, at least OpenOCD should allow some TCL-scriped IDCODE polling.
That should probably suffice for the paranoia check, plus could also help you with issuing the proper erase sequences in a more low level controlled environment than the sometimes flaky Diamond Programmer. Did you succeed in restoring the feature row?

Thanks I'll try out OpenOCD and post any results! I screwed up my FTDI drivers earlier today intalling urjtag, which has caused my FTDI cable to longer be recognized by Lattice Diamond or FTDI's FT_PROG (cable still recognized by both programs on a different computer though,), so need to solve that problem tonight.

I haven't had luck restoring the Feature Row. From the Lattice documentation it seems that's a feature in the standalone "Programming File Utility", but not in Lattice Diamond v3.10 or v3.12. I couldn't seem to install the Programming Utility though...have you tried this in the past?

As to how to avoid doing this, I guess if you never use any of the advanced programming modes, you should be fine. What was the programming mode you used?

Thanks for the info about accidentally setting the fuses. I had used the "Flash Programming Mode" with the "FLASH Erase, Program, Verify" operation. No errors were reported when I did so. Problems only came up afterwords.

I do wonder if perhaps when I was programming the power became momentarily disconnected which messed up the configuration?

[asmi]

It kind of reminds me of AVR micros - I think everybody who ever worked with them as standalone MCUs (not in Arduino) bricked it at least once Fortunately it's reversible in many cases for those MCU, but messing with OTP fuses is always a dangerous affair, infact I don't ever touch them even on my production boards on the off-chance I will ever need to do a field update.

[jrx07]

It kind of remind me of AVR micros - I think everybody who ever worked with them as standalone MCUs (not in Arduino) bricked it at least once Fortunately it's reversable in many cases for those MCU, but messing with OTP fuses is always a dangerous affair, infact I don't ever touch them even on my production boards on the off-chance I will ever need to do a field update.

This was my first board with the MachXO2, so hopefully I'm getting the bricks out early in the process 

For anyone who encounters this in the future, I figured out the FTDI C232HM cable error...it seems that installing libusb to try have urjtag recognize the cable caused Lattice to no longer recognize the cable. Thinking the FTDI driver didn't install properly, I tried reinstalling it several times. This was my mistake! This essentially created several copies of the driver on my system. To fix the problem, I went to the Device Manager, plugged in the cable, uninstalled the C232HM device that popped up, unplugged the cable...and repeated this process until plugging in the cable no longer caused a device to pop up. At this point, I could reinstall the FTDI drivers and now the cable is recognized by Lattice Diamond. TLDR: don't just reinstall the FTDI drivers multiple times if things aren't working

Will post again soon once I have a chance to try OpenOCD

[jrx07]

I tested the MachXO2 again today with Lattice Diamond and with a python script based on PyFTDI(https://github.com/eblot/pyftdi/blob/master/pyftdi/jtag.py).

After all of this it seems like the issues might be caused by an unstable physical connection between the JTAG connections and the MachXO2 chip.

Using PyFTDI "jtag.py" script and changing the JTAG instructions to match fthe MachXO2 programming commands (p.51, https://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/MO/MachXO2ProgrammingandConfigurationUsageGuide.ashx?document_id=39085) I could successfully query the chip and receive the expected ID code. The FTDI C232H cable is readily recognized by Lattice and by Python (have to run Zadig to switch the driver from FTDI to WinUSB), so the FTDI chip doesn't seem to be the problem.

In Lattice Diamond, I  found that the chip would occassionally (maybe half the time?) issue the error requiring the programming key. Other times, when trying to perform the operation "FLASH Erase, Program, and Verify," I received an error that the Verify command could not be completed, but no mention that a programming key was necessary.

It seems like there's an intermittent failure somewhere in the signal chain based on the inconsistent response. I unfortunately can't run more tests until Monday, but will do so with a QFN breakoutboard and another MachXO2 to see if the physical PCB is the problem. Thanks for all the helpful tips so far.

[SiliconWizard]

OK, thanks for the heads up.
And I wouldn't be hugely surprised if Lattice's programming tool gave funky misleading errors in case of data corruption during the JTAG exchange with the FPGA. It seems to be ridden with dubious error handling and hard-coded pauses here and there. =)
So yes, if you can use something else for programming, do not hesitate.

[laugensalm]

These issues with the Lattice Programmer are also present on a Linux system (which *should* be a more controlled environment with respect to FTDI driver issues). From what I remember looking into it, the dangling JTAG daemon and those reported spurious timeouts would leave the JTAG chain in an undefined state, requiring full restarts/killing the daemon exe manually. However, these are pure software issues that have been reported to Lattice Tech support repeatedly, without any improvement seen up to Diamond v3.12 (last tested).
For mass programming, this is (probably still) very frustrating, I had to go for a custom solution.

On the JTAG hardware side, it might appear as a surprise, but it may very well be that you don't see TCK glitches on a typical 1GHz scope but still get occasional misbehaviour induced by cross talk due to the very fast input buffer technology of the MACHXO* (assuming the JTAG logic is not any different). So, any programmer based on older FTDI 2232L chips without any extra buffering might likely behave unstable.

[SiliconWizard]

These issues with the Lattice Programmer are also present on a Linux system (which *should* be a more controlled environment with respect to FTDI driver issues).

It's every bit as horrible on Linux indeed.
And for the record, the FTDI "drivers" for Linux (which are not drivers per se, but a library on top of libusb) are rather bad from my experience. So, if this is what Lattice uses (which is very likely), it's not going to help.

(To get fast and reliable communication using FTDI parts on Linux, I resorted to writing my own lib (on top of libusb).  You can get some inspiration with libftdi - but back when I did this, libftdi was lacking some features, so I wrote my own one.)

[jrx07]

For anyone who stumbles on this error in the future, double (triple, quadruple) check the physical connection of your programmer to your device and be sure that the voltage levels are correct. Thanks for the help everyone.