Issues with isoc.FinishDataXfer(ref cBufs[k], ref xBufs[k], ref len, ref oLaps[k], ref pktsInfo[k]))

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
maVa_1182686
Level 3
Level 3
Welcome!

Hi,

I had a spartan 7 fpga dumping data into the FX3 and was reading the data with a modified version of STREAMER C#.

The protocol was BULKtransfer. I was seeing some dataloss on some computers so I needed to move Isochronous protocol.

In bulk i was using 64*1024byte DMA buffers.

In bulktransfer the data that gets put into xBufs is always exactly the amount of data I suspect =>

The amount of Packets per Xfer*1024.

For my current application that was 19 packets of 1024. Worked like a charm

Just go USB_data_frame = xBufs

Now that I've changed the FX3 code to ISOCHRONOUS this is not longer true.

I had to increase the DMA buffer size as isochronous is really slow with small buffers.

Currently I still need to send dataframes of 19kB but I have to send at least 8 packets per Xfer (isochronous demands this) but i also had to increase the buffersize to 4KB instead of 1024.

Therefore, I'm sending at least 32KB every Xfer.

This is not a problem. I can deal with this on another level.

I do notice however that the packets that are coming in through

isoc.FinishDataXfer(ref cBufs, ref xBufs, ref len, ref oLaps, ref pktsInfo))

aren NOT 32 KB anymore.

They're alternating between 8KB and 12KB which makes me think it's sending either 2 or 3 bursts of the 4KB dma buffers.

To makes things worse, it seems that the data is skipping randomly.

Does that have anything to do with the "overlaps"?

USB_data_frame = xBufs  does not work for sure

I only have been programming C# since last week so I'm quite in over my head.

Can anybody point me in the right direction as far as the inner workings of isoc.FinishDataXfer goes.

The manual is sooo incredibly short and explains nothing.

Thank You!!!!!!!!!!!!!!!!!!!!!

0 Likes
1 Solution
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Mattijs,

Please program the firmware that I have given you yesterday ( with which the issue is reproduced - I hope Thread(1000) is not changed when the issue is seen)

Then run the attached streamer application which creates FinishData.bin in the same directory where the application is.

-> Choose IN Endpoint; Choose 8 as PPX and 1 in Queue.

Note:

1. Every time you run this application, if FinishData.bin file exists it deletes and creates new. (Letting you know in case you have some other file with same name)

2. open the FinishData.bin file after closing Streamer.

Please test and let me know if the pattern obtained in the file is correct.

Regards,

Hemanth

Hemanth

View solution in original post

0 Likes
47 Replies

I can now reproduce my issue with your Firmware!

This is my debug read out.

I basically print the ENTIRE xbuf every time just to try to see the pattern. (The first element of every 1024 bytes of the entire buffer...not the entire buffer obviously)

It is printed to console every time you go through the finishXfer loop.

I set Xfers to queue to 1 just so k is always 0  (xBuf[k]), I print k too but that is not useful right now.

It all boils down to me not knowing where to take the data from the xBuf as it seems to be put there at a random location.

I can't see the pattern.

BOLD indicates actual debug, comments are not bold

The *** starts indicate the position in the xBuf where I would think the new data should be

The /// indicates a position in the xBuf that to my understanding is not written to because length pkts < length xBuf

In the first debug information the data at the start of a 1024 boundary goes from 52 => 63

It gets placed in position 1=>12 in the xbuf. This seems logical to me

CONSOLE :

length xBuf=  32768

length pkts=  12288

k= 0

test:

***  52    <= seems OK

***  53

***  54

***  55

***  56

***  57

***  58

***  59

***  60

***  61

***  62

***  63

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

*************************

length xBuf=  32768

length pkts=  8192

k= 0

test:

***  64   <= OK TOO.. payload is sequential...last xFer 52=>63, this starts at 64 and goes to 71 in 88 steps (length pkts=  8192)

***  65

***  66

***  67

***  68

***  69

***  70

***  71

///  60

///  61

///  62

///  63

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

///  165

*************************

length xBuf=  32768

length pkts=  12288

k= 0

test:

***  64

***  65

***  66

***  67

***  68

***  69

***  70

***  71

***  60

***  61

***  62

***  63

///  165

///  165

///  165

///  165

///  72      <=== FIRST PROBLEM!!!!!!   The payload goes from 71 to 83...BUT WHY on this location in xBUF?? How should I know where to take data in the future???

///  73

///  74

///  75

///  76

///  77

///  78

///  79

///  80

///  81

///  82

///  83

///  165

///  165

///  165

///  165

*************************

length xBuf=  32768

length pkts=  4096

k= 0

test:

***  84          <= Here the payload continues at 84 => 87...but in the start position again???

***  85

***  86

***  87

///  68

///  69

///  70

///  71

///  60

///  61

///  62

///  63

///  165

///  165

///  165

///  165

///  72

///  73

///  74

///  75

///  76

///  77

///  78

///  79

///  80

///  81

///  82

///  83

///  165

///  165

///  165

///  165

*************************

length xBuf=  32768

length pkts=  8192

k= 0

test:

***  88

***  89

***  90

***  91

***  92

***  93

***  94

***  95

///  60

///  61

///  62

///  63

///  165

///  165

///  165

///  165

///  72

///  73

///  74

///  75

///  76

///  77

///  78

///  79

///  80

///  81

///  82

///  83

///  165

///  165

///  165

///  165

*************************

length xBuf=  32768

length pkts=  12288

k= 0

test:

***  88

***  89

***  90

***  91

***  92

***  93

***  94

***  95

***  60

***  61

***  62

***  63

///  165

///  165

///  165

///  165

///  72

///  73

///  74

///  75

///  96

///  97

///  98

///  99

///  100

///  101

///  102

///  103

///  104

///  105

///  106

///  107

*************************

length xBuf=  32768

length pkts=  4096

k= 0

test:

***  108

***  109

***  110

***  111

///  92

///  93

///  94

///  95

///  60

///  61

///  62

///  63

///  165

///  165

///  165

///  165

///  72

///  73

///  74

///  75

///  96

///  97

///  98

///  99

///  100

///  101

///  102

///  103

///  104

///  105

///  106

///  107

*************************

The thread 0x2cdc has exited with code 0 (0x0).

0 Likes

It gets even crazier...when I speed up your code by only doing sleep (1) there are "holes" in the positions where new data is put.

I changed my streamer just slightly and now I always delete the content of the xBuf so it's clearer where the new data is being put.

length xBuf=  32768

length pkts=  12288

k= 0

test:

***  208

***  209

***  210

***  211

***  0

***  0

***  0

***  0

***  0

***  0

***  0

***  0

///  0

///  0

///  0

///  0

///  212

///  213

///  214

///  215

///  216

///  217

///  218

///  219

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

*************************

length xBuf=  32768

length pkts=  16384

k= 0

test:

***  220

***  221

***  222

***  223

***  224

***  225

***  226

***  227

***  228

***  229

***  230

***  231

***  232

***  233

***  234

***  235

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

*************************

length xBuf=  32768

length pkts=  20480

k= 0

test:

***  236

***  237

***  238

***  239

***  240

***  241

***  242

***  243

***  0

***  0

***  0

***  0

***  244

***  245

***  246

***  247

***  248

***  249

***  250

***  251

///  252

///  253

///  254

///  255

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

*************************

length xBuf=  32768

length pkts=  12288

k= 0

test:

***  0

***  1

***  2

***  3

***  0

***  0

***  0

***  0

***  0

***  0

***  0

***  0

///  4

///  5

///  6

///  7

///  8

///  9

///  10

///  11

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

*************************

length xBuf=  32768

length pkts=  16384

k= 0

test:

***  12

***  13

***  14

***  15

***  16

***  17

***  18

***  19

***  20

***  21

***  22

***  23

***  24

***  25

***  26

***  27

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

*************************

length xBuf=  32768

length pkts=  20480

k= 0

test:

***  28

***  29

***  30

***  31

***  32

***  33

***  34

***  35

***  36

***  37

***  38

***  39

***  40

***  41

***  42

***  43

***  44

***  45

***  46

***  47

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

*************************

length xBuf=  32768

length pkts=  12288

k= 0

test:

***  48

***  49

***  50

***  51

***  0

***  0

***  0

***  0

***  52

***  53

***  54

***  55

///  56

///  57

///  58

///  59

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

///  0

*************************

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Mattijs,

Please program the firmware that I have given you yesterday ( with which the issue is reproduced - I hope Thread(1000) is not changed when the issue is seen)

Then run the attached streamer application which creates FinishData.bin in the same directory where the application is.

-> Choose IN Endpoint; Choose 8 as PPX and 1 in Queue.

Note:

1. Every time you run this application, if FinishData.bin file exists it deletes and creates new. (Letting you know in case you have some other file with same name)

2. open the FinishData.bin file after closing Streamer.

Please test and let me know if the pattern obtained in the file is correct.

Regards,

Hemanth

Hemanth
0 Likes

It looks right. But what am I doing wrong then?

How do you know where in the xBuf the data is?

I really don't get it...

0 Likes

I'll try to go into more detail tonight and I'll try to find the differences in your streamer code and mine

0 Likes

OK...I understand now! Thanks!

if (pkts.Length > 0)    <<<<<<<<<CRUCIAL!

                                {

                                    //file.Write(xBufs, (EndPoint.MaxPktSize) * j, 1);

                                    //file.Write(xBufs, ((EndPoint.MaxPktSize) * j) + 1024, 1);

                                    //file.Write(xBufs, ((EndPoint.MaxPktSize) * j) + 2048, 1);

                                    //file.Write(xBufs, ((EndPoint.MaxPktSize) * j) + 3072, 1);

                                    Console.WriteLine(xBufs[(EndPoint.MaxPktSize) * j + 0 * 1024].ToString());

                                    Console.WriteLine(xBufs[(EndPoint.MaxPktSize) * j + 1 * 1024].ToString());

                                    Console.WriteLine(xBufs[(EndPoint.MaxPktSize) * j + 2 * 1024].ToString());

                                    Console.WriteLine(xBufs[(EndPoint.MaxPktSize) * j + 3 * 1024].ToString());

                                    /*if (file_buffer[0] > 0)

                                    {

                                        file.WriteByte(0xCC);

                                        file.WriteByte(file_buffer[0]);

                                        file_buffer[0] = 0;

                                    }*/

                                }

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Mattijis,

Please test with the attached firmware and let me know if you can see the issue. Also analyze the time difference between 4K packets.

Regards,

Hemanth

Hemanth
0 Likes
maVa_1182686
Level 3
Level 3
Welcome!

Hi,

I have tried all sorts of combinations.

4,8,16 bursts and 1 to 3 packets per uFrame.

It all seems to be fine at the FPGA side. Flow control works as it should.I have one thread with an auto DMA channel so my FLAG(b) goes high for a brief moment indicating that the SLAVE is not ready every DMA buffer size amount of transfers.

The FlagB I have assigned does also reflect the DMA buffers size increases or decreases according to DMA size = 1024*burst*packs (per uframe).

A colleague, unlike me a good programmer ,  has a program he wrote in C++ (as opposed to my C# code) and it appears that the data is not like it should be in his program too. I therefore do not think that I did something wrong with finishDataXfer()

Basically we now assume that something is wrong in the FX3 firmware or GPIFII statemachine hardware and that the problems start when the buffersize is a multiple of 1024.

The firmware works as it should in BULK with 1024byte sized dma buffers. We changed that piece of firmware from BULK to ISO.

The problems came when we needed to increase the buffersizes from 1024 to a multiple of this.

We can't find the reason for this. It seems the GPIFII is not aware of how big buffers are. Increasing them from within the firmware is also reflected in the way flag B acts. It seems logical to me that that means that the GPIFII "knows enough" to handle the full and empty buffers at other side (where the USB portion takes data from those buffers)

We are pretty much stuck now.

0 Likes