Jtag with a lattice LCMX0256C Rigol 1052e

[GGMM]

Hello,

I try to repair an oscilloscope
see here: https://www.eevblog.com/forum/repair/startup-rigol-1052e/msg5068690/#msg5068690

I tried with TopJtag to see the chain , but without success.
By cons when I connect only a component I see the Blackfin, but never the lattice. (Error no Jtag chain)

see here some exemple that works!!
https://www.eevblog.com/forum/testgear/backup-firmware-dg1022/

With them it works and they see  the 2 components.

I read this documentation (see  datasheet), do you think that sleep is activated and prevents the Jtag channel from working?  See p 2-21
It works correctly on other posts (See post before) with Rigol 1052E
Strange???

an idea?

cdt

[GGMM]

.....Or Usb blaster not compatible with lattice?

Something to modify on connexion?? I have tested with  pullup resistor, it's the same

?

cdt

[darkspr1te]

If you have a arduino compatible device laying around you could try the jatgulator /jtag finder code and it will confirm the pinouts are correct, it also test for pullup /down configs too. I have used it to confirm lots of jtag interfaces,it will also test for jrst which some device need before you scanchain




darkspr1te

[GGMM]

Hello Darkspr1te,

I looked at the motherboard. There is in pin 48 a 4.7k pullup resistor connected to the 3.3v.
So we are in compliance with the documentation. Signal sleep high = Jtag chain activated.
it's a good thing.

i have not a Jtagtor /find.

At this time the question is: a CLONE  Usb Blaster (Cheap China product) can work with a lattice  y/n?
Do we need a special jtag programmer for this Lattice component  as product Jtag SPI Programmer for LATTICE FPGA.
? I don’t know.

if somebody can confirm it's work whith an Usb Blaster
cdt

[ataradov]

If you see at at least one device in the chain, your tools work. It is impossible to work with just one device in the JTAG chain and completely ignore the rest.

I would double check that Lattice device is actually in the chain, there may have been a board revision.

Wait, the other post you linked seems to have Altera FPGA in the chain. I'm confused.

[GGMM]

Ataradov,

There are actually in my chain 2 components as precised altera and blackfin

When both components are wired, the chain is not detected.
When I test one component at a time, I detect blackfin, but not alter it. (Of course the wiring is modified to test one / by one)

So, as the altera is never  seen, necessarily the blackfin is not also seen because they are chained at this time of the test.
Something "blocks" the altera.
I think you understand me.
Maybe there’s a connection problem on the altera?

see example:
https://www.eevblog.com/forum/fpga/first-fpga-pcb-jtag-unable-to-scan-device-chain/

i will inspect the mother board

cdt

[ataradov]

There is a simple test for JTAG chains. Make sure that the scope is power cycled, then connect logic analyzer to the TDO of the last device in the chain and apply some clock to the TCK (from a signal generator or something like that). By default all devices will have their IDCODE register selected in the chain. Capture the first 64 bits and see if they correspond to the expected devices in the chain. This is a simple method that eliminates all the tools from the suspicion.

I would also check if Altera has some soft of code protection or JTAG disable function and if that may be set.

[GGMM]

Ataradov,

I took apart the motherboard and looked at the connexions.
If I test the Jtad connexions  on the blackfin with an Ohmeter , the values are a few kiloOhms.
Where it becomes very strange is that on the Altera the values are either an open circuit, or 0.7MégaOhm according to the direction of the ohmeter.
Except the TCK at a few kiloOhms.
And this is not finished, if I press a little on the card, it goes from 0.7 MégaOhm to...11KiloOhm.  Ha!!!
So, there is something strange on this board.

Tomorrow when I see more clearly, I’m going to blow a hot air on the altera to see.
There must be some kind of dry weld somewhere.  Where??? I took apart the motherboard and looked at the connections.
If I test the Jtad connections on the blackfin with an Ohmetre, the values are a few kiloOhms.
Where it becomes very strange is that on the altera the values are either an open circuit, or 0.7MégaOhm according to the direction of the ohmeter.
Except the TCK at a few kiloohms.
And this is not finished, if I press a little on the card, it goes from 0.7 MégaOhm to...11KiloOhm.
So, there is something on weld on the board.
Tomorrow when I see more clearly, I’m going to blow a hot air on the altera to see.
There must be some kind of dry weld somewhere.  I hope it’s not between the layers...LOL

to be continued.....
cdt

[SiliconWizard]

Still not sure why you talked about a Lattice part that turned out to be Altera? Confusing.

[GGMM]

hello,

It’s not always easy to speak French to English. I use a translator.

I repeat the following post to understood.   https://www.eevblog.com/forum/testgear/backup-firmware-dg1022/
Look at the hand-made diagram, we see the Altera and not the lattice.

Yeah, it’s a little confusing talking about Lattice and Altera.

If we follow all the posts on this subject, we always talk about chaining JTAG  the lattice and the blackfin.

The goal is to reprogram a firmware, it’s complex.
This firmware can be installed in part in the S29GL032, and part in the lattice. I understood it like that with all posts on this subject.
 You have to read the posts about it, there are hundreds of pages.
This is a subject that dates back 10 years, we must get back in.

For now, the main point is to operate the Lattice alone in JTAG.  It's must work, but not on my board.
And there, no result for the moment.
Perhaps someone could measure the impedance on the Lattice’s JTAG port. I find strange results (Open, or 0.7Mohm), but TCK only some KOhm.
See the picture of connxion

So I’m digging this trail.

cdt

[GGMM]

the picture

[ataradov]

Resistance from what to what you are measuring. You are doing some strange things.

If devices are in the chain, then TMS and TCK must be connected together. And TDO if one must be connected to the TDI of another. Are they connected this way?

Also, what is the deal with Lattice vs Altera? Is this a different board revision or what?

[GGMM]

Ataradov,

I think it is difficult to be understood. lol

I break down the steps:

1st) when I connect the Jtag chain for the 2 components (Lattice and blackfin) and this in the rules of art, the chain is not detected. (Yes there is the TDO/TDI link between the 2 components)

2eme) When I connect ONLY the blackfin, IT IS RECOGNIZED.  (Only wires in this case on connector blacfin   + 3.3v)

3eme) When I connect ONLY the lattice, it is not recognized, (Only wires in this case on connector Lattice, 3.3v included)
 so this explains that point 1 does not work. 

The question is always the same, Why is the Lattice not seen in jtag chain  with the USB Blaster and TOPJtag software?

In the posts I put the link, it works but Wiggler connection.

I put in red, the USB blaster connexion for the complete chain  (See picture)

I opened my USB Blaster, there is only one active component a CH552 ang regulator
it is noted on the serigraphy.

1 TCK 2 GND
3 TDO 4 UL
5TMS 6NCE
7 ASDO 8NCS8
9 TDI 10 GND
so only the same question, What is missing for the lattice to be seen with the USB Blaster?


cdt

[GGMM]

I wonder if it does not need a particular driver for the usb blaster to recognize the lattice in the device manager?
Frankly I’m stuck

exemple:
https://www.latticesemi.com/support/answerdatabase/2/0/8/2081

some idea?

cdt

[ataradov]

What exact lattice chip is this?

[GGMM]

Ataradov,

it's on tittle of the post
Lattice LCMXO256C

cdt

[ataradov]

Ok, this device has code protection, but it looks like it does not entirely disable the JTAG port, so I would expect identification to work.

I would do my experiment with clocking the Lattice JTAG port directly and observing its TDO output after the power cycle. If it does not shift out the IDCODE, then it is either dead or something else is wrong.

[GGMM]

Ataradov,

I haven’t checked the Jtag signals with my other oscilloscope yet.
I came to almost the same conclusion that the circuit is down, but the Rigol bootes well and freezes after 6seconds.
The design is quite complex and as said before the firmware seems scattered on several circuits. It is interesting to look for the breakdown, but we are exhausted a little by force.
Meanwhile I looked for another driver and I found one. The problem is that it made me a blue screen of death.
So I went back to the one in quartus directly on the USB Blaster folder. (As at first installation, it's like a come back)  --> Now no bleu screen!
I have also installed the quartus version. it's the 13.1, not sure it is the last but I could do a test with, knowing that I do not know at all this software, so to discover.
I’m not sure this is the latest version.

INTEL also specifies to use this driver in the USB Blaster folder and not to choose the one in X32 or X64 folder.(It's that i have do to reinstall it)

Now the Usb Blaster  is a revision C model based on a CH552 I think, i don't know is this driver is completly compatible with it.

I found this artical, to be read:
https://en.kohacraft.com/archives/install-chinese-usb-blaster-drivers-to-windows-10.html

Well, this is the night here and as said, it carries advice
A+  for futures adventures! LOL

[GGMM]

For your information in device manager:

Le périphérique USB\VID_09FB&PID_6001\FFFFFFFF a été démarré.

Nom du pilote : oem32.inf
GUID de classe : {36fc9e60-c465-11cf-8056-444553540000}
Service : AlteraUSBBlaster
Filtres inférieurs :
Filtres supérieurs :


good night

[ataradov]

If that JTAG adapter can see one device, it is fine, there is no need to mess with it. It is just a dummy translator from USB to JTAG, all the scan logic is implemented in the software.

[GGMM]

Ataradov,

Here is a video I found. (In russian)
This looks except that it is a Siglent.



Strangely it must chain 2 connections Jtag, but one is different (A right connector not soldered) and the other with 6 pins (left) does not seem used. The problem we see no wiring on the video and it seems in contradiction with everything I could read on the posts!
Note that its activity light is always on.

I’m even more confused
To dig.

cdt

[ataradov]

I don't know why he did need to get both devices at the same time. It is possible that MAX V CPLD is somehow also involved in the connection to the target flash, so he needed to control both devices at the same time.

But again, we are looking at wildly different designs with move MAX V entering the picture.

Stop doing random stuff and start doing things that are known to work.

[GGMM]

Hello Ataradov,

Yeah, it’s hard to figure out what’s going on. I am not a specialist engineer of FGPA or other and indeed I am trying to find what is wrong. It’s a retired hobby
On eevblog, I found a post where you intervened.
https://www.eevblog.com/forum/beginners/custom-fpga-dev-board-not-working/
help on:
https://www2.lauterbach.com/pdf/training_jtag.pdf

My idea is to know if it is possible to record what happens on the differents signals Tdi, tdo, etc to see.
I know it works with one component, not the other.

We are talking about a trace32 program.
Can be used with a USB blaster without add some extended card (?) and where to download it.
It would be ideal if it records the traffic of Jtag pins, I think you understand what I mean

It’s not easy for me to translate back into French all articals on the net, and there are so many different links. (nb: I don’t have a brain of 20 anymore.  LOL)
If you can give me a download link that might work for this type of software  if you think it’s a good idea.

cdt

[ataradov]

You need to get a logic analyzer and you will be able to record all the signals. It is a p piece of hardware. There are very common Saleae clones that are <$20. You can also use oscilloscope if you have one.

You can use any MCU board where you can drive a couple pins (like Arduino, but mind 3.3V levels).

[GGMM]

Hello Ataradov,

Today I demonstrated the USB Blaster
As already said, there is only one CH552 and a regulator.
The regulator is a 3.3V model and supplies the circuit with 3.3V.
Pin 4 is actually not wired (Generally used to power a circuit type 244 to have signal voltages equal in amplitude to the voltage of the circuit under test)
The resistors that go to the signals tms, tclk, tdo, tdi are 22 ohms. (I thought I read in an article that it may be a little weak and that it would take 100 ohms?)
Without considering the design, I looked at the signals one part at the oscilloscope when scan the chain. There is at one time a variation 0/3.3v or reverse.
All seem good...

I installed TOPJtag probe and discovered that there is a small log.

This is where it becomes interesting to read, but for a specialist like you.
We seem to be detecting something, but? 

here a part of the most interisting in the log:


TopJTAG Probe 1.7.5, build 1551, May  1 2012
Creating CrUsbBlaster
Loading USB-Blaster FTD2XX interface:
Loading usbblstr32.dll ...  OK
Found 1 USB-Blaster device(s)
Destroying CrUsbBlaster
Creating cable object  ALTERA_USB_BLASTER
Creating CrUsbBlaster
Loading USB-Blaster FTD2XX interface:
Loading usbblstr32.dll ...  OK
Device successfully opened
Initialization succeeded

.......
Analyzing the JTAG chain...
TAP reset
Scan DR...
Bits to be shifted in:
11111111000000000000000000000000+
00000000000000000000000000000000+
00000000000000000000000000000000+
00000000000000000000000000000000+
00000000000000000000000000000000+
00000000000000000000000000000000+
00000000000000000000000000000000+
00000000000000000000000000000000+
000000000000
Bits shifted out:
11000010000000000000000000000000+
00000000000000000000000000000000+
00000000000000000000000000000000+
00000000000000000000000000000000+
00000000000000000000000000000000+
00000000000000000000000000000000+
00000000000000000000000000000000+
00000000000000000000000000000000+
000000000000



.........

Checking for all bits are either ones or zeros...
Last 500 bits we received are either only ones or only zeros
JTAG chain NOT found, checking for Atmel ATmega bug...
Received bits have both ones and zeros
IDCODE register
11000010000000000000000000000000
BYPASS register
BYPASS register
BYPASS register
BYPASS register
BYPASS register
BYPASS register
BYPASS register
BYPASS register
BYPASS register
BYPASS register
BYPASS register
BYPASS register
BYPASS register


.......N Times

BYPASS register
BYPASS register
Some idcode(s) collected
NO JTAG chain found


cdt

[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