FTDI/JTAG buffer overflow?

Jetzt geht mir gerade auf, dass das hier vielleicht das falsche Forum 
ist...:-)

4K ist eben genau die Größe des Sendepuffers auf dem Chip. Wenn ich die 
JTAG-Frequenz runterdrehe, tritt der Fehler tendenziell häufiger auf, 
deshalb auch meine Vermutung mit dem Overflow.
Das mit den 1K Blöcken müsste ich mal ausprobieren...

Das glaube ich eben nicht. Gerade wenn ich den JTAG-Takt kleiner mache, 
die Daten also langsamer ins FPGA schiebe, tritt der Fehler ja häufiger 
auf.
Die FT_Write mag ja erst zurückkehren, wenn die Daten per USB 
abgeschickt sind, die Frage ist vielmehr ob sie auch sicherstellt, dass 
im Sendebuffer des Chips auch Platz dafür ist.

Mein Buffer is 4096 Byte groß und beinhaltet sowohl meine Daten als auch 
die FT-MPSSE-Kommandos.

Günter R. schrieb:
> Welches Kommando verwendest du denn? Irgendwie kommt mir 4096
> gesamt
> komisch vor, wenn da die MPSSE auch mit dabei sind. Ich würde eher auf
> 4099 kommen, Kommando, LengthL, LengthH, Daten (4096).
Versteh ich nicht. Ich kopiere halt die Daten in den Puffer, und sobald 
er voll ist oder ich explizit ein flush() aufrufe, wird der Inhalt 
abgeschickt. Was hat das mit den verwendeten Kommandos zu tun?

> Ich behaupte sogar dass die
> FT_Write erst zurück kehrt, wenn die Daten tatsächlich raus gegangen
> sind.
Du meinst auf dem JTAG raus gegangen? Das kann ich mir nicht vorstellen. 
Damit würde mann u.U. ja Geschwindigkeit verschenken.

> Alternativ könntest du natürlich auch ein Schreib/Lese Kommando nehmen,
> dann kehrt er 100% erst zurück, sobald die Daten durch geschoben sind...
Das dürfte den ganzen Vorgang aber auch deutlich bremsen.

Hier mal ein Code-Auszug:

1

#define TR_BUFFER_SIZE 4096

2

3

void FtJtagIO::writeBuffer(int numBytes, uint8_t *data)

4

{

5

    uint8_t *dPtr = data;

6

    while(numBytes)

7

    {

8

        if(trSize < TR_BUFFER_SIZE)

9

        {

10

            trBuffer[trSize++] = dPtr ? *(dPtr++) : 0xff;

11

            numBytes--;

12

        }

13

        else

14

        {

15

            flushBuffer();

16

        }

17

    }

18

}

19

20

void FtJtagIO::writeBuffer(uint8_t data)

21

{

22

    writeBuffer(1, &data);

23

}

24

25

void FtJtagIO::flushBuffer()

26

{

27

    if(trSize == 0)

28

        return;

29

30

    ftStatus = FT_Write(ftHandle, trBuffer, trSize, (DWORD*)&trDoneSize);

31

    Sleep(1);

32

33

    if(ftStatus != FT_OK || trDoneSize != trSize)

34

    {

35

        throw std::runtime_error("FT_Write() failed");

36

    }

37

    trSize = 0;

38

}

39

40

void FtJtagIO::shiftTdiData(uint32_t numBits, uint8_t *tdiData,

41

                            bool readTdo)

42

{

43

    int numBytes   = (numBits-1) >> 3;

44

    int numBitsRes = (numBits-1) & 0x7;

45

    char cmdRdMask = readTdo ? 0x20 : 0;

46

    uint8_t *dPtr = tdiData;

47

48

    ...

49

50

    // Write complete bytes

51

    if(numBytes)

52

    {

53

        writeBuffer(CMD_DATABYTES2TDI | cmdRdMask);

54

        writeBuffer((numBytes-1) & 0xFF);

55

        writeBuffer(((numBytes-1) >> 8 ) & 0xFF);

56

        writeBuffer(numBytes, dPtr);

57

        dPtr += numBytes;

58

    }

59

60

    // Write residual bits

61

    if(numBitsRes)

62

    {

63

        writeBuffer(CMD_DATABITS2TDI | cmdRdMask);

64

        writeBuffer((numBitsRes-1) & 0xFF);

65

        writeBuffer(dPtr);

66

    }

67

}

Ich hab das Gefühl wir reden aneinander vorbei :-)

Günter R. schrieb:
> Mit Kommandos meinte ich z.B. CMD_DATABYTES2TDI. Somit hat dein Buffer
> (der der wirklich im flushBuffer() gesendet wird) immer mehr als 4096
> Bytes. Du schickst das Zeug aber schon sobald Gesamt > 4096 ist und das
> ist der Bock, weil dir immer einige Daten fehlen.
> Schau mal in die shiftTdiData() Methode und dann siehst du sofort, dass
> immer 3 Bytes pro Aufruf dazu kommen. Den Wert CMD_DATABYTES2TDI kannst
> du in der MPSSE Doku mal nachschlagen und dann siehst du schon was ich
> meine...

Dass da Kommandos hinzugefügt werden, ist mir schon klar. Aber aus Sicht 
der writeBuffer()-Methode ist das doch völlig egal. Die bekommt einen 
beliebig großen anonymen Datenblock übergeben und kopiert diesen 
byteweise in den 4K-Transmit puffer. Immer wenn dieser voll ist, wird 
ein flush aufgerufen, der den puffer leert. Anschließend wird er wieder 
befüllt usw. Das geht so lange, bis alle Daten kopiert sind.
Was in meinem codeschnipsel nicht zu sehen ist - sollte der 
Gesamttransfer (Daten+Kommandos) nicht 4K aligned sein, werden die am 
Ende verbleibenden Daten (plus die nachfolgenden TMS-shift Kommandos) 
beim nächsten RUNTEST-Kommando abgeschickt.
Wo da jetzt Daten fehlen sollen, sehe ich nicht. Wenn das so wäre, 
dürfte das Ganze ja, unabhängig vom Sleep(), gar nicht funktionieren.

Ok, jetzt habe ich zumindest verstanden was Du mir sagen willst :-)
ABER ich sehe das wiederum anders. Der Treiber weiß doch überhaupt 
nichts von irgendwelchen Kommandos, oder sollte es zumindest nicht. 
Seine Aufgabe sollte sein, transparente Daten über USB zum/vom Chip zu 
transportieren und dafür zu sorgen, dass alles ankommt. Die 
Interpretation der Daten ist Sache der MPSSE. Und ich baue doch eine 
Abstraktionsschicht wie obige Klasse FtJagIO doch gerade deshalb, damit 
ich mich als Anwender eben nicht um irgendwelche Buffergrößen etc. 
kümmern muss.
Ich will gar nicht generell ausschließen, dass Dein Vorschlag Erfolg 
haben mag und werde es auch bei Gelegenheit mal ausprobieren. Aber ich 
bin der Meinung, dass wenn Du Recht hast dieses Verhalten ein schlechtes 
Design, wenn nicht gar einen Bug auf Seiten der FTDI-Entwickler 
darstellen würde. Und vor allem sollte es dann irgendwo dokumentiert 
sein. Man findet übrigens eine solche Sleep-Anweisung auch im 
Beispielcode einer Application-Note von FTDI, ohne dass sie näher 
erläutert wäre.
Letztlich wäre es auch noch möglich, dass es sich einfach um einen 
Hardware-Bug handelt, da das Problem mit einem anderen Design (anderes 
FPGA) nicht auftritt. Leider habe ich momentan keine Möglichkeit ein 
anderes Exemplar der gleichen Hardware zu prüfen.

Gruß