Jtag with a lattice LCMX0256C Rigol 1052e

[ataradov]

This test tries to do exactly what I described. It shifts in a sequence 1111100000...... and observes the output. After the power cycle (or the TAP reset if TRST JTAG pin is connected) the  first value that is shifted out would be the IDCODE.

This is a good test, but you need to make sure to do this right after the power cycle before doing anything else with JTAG, since you don't have TRST pin.

So, power cycle the scope and run this test. Does result stay the same?

In this case it is strange that it shifts out 1100001000...... I would have expected all 0s. But it is possible this is the result of you doing stuff with the JTAG port before running that test.

[GGMM]

Re,

I put an answer that I got on another forum.
https://community.intel.com/t5/Programmable-Devices/USB-blaster-and-LCOMX256C-Lattice/td-p/1536288

From what I understood, the USB Blaster simply does what is asked by the software and should work with this component.
I don’t know any more than that.
Only thing I could read is to add a 4.7kohms/ Ground pull resistor on the TCK signal
I’ll test it tomorrow


THE ANSWER:

That is not quite accurate is to what goes on inside the USB-Blaster series of device.

Here is a simple block diagram of a USB Blaster. Basically just a USB to byte parallel FIFO transceiver.
Could also use a USB to serial protocol transceiver with the appropriate change in the interface to the
EPM7064 CPLD device.

In particular the USB Blaster knows NOTHING about the Altera/Intel device bitstream or file encoding per se.

It ONLY knows how to twiddle the JTAG lines based on simple commands sent from the host (JAM STAPL here,
or Quartus Programmer, etc).

So the USB Blaster is really a pretty general purpose USB to JTAG interface device that about any host software
could use to interface to JTAG.

/*
 * USB-JTAG, Altera USB-Blaster and compatibles are typically implemented as
 * an FTDIChip FT245 followed by a CPLD which handles a two-mode protocol:
 *
 *            _________
 *           |         |
 *           | AT93C46 |
 *           |_________|
 *            __|__________    _________
 *           |             |  |         |
 *      USB__| FTDI 245BM  |__| EPM7064 |__JTAG (B_TDO,B_TDI,B_TMS,B_TCK)
 *           |_____________|  |_________|
 *            __|__________    _|___________
 *           |             |  |             |
 *           | 6 MHz XTAL  |  | 24 MHz Osc. |
 *           |_____________|  |_____________|
 *
 * Protocol details are given in the code below.
 *
 * It is also possible to emulate this configuration using a single-chip USB
 * controller like the Cypress FX2.
 */
From the comments in the JAM STAPL USB Blaster interface driver describing the USB Blaster protocol. The simplest mode
is to just use the BIT BANGING mode with bit 7 set to zero. Then bits 4,1,0 set TDI, TMS, TCK based on their value. TDO can
be read back by setting bit 6.

That's all the USB Blaster does. Really pretty simple just bit banging the JTAG pins. It does not care what kinds of devices
are connected, just that they follow the JTAG serial protocol.

But the complexity is that you have to send JTAG commands to devices that they understand.

And of course any software that wants to use the USB Blaster to talk JTAG needs to follow the below protocol definition.

/* The following code doesn't fully utilize the possibilities of the
 * USB-Blaster. It only buffers data up to the maximum packet size of 64 bytes.
 *
 * Actually, the USB-Blaster offers a byte-shift mode to transmit up to 504 data
 * bits (bidirectional) in a single USB packet. A header byte has to be sent as
 * the first byte in a packet with the following meaning:
 *
 *   Bit 7 (0x80): Must be set to indicate byte-shift mode.
 *   Bit 6 (0x40): If set, the USB-Blaster will also read data, not just write.
 *   Bit 5..0:     Define the number N of following bytes
 *
 * All N following bytes will then be clocked out serially on TDI. If Bit 6 was
 * set, it will afterwards return N bytes with TDO data read while clocking out
 * the TDI data. LSB of the first byte after the header byte will appear first
 * on TDI.
 */

/* Simple bit banging mode:
 *
 *   Bit 7 (0x80): Must be zero (see byte-shift mode above)
 *   Bit 6 (0x40): If set, you will receive a byte indicating the state of TDO
 *                 in return.
 *   Bit 5 (0x20): Output Enable/LED.
 *   Bit 4 (0x10): TDI Output.
 *   Bit 3 (0x08): nCS Output (not used in JTAG mode).
 *   Bit 2 (0x04): nCE Output (not used in JTAG mode).
 *   Bit 1 (0x02): TMS Output.
 *   Bit 0 (0x01): TCK Output.
 *
 * For transmitting a single data bit, you need to write two bytes. Up to 64
 * bytes can be combined in a single USB packet.
 * It isn't possible to read a data without transmitting data.
 */
 

[ataradov]

From what I understood, the USB Blaster simply does what is asked by the software and should work with this component.

Yes, I already told you that. I also told you that your tool is fine if it can see any device at all. Don't mess with it.

I already described the test you need to do. If that test does not work, then there is no point in trying anything else.

[GGMM]

Ataradov,

Look at this post, it’s equivalent to my concern.
A priori, for those where it worked, they used a Wiggler adapter. There may be a problem with a USB Blaster. I do not know.
It’s a shame, there is no continuation...
Nb, BDSL files are present, but must be used after detection.
I continue my search.
cdt

https://www.eevblog.com/forum/repair/need-full-firmware-(full-dump-flash)-oscilloscope-atten-ads-1062cml/msg3082549/#msg3082549

[ataradov]

Ok, you are not going to do the debugging steps I tell you to do. This is not going anywhere.

[GGMM]

Ataradov,

Here is a video that can explain some phenomena.   >>Bounce on signals for example....Speed signal??



In fact you have to use a Jtag debugger to test to see what append onthe chain.
Always to  see the component code again if i have understood.

 this tool  seems integrated in Quartus.
Well, it gets complicated, I didn’t do UCLA or Cambridge. LOL

It takes time, but well, it becomes a challenge.

to be see
cdt

[ataradov]

I'm not watching any videos or reading any other links. I told you what to do to start diagnosing this issue. I'm done with this thread.

[danilnik]

If this helps someone, I can share the S29GL064 dump

[GGMM]

Hello all, hello Ataradov

I had left aside my detection of chain Jtag with the lattice machxo. Meanwhile, I ordered for a few euros an adapter type Wiggler.
This day having a little time, I first improved it a little by adding a 1kohm resistance and a jumper to have an optional Trst signal. There is also a location for a regulator. Too bad it is not wired for a few cents. I also made a cable to connect directly to the Jtag port of the Lattice.
I had to fix an old pc (xp) to use the parallel port.

And then, good surprise, the Lattice is well detected. Finally...

We are a little limited in speed (200K), but it has the merit of working.

So I will modify the cable, to chain the lattice and the blackfin.

Will open a new adventure with flash reading and other things.
Programming, etc. Good enough to take care of.


cdt

[GGMM]

some pictures