Communication FPGA Visual Studio Violation d'accès (BulkInPipe)

Version imprimable

Bonjour à tous,

J'essaye de communiquer avec mon FPGA, Driver : CyUSB driver - FPGA board PID=8613 - KNJN LLC

à travers un programme en C++, sous Visual Studio :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
#include "stdafx.h"
#include <windows.h>
#include <conio.h>
#include <cmath>
#include <fstream> 
#include <iostream> 
#include <stdio.h>
#include <ctime>
#include <cstring>
 
using namespace std;
 
#include "CyAPI.h"
 
#pragma comment(lib, "CyAPI.lib")       // this links CyAPI.lib statically to the project
#pragma comment(lib, "ws2_32.lib")
 
static GUID GUID_CYUSB_CYPRESS_FX2 = {0xAE18AA60, 0x7F6A, 0x11D4, 0x97, 0xDD, 0x00, 0x01, 0x02, 0x29, 0xB9, 0x59}; 
static GUID GUID_KNJN_FX2 = {0x0EFA2C93, 0x0C7B, 0x454F, 0x94, 0x03, 0xD6, 0x38, 0xF6, 0xC3, 0x7E, 0x65};
 
#define BulkOutPipe0 USBDevice->EndPoints[1]
#define BulkInPipe1  USBDevice->EndPoints[2]
#define BulkOutPipe2 USBDevice->EndPoints[3]
#define BulkOutPipe3 USBDevice->EndPoints[4]
#define BulkInPipe4  USBDevice->EndPoints[5]
#define BulkInPipe5  USBDevice->EndPoints[6]
 
///////////////////////////////////////////////////
 
void main()
{
 
	unsigned char buf[512000];
 
	unsigned int i=0;
	unsigned int b=0;
	unsigned long int j=0;
	unsigned int compt=0;
 
	string const nomFic(  "C:\Users\E2S\Desktop\Oscilloscope\Oscilloscope.csv");
	ofstream nflux(nomFic.c_str());
	CCyUSBDevice *USBDevice = new CCyUSBDevice(NULL, GUID_KNJN_FX2);
 
	if(!nflux) cout<< "erreur ouverture du fichier"<<endl;
 
	else {
		LONG len= 512000;
		BulkInPipe4->XferData((PUCHAR)buf, len);
		for(int c=0; c<512000 ;c++) nflux << (unsigned int)buf[c]<< endl;	
	}	
 
	delete USBDevice;
	printf("done - press a key to terminate");
	_getch();
}

Seulement voilà, j'ai une erreur de ce type à chaque fois que je lance le programme :

Exception de première chance à 0x0008815c dans CyUSB_test.exe*: 0xC0000005: Violation d'accès lors de la lecture de l'emplacement 0x00000000.

=> Cette ligne pose problème : BulkInPipe4->XferData((PUCHAR)buf, len);

Quelqu'un a une idée... ?

Merci.

22/10/2014, 14h10
therwald

ben ça ressemble à s'y méprendre à un déréférencement de pointeur null
question subsidiaire: comment USBDevice->EndPoints[5] (je décode le define) est-il censé être initalisé?
22/10/2014, 14h11
Bousk

Salut,

le message est plutôt simple et clair : Violation d'accès lors de la lecture de l'emplacement 0x00000000.tu as un pointeur NULL (0x0), vue la ligne que tu invoques, il s'agit sûrement de BulkInPipe4
22/10/2014, 14h14
therwald

En fait, vu le define, et le new qui initialise en théorie USBDevice à la ligne 42 (mais quelle est la question ? :ptdr: ) je pencherais plutôt pour que ce soit USBDevice->EndPoints[5] le pointeur nul...

Citation:

Envoyé par therwald

ben ça ressemble à s'y méprendre à un déréférencement de pointeur null
question subsidiaire: comment USBDevice->EndPoints[5] (je décode le define) est-il censé être initalisé?

Dans ces deux lignes là :
Code:

1 2 3 static GUID GUID_CYUSB_CYPRESS_FX2 = {0xAE18AA60, 0x7F6A, 0x11D4, 0x97, 0xDD, 0x00, 0x01, 0x02, 0x29, 0xB9, 0x59}; static GUID GUID_KNJN_FX2 = {0x0EFA2C93, 0x0C7B, 0x454F, 0x94, 0x03, 0xD6, 0x38, 0xF6, 0xC3, 0x7E, 0x65};

22/10/2014, 14h41
aida_e2s

Citation:

Envoyé par therwald

En fait, vu le define, et le new qui initialise en théorie USBDevice à la ligne 42 (mais quelle est la question ? :ptdr: ) je pencherais plutôt pour que ce soit USBDevice->EndPoints[5] le pointeur nul...

Le C++ n'est pas tout à fait mon domaine de prédilection, vous avez une idée sur comment initialiser l'USBDevice ?

Je pensais que cette ligne suffisait :

Code:

CCyUSBDevice *USBDevice = new CCyUSBDevice(NULL, GUID_KNJN_FX2);
22/10/2014, 14h45
bacelar

Pourquoi un new ??

C'est quoi le NULL passé en premier paramètre du constructeur ?
22/10/2014, 14h49
therwald

A vrai dire ce n'est pas un problème de C++ à proprement parler.
Il faut consulter la documentation du driver et voir ce qui doit être fait pour l'initialiser. Qu'est-ce qui te fait choisir BulkInPipe4 plutôt que BulkInPipe1?
Peut-être disposes-tu de fonctions pour vérifier le statut des différents services, de fonctions pour les activer, etc...

Citation:

Envoyé par bacelar

Pourquoi un new ??

C'est quoi le NULL passé en premier paramètre du constructeur ?

Je n'ai fait que reprendre le code du fabricant...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
// FX2 FlashyDemo example
// (c) fpga4fun.com KNJN LLC - 2008, 2009
 
// This works in conjunction with a FlashyDemo FPGA bitfile
 
// This example uses the CyUSB driver
// Tested with MS Visual C++ 6.0
 
///////////////////////////////////////////////////
#include <windows.h>
#include <stdio.h>
#include <assert.h>
 
#include "CyAPI.h"
#pragma comment(lib, "CyAPI.lib")       // this links CyAPI.lib statically to the project
 
// GUID {0EFA2C93-0C7B-454F-9403-D638F6C37E65}
static GUID GUID_KNJN_FX2 = {0x0EFA2C93, 0x0C7B, 0x454F, 0x94, 0x03, 0xD6, 0x38, 0xF6, 0xC3, 0x7E, 0x65};
 
#define BulkOutPipe0 USBDevice->EndPoints[1]
#define BulkInPipe1  USBDevice->EndPoints[2]
#define BulkOutPipe2 USBDevice->EndPoints[3]
#define BulkOutPipe3 USBDevice->EndPoints[4]
#define BulkInPipe4  USBDevice->EndPoints[5]
#define BulkInPipe5  USBDevice->EndPoints[6]
 
///////////////////////////////////////////////////
#define nFlashyChannels 4	// 4 for Saxo-Q, 2 for the other FX2 boards
#define AcqDataLen	1024
#define DataPacketVersion	2
 
void main()
{
	int i, ch;
 
	struct
	{
		WORD PktAdr;
		BYTE DAC[8];
		BYTE TriggerThreshold;
		BYTE PreTriggerPoint;
		BYTE FilterDataIn_HDiv;
		BYTE AcqAllowed_TriggerSlope;
	}
	TriggerRequest;
 
	struct DPH
	{
		WORD magic_number;	// 0x55AA
		BYTE version;		// 0x01
		BYTE nb_channels_and_ADCfreq;
	};
 
	struct
	{
		struct DPH hdr1;					// header
		BYTE samples[AcqDataLen*nFlashyChannels];	// data acquired from Flashy
		DWORD dummy[4];						// don't care data
		DWORD FC[3];						// frequency counters
		struct DPH hdr2;					// second header
	}
	DataPacket;
 
	// make sure the structures are packed
	assert(sizeof(TriggerRequest)==14);
	assert(sizeof(DataPacket)==AcqDataLen*nFlashyChannels+36);
 
	TriggerRequest.PktAdr = 0x0000;
	TriggerRequest.DAC[0] = 0xFF;	// max range and position
	TriggerRequest.DAC[1] = 0xFF;
	TriggerRequest.DAC[2] = 0xFF;
	TriggerRequest.DAC[3] = 0xFF;
	TriggerRequest.DAC[4] = 0xFF;
	TriggerRequest.DAC[5] = 0xFF;
	TriggerRequest.DAC[6] = 0xFF;
	TriggerRequest.DAC[7] = 0xFF;
	TriggerRequest.TriggerThreshold = 0;	// trigger now
	TriggerRequest.PreTriggerPoint = 128;	// half the data before the trigger, half after
	TriggerRequest.FilterDataIn_HDiv = 0;	// acquire at full speed
	TriggerRequest.AcqAllowed_TriggerSlope = 0x80;
 
	CCyUSBDevice *USBDevice = new CCyUSBDevice(NULL, GUID_KNJN_FX2);
 
	LONG len = sizeof(TriggerRequest);
	BulkOutPipe2->XferData((PUCHAR)&TriggerRequest, len);	// send the trigger request
 
	len = sizeof(DataPacket);
	BulkInPipe4->XferData((PUCHAR)&DataPacket, len);	// and get the data packet back
 
	if(DataPacket.hdr1.magic_number==0x55AA && DataPacket.hdr1.version==DataPacketVersion)
	{
		if((DataPacket.hdr1.nb_channels_and_ADCfreq & 0x0F)==nFlashyChannels)
		{
			if(DataPacket.hdr2.magic_number==0x55AA && DataPacket.hdr2.version==DataPacketVersion)
			{
				// display the data received
				for(ch=0; ch<nFlashyChannels; ch++)
				{
					printf("Channel %d: ", ch+1);
					for(i=0; i<AcqDataLen; i++) printf("%d ", DataPacket.samples[i+AcqDataLen*ch]);
					printf("\n");
				}
			}
		}
		else
			printf("Wrong number of Flashy channels (%d received, %d expected)\n", (DataPacket.hdr1.nb_channels_and_ADCfreq & 0x0F), nFlashyChannels);
	}
	else
		printf("Bad packet received\n");
 
	// now we could re-trigger to get more data if we wanted
	// but let's just exit
	delete USBDevice;
}

22/10/2014, 15h01
aida_e2s

Citation:

Envoyé par therwald

A vrai dire ce n'est pas un problème de C++ à proprement parler.
Il faut consulter la documentation du driver et voir ce qui doit être fait pour l'initialiser. Qu'est-ce qui te fait choisir BulkInPipe4 plutôt que BulkInPipe1?
Peut-être disposes-tu de fonctions pour vérifier le statut des différents services, de fonctions pour les activer, etc...

C'est celui qui correspond à la sortie du FPGA, j'essaye de lire des valeurs qu'il m'envoie.

Je n'ai que ça : http://www.knjn.com/docs/KNJN%20FX2%20ARM%20boards.pdf
22/10/2014, 15h33
therwald

Code:

unsigned char buf[512000];

Ça m'avait échappé, mais tu tentes de réserver un tableau de 512k sur la pile. Pas sûr que ça passe, ça... (sur Visual Studio ça doit représenter une bonne partie de la taille de la pile...)
Faudrait peut-être le réserver sur le tas, donc par allocation dynamique (new...)
A tester avant toutes choses si tu as du mal à trouver une sérieuse de l'API du driver.
22/10/2014, 15h44
aida_e2s

1 pièce(s) jointe(s)

Citation:

Envoyé par therwald

Code:

unsigned char buf[512000];

Ça m'avait échappé, mais tu tentes de réserver un tableau de 500*sizeof(char)k sur la pile. Pas sûr que ça passe, ça... (sur Visual Studio ça doit représenter une bonne partie de la taille de la pile...)
Faudrait peut-être le réserver sur le tas, donc par allocation dynamique (new...)
A tester avant toutes choses si tu as du mal à trouver une sérieuse de l'API du driver.

J'ai essayé avec 32, mais rien n'y fait...

Pièce jointe 159448
22/10/2014, 15h46
therwald

Après test de ma part, rapidement, la réservation du tableau passe s'il n'y a rien d'autre sur la pile.
(si tu tentes avec un deuxième elle déborde, ceci-dit...)
22/10/2014, 15h51
therwald
On s'est croisés :aie:
De toutes façons, même si effectivement tu mets un gros coup à la pile de cette façon, ça ne peut pas être l'origine du problème.
On en revient à la valeur du pointeur USBDevice->EndPoints[5]...
Il doit y avoir quelque chose à faire pour initialiser la table des endpoints...ça n'aurait pas un rapport avec:
Code:

1 2 LONG len = sizeof(TriggerRequest); BulkOutPipe2->XferData((PUCHAR)&TriggerRequest, len); // send the trigger request
Par hasard? Je remarque que tu ne le fais pas dans le code que tu montres.
Je ne connais strictement rien au maniement de ce type de cartes, mais elle n'enverra peut-être rien tant que tu ne le lui demandes pas...par une requête?
22/10/2014, 16h06
aida_e2s
Citation:
Envoyé par therwald

On s'est croisés :aie:
De toutes façons, même si effectivement tu mets un gros coup à la pile de cette façon, ça ne peut pas être l'origine du problème.
On en revient à la valeur du pointeur USBDevice->EndPoints[5]...
Il doit y avoir quelque chose à faire pour initialiser la table des endpoints...ça n'aurait pas un rapport avec:

Code:

1 2 LONG len = sizeof(TriggerRequest); BulkOutPipe2->XferData((PUCHAR)&TriggerRequest, len); // send the trigger request

Par hasard? Je remarque que tu ne le fais pas dans le code que tu montres.
Je ne connais strictement rien au maniement de ce type de cartes, mais elle n'enverra peut-être rien tant que tu ne le lui demandes pas...par une requête?
:)

J'ai essayé de lancer l'application type du constructeur mais j'ai eu le même problème...

En revanche, après avoir changé l'argument 2 dans :

Code:

CCyUSBDevice *USBDevice = new CCyUSBDevice(NULL, GUID_CYUSB_CYPRESS_FX2);

J'obtiens :

Exception de première chance à 0x002411a7 dans CyUSB_test.exe*: 0xC0000005: Violation d'accès lors de la lecture de l'emplacement 0x00000014.
22/10/2014, 16h14
therwald

Leur code d'exemple ne marche pas? Il n'y a pas de support pour ce truc?
Je parlais de la doc du driver USB, pas de la carte. Ça se résume à leur exemple de code?
22/10/2014, 16h18
aida_e2s

Citation:

Envoyé par therwald

Leur code d'exemple ne marche pas? Il n'y a pas de support pour ce truc?
Je parlais de la doc du driver USB, pas de la carte. Ça se résume à leur exemple de code?

Oui il n'y a que l'exemple que j'ai posté et ça : http://www.knjn.com/docs/KNJN%20FX2%20ARM%20boards.pdf
22/10/2014, 17h16
aida_e2s

ça fonctionne !

J'ai changé Projet -> Propriétés -> Propriétés de configuration -> C/C++ -> Génération du code -> Bibliothèque Runtime, Choisir DLL de débogage multithread (/MDd)

Merci de votre aide !
22/10/2014, 17h20
therwald

arf! problème d'incohérence entre formats binaires... euh ça s'invente pas ce genre de choix, ils ne donnent pas l'info eux-même chez le fabricant?
22/10/2014, 17h24
aida_e2s

Citation:

Envoyé par therwald

arf! problème d'incohérence entre formats binaires... euh ça s'invente pas ce genre de choix, ils ne donnent pas l'info eux-même chez le fabricant?

En fait il s'agissait d'un problème d'OS, de windows 8 à windows 7 il fallait changer ce paramètre.
24/10/2014, 13h50
bacelar

ATTENTION.
La "solution" que tu donnes n'a rien à voir avec le support d'un OS X ou Y.
C'est juste pour la version Debug de la C-Runtime.
Oui, il est préférable d'utiliser la version Debug de la C-Runtime dans la configuration Debug d'un projet mais JAMAIS dans une configuration Release.
La C-Runtime Debug n'est pas redistribuable, elle n'est utilisable que sur les machines ou Visual Studio est installé.
24/10/2014, 14h09
therwald

Citation:

Envoyé par bacelar

ATTENTION.
La "solution" que tu donnes n'a rien à voir avec le support d'un OS X ou Y.
C'est juste pour la version Debug de la C-Runtime.
Oui, il est préférable d'utiliser la version Debug de la C-Runtime dans la configuration Debug d'un projet mais JAMAIS dans une configuration Release.
La C-Runtime Debug n'est pas redistribuable, elle n'est utilisable que sur les machines ou Visual Studio est installé.

Ce qui veut dire que aida_e2s devra prendre soin de choisir de linker avec le runtime approprié par l'option /MD pour distribuer (si toutefois elle distribue, dans la mesure où nous ne connaissons pas son contexte nous ne pouvons pas le savoir mieux qu'elle). Je soupçonne que le lien avec l'OS est indirect, peut-être que les binaires propriétaires qu'elle utilise pour piloter son device ne sont pas linkés avec les mêmes options sous W7 et W8...