ispLSI 1032E Programmieren über JTAG geht nicht

Vielleicht ist es ein Nachfolgetyp mit anderer Kennung
http://www.latticesemi.com/~/media/LatticeSemi/Documents/DataSheets/ispLSI/ispLSI1032EDataSheet.PDF?la=en
da steht schräg drüber "neuen Typ ispLSI1032EA verwenden"
Ich fürchte, die Kennung steht nicht im Datenblatt, aber vielleicht im 
Boundary-scan-File.
http://bsdl.info/download.htm?sid=b7a5e55ec84fc80c88ca59b002289d77

   -- IDCODE Definition

   attribute IDCODE_REGISTER of ispLSI1032EA: entity is
   "0000" &                                       -- version
   "0000001100101110" &                           -- part number (032E)
   "00000100001" &                                -- manufacturer's 
identity
   "1" ;                                          -- required by 1149.1

   -- USERCODE Definition

   attribute USERCODE_REGISTER of ispLSI1032EA: entity is
   "11111111111111111111111111111111";

IDCODE:   00000000001100101110000001000011
0x0032E043

naja da sollte man sich erst mal einlesen

Die Signale sind sauber (5 cm Verbindung zum FT2232H).
Die ispLSI ist eine 1032E, keine 1032EA.
Test mit 2 ispLSI 1016 -> gleiches Problem.
Test mit ispLSI 2064VE -> funktioniert.

Ich vermute die alten ispLSI lassen sich nicht mit FT2232H ansprechen(?)

Hier habe ich noch das alte Windows-Download.exe von Lattice, das hat am 
Druckerport noch unter XP funktioniert. Das Interface bestand aus ein 
paar Vorwiderständen zur Strombegrenzung und einem Tristate-Buffer.
Beitrag "Re: ISPLS2032 Programmieren"
da ist die Schaltung

Ich sehe gerade, ohne das .sdn-File startet es nicht (mit Wine unter 
Ubuntu - vermutlich läuft es so nicht wirklich)

Christoph K. schrieb:
> Hier habe ich noch das alte Windows-Download.exe von Lattice, das hat am
Mit den alten Sachen vom isp-Starter Kit will ich nicht anfangen...


ich habe mal in der IODD.svp rumprobiert:

1

function READ_ID {

2

  int32 TotalLength = 0;

3

  TotalLength = ID_Length+(TOTAL_TID_LENGTH)+(TOTAL_HID_LENGTH);

4

  STATE ispIDLE;

5

  SDR_VERIFY  TotalLength  TDI (#1^TotalLength)

6

              TDO  ((#1^(TOTAL_TID_LENGTH))@IDTDI[1]@(#1^(TOTAL_HID_LENGTH)))

7

              MASK ((#0^(TOTAL_TID_LENGTH))@DEVICE_ID_MASK@(#0^(TOTAL_HID_LENGTH)));

8

}

wenn man eine von den Längen erhöht kam sogar die richtige ID.
Kann aber mit dem Script nicht wirklich was anfangen: #0^ ????

Ansonsten lass ich es lieber und nehme andere CPLD's.

Ich verwende ein FT2232H-Modul als Programmieradpater. Ein Parallelport 
steht  hier nicht zur Verfügung.
ispEN liegt per Draht auf Masse da dieses Signal nicht angesteuert wird.
Komisch ist nun, dass der Scan Chain das CPLD richtig erkennt aber der 
Befehl "Display ID" nicht funktioniert (s.o.).

Ich habe auf einem alten XP-Rechner mit Parallelport das auch nochmal 
ausprobiert. Dort funktioniert alles.

Rudolph schrieb:
> Läuft da die gleiche Programmversion wie auf dem anderen Rechner?
ja, die gleiche ISPVMSystem.
Nun auch nochmal unter Windows 7 32-Bit probiert: gleiches Problem

>
> Fragt "Display ID" denn tatsächlich den IDCODE ab, oder irgendeine
> andere ID? "SDR 8   TDI(FF)" ist ja ein bisschen kurz für den IDCODE...

Ist die ID von Scan Chain die gleiche wie bei Display ID?
Die ID's sind hier nur 8-Bit breit.

Noch eine Korrektur:
Die ispLSI1000er haben kein JTAG sondern verwenden die propri-
etary Lattice ISP State Machine.

Ich habe das Get ID Timing aufgezeichnet.
Gleiches Ergebnis bei Scan Chain und READ ID.
Leider kann ich das Ergebnis nicht richtig verstehen:
1. Mode=1, 7 Takte -> ID wird in das Shift-Register eingeschrieben (LOAD 
ID)
2. Mode=0, b0 von der ID liegt an SDO
3. nur ein (?) Takt, b1 von der ID liegt an SDO (ShiftID)

Warum nur 1 Takt?