Library PmacDownloadA function flakiness

We have a utility we wrote to download code upgrades to our customers so they do not have to get involved with the intricacies of PEWin and multiple commands/downloads. They just click a button.

It uses uses the old PMACServer DLL library communications method. We build it in Borland C++ Builder 3. I know these are old.

Now we are in the situation where an important customer found it didn't work on their PC and are now broadcasting our system is poor.

We narrowed down the differences in the program on their system between working and not working to one section. Basically in simplified pseudocode we have:

Initialisation Code

FPMAC->GetResponse("m800", &Response, &Error)

Check response is good

FPMAC->GetResponse("ver", &Response, &Error) !!!!!

Check response is good

FPMAC->GetResponse("$$$", &Response, &Error)

Sleep 2s

FPMAC->GetResponse("p7001..7109", &Response, &Error)

Store response

FPMAC->GetResponse("$$$***", &Response, &Error)

Sleep 2s

FPMAC->GetResponse("PASSWORD=xxxxxxxx", &Response, &Error)

FPMAC->GetResponse("i5=0", &Response, &Error)

Sleep 1s

FPMAC->DownloadFile(MsgProc, ProgProc, "#XXOMNI.PMC", True, True)

etc

On particular PCs (these happen to be Intel Atom PCs) the program fails if the line marked !!!!! is not included.

The failure symptom is that based on the output from the message callback and log file, the file is compiled ok but when download occurs we get 'Downloaded 0 lines'. Then no warnings no errors. The PMA file is zero bytes.

Put the ver command back in and all is fine again.

We cannot see how that line and the position it is in could affect anything unless it is clearing a buffer or something. We have lost all confidence in using this library. Can anyone explain this?

Also do you have any examples which actually use the DLL PmacDownloadA function we can see in case we are not doing something quite right?

Thanks

Dave

Dave,

I need more info regarding your problem, for example:

1. Version of PMAC Communication Library (Pro1, or Pro2) with exact version number?

2. Mode of communication (Serial, Ethernet, USB, PCI or ISA)?

3. The function in question is a legacy one and has been replaced by the new function GetResponseEx(). GetResponseEx() has slightly different specs. than the old function. Please the Library document for correct prototype.

4. The updated function for Downloading a file or files is PMACDownload() or Download(), again based on the library revision and is explained in the document accordingly.

We have a utility we wrote to download code upgrades to our customers so they do not have to get involved with the intricacies of PEWin and multiple commands/downloads. They just click a button.

 

It uses uses the old PMACServer DLL library communications method. We build it in Borland C++ Builder 3. I know these are old.

 

Now we are in the situation where an important customer found it didn't work on their PC and are now broadcasting our system is poor.

 

We narrowed down the differences in the program on their system between working and not working to one section. Basically in simplified pseudocode we have:

 

Initialisation Code

FPMAC->GetResponse("m800", &Response, &Error)

Check response is good

FPMAC->GetResponse("ver", &Response, &Error) !!!!!

Check response is good

FPMAC->GetResponse("$$$", &Response, &Error)

Sleep 2s

FPMAC->GetResponse("p7001..7109", &Response, &Error)

Store response

FPMAC->GetResponse("$$$***", &Response, &Error)

Sleep 2s

FPMAC->GetResponse("PASSWORD=xxxxxxxx", &Response, &Error)

FPMAC->GetResponse("i5=0", &Response, &Error)

Sleep 1s

FPMAC->DownloadFile(MsgProc, ProgProc, "#XXOMNI.PMC", True, True)

etc

 

On particular PCs (these happen to be Intel Atom PCs) the program fails if the line marked !!!!! is not included.

 

The failure symptom is that based on the output from the message callback and log file, the file is compiled ok but when download occurs we get 'Downloaded 0 lines'. Then no warnings no errors. The PMA file is zero bytes.

 

Put the ver command back in and all is fine again.

 

We cannot see how that line and the position it is in could affect anything unless it is clearing a buffer or something. We have lost all confidence in using this library. Can anyone explain this?

 

Also do you have any examples which actually use the DLL PmacDownloadA function we can see in case we are not doing something quite right?

 

Thanks

Dave

Hi, thanks, here is more info

1. Version of PMAC Communication Library (Pro1, or Pro2) with exact version number?

Pro1:

PComm32.dll

10.48.0.0

Pmacusb.sys

File: 4.2.4.1 Product: 4.0.0.0

PmacServer.exe

1.0.1.745

2. Mode of communication (Serial, Ethernet, USB, PCI or ISA)?

USB

3. The function in question is a legacy one and has been replaced by the new function GetResponseEx(). GetResponseEx() has slightly different specs. than the old function. Please the Library document for correct prototype.

That function is Pro2 and we are currently interested in an explanation of the problem found using Pro1 drivers. When we 'attach' to the PmacGetResponseA function in the DLL we use the following prototype and code

typedef long (CALLBACK* GETRESPONSEMETHOD)(DWORD Device, PCHAR Response,
 UINT MaxChar, PCHAR Command);

 FGetResponse = (GETRESPONSEMETHOD)GetProcAddress(hPMACLib, "PmacGetResponseA");

4. The updated function for Downloading a file or files is PMACDownload() or Download(), again based on the library revision and is explained in the document accordingly.

I have not seen PMACDownload() but Download() is also Pro2. We attach to PmacDownloadA using the following prototypes and code:

typedef long (FAR WINAPI *DOWNLOADGETPROC)(long nIndex, LPTSTR lpszBuffer, long nMaxLength);
typedef void (FAR WINAPI *DOWNLOADPROGRESS)(long nPercent);
typedef void (FAR WINAPI *DOWNLOADMSGPROC)(LPTSTR str, BOOL newLine);

typedef long (CALLBACK* DOWNLOADMETHOD)(DWORD Device, DOWNLOADMSGPROC msgp,
 DOWNLOADGETPROC getp, DOWNLOADPROGRESS prgp, PCHAR FileName, BOOL Macro,
 BOOL Map, BOOL Log, BOOL Download);

 FDownload = (DOWNLOADMETHOD)GetProcAddress(hPMACLib, "PmacDownloadA");

As described these work most of the time. But we now have a type of PC which repeatedly fails with the originally highlighted line of code removed and repeatedly works with the line in.

Previous attempts at coding a downloader in Delphi, C++Builder, and also VC++ using the Pro2 interface have always been unsuccessful (we use all the other API functions easily). That is why I requested some example projects using the download functionality (Pro1 or Pro2).

I guess we will revisit the Pro2 drivers as maybe we understand more now than we did then. However some explanation of the original phenomenon would be appreciated to rebuild confidence... and our customer wants some reassurance.

Thanks

Dave