Pointer Problem dll JTAG Macraigor Systems

[Dawid]

Hello,

 

I write here a topic, because I'm looking for a help since I can not deal with some issue for a long time. I'm trying to write LabView program which will program uC flash using JTAG usbWiggler manufactured by Macraigor Systems. The manufacturer provides customers with program to do whole staff connected with programming, but it's stand alone app and I would like to build the programming process into the test sequence performed by LabView (program + test). Additionally the manufacturer provides a library to call various functions related to programming, erasing etc. I tried to write a program to use dll but no success. There is some small cmd exe program which is using the dll (also created by the supplier), and its working, but there are some bugs in it, and I cannot change it or make some error handling so that's why I decided to use dll alone. I attached dll, dll readme file, ocd file (configuration file for uC), and VIs.

I checked the first command called: "FlashSetupAndConnect" it's working without hardware, so you are able to test something. (checked with cmd exe program, without device it always pass if input data is ok, it fails when something is missing like bad path file etc.) Status from each function should be "1", and I get "0" all the time.

 

The function should looks like this (copied from readme file):

int FlashProgrammer_SetupAndConnect(char *ocd_filename, char *device_name, char *device_address, unsigned long baud_rate,
unsigned long jtag_speed);

 

I will be very grateful for any answer and advices.

Dawid K.

readme.rtf

OCDandDLLl.zip

Edited October 10, 2014 by Dawid

[Rolf Kalbermatter]

Hello,

 

I write here a topic, because I'm looking for a help since I can not deal with some issue for a long time. I'm trying to write LabView program which will program uC flash using JTAG usbWiggler manufactured by Macraigor Systems. The manufacturer provides customers with program to do whole staff connected with programming, but it's stand alone app and I would like to build the programming process into the test sequence performed by LabView (program + test). Additionally the manufacturer provides a library to call various functions related to programming, erasing etc. I tried to write a program to use dll but no success. There is some small cmd exe program which is using the dll (also created by the supplier), and its working, but there are some bugs in it, and I cannot change it or make some error handling so that's why I decided to use dll alone. I attached dll, dll readme file, ocd file (configuration file for uC), and VIs.

I checked the first command called: "FlashSetupAndConnect" it's working without hardware, so you are able to test something. (checked with cmd exe program, without device it always pass if input data is ok, it fails when something is missing like bad path file etc.) Status from each function should be "1", and I get "0" all the time.

 

The function should looks like this (copied from readme file):

int FlashProgrammer_SetupAndConnect(char *ocd_filename, char *device_name, char *device_address, unsigned long baud_rate,

unsigned long jtag_speed);

 

I will be very grateful for any answer and advices.

Dawid K.

 

There is absolutely no need for all the pointer stuff you are doing. The Call Library Node is very capable of translating LabVIEW strings into C string pointers for the duration of the Call Library Node call. Your own managed pointers would only be necessary if the lifetime of that pointer is required to last beyond the call of the function itself. So get rid of all the pointer acrobatic and just use the code in the true case.

 

The DLL doesn't load on my system since it is compiled using Borland C and probably requires the Borland C Runtime library installed on the computer, which I have no plans to install on my system.

 

However taking a quick look at the assembly would indicate that it might be compiled to use stdcall convention for all its functions. The header files or the MS Visual C example mentioned in the documentation would certainly help to verify what calling convention is supposed to be the right one.

 

Also the return value of those functions is defined to be int, which under all modern Windows versions is a 32 bit integer. Your function thinking it's a int16 certainly might miss some interesting bits that way.

 

 

Look at this declaration in the documentation:

 

 

int FlashErase(int start_sector, int end_sector);

 

 

An int is still a 32 bit integer, and not a 64 bit integer as you have decided to make it here for the parameters (and still use an int16 for the return value)!!!!

 

Last but not least:

 

If you have several files to attach, with some of them being not possible to post because of their ending being rejected it is quite a good idea to pack everything into a ZIP file and post that rather than renaming files to make them appear as something they are not, and having to explain how to do all the renaming back in order to get the right files.

[Dawid]

Thank you for very quick answer!
 

I'm not so experienced programmer like you and I will be thankful If you will say something more what you mean by:

"The DLL doesn't load on my system...."

 

Maybe it doesn't load on my PC too. Anyway I don't know what doesn't mean. I tried to look for "Borland C Runtime library" and I install something but I'm not pretty sure if it's exactly what you said I should have (installed C++ free compiler http://edn.embarcadero.com/article/20633 where it says there is Borland C/C++ Runtime Library included).

I read on forums that LabView handles pointers but since I have a lot of problems, I thought that maybe it is not in my case and I create "false case".

 

Thanks for pointing me mistake with int variable, I will update code at once.

I attached also example how to use dll from JTAG manufacturer, it might help somebody to advice me something.

 

PS: My company is good customer (I think) of TMS Poland, and it's cool somebody from TMS answer first:)

 

Dawid

 

usbWiggler.vi

ExampleMSCPP.zip

Edited October 9, 2014 by Dawid

[Rolf Kalbermatter]

Thank you for very quick answer!

 

I'm not so experienced programmer like you and I will be thankful If you will say something more what you mean by:

"The DLL doesn't load on my system...."

 

Well I got rid of the dynamic path in the diagram and simply pointed the Call Library Node to the DLL on my system and then LabVIEW ends up with broken arrow for the VI claiming it couldn't load the DLL.

 

Well disregard this remark. Typical PEBCAK problem  . Should have noticed that the VI got opened in LabVIEW 64 Bit rather than 32 Bit.

 

I have edited the VI in a way that I should think should work. Seems that LabVIEW feels the functions need to be called as cdecl. Not sure why since the assembly code seems to hint otherwise, but whatever.

 

I now get a return value of 1 for the Disconnect call, which sounds not to bad. 

 

Obviously other than what you believe, the FlashSetupAndConnect() call has to fail on a system with no hardware to connect to!

 

Just adapt the path generation to your conf file in a way that is working for your installation.

usbWiggler.vi

[Dawid]

I remove the dynamic path, but I don't have any error or broken arrow. The VI behave the same like with dynamic path.

[Rolf Kalbermatter]

I remove the dynamic path, but I don't have any error or broken arrow. The VI behave the same like with dynamic path.

 

See above in my edited post. And from the example project you included it seems that cdecl is indeed the right calling convention.

[Dawid]

See above in my edited post. And from the example project you included it seems that cdecl is indeed the right calling convention.

 

 

OK, so you are now at the same point I am. The two first commands returns 0, and disconnect returns 1 (the first command should return 1 even if you don't have hardware - I test that with cmd exe program prepared by supplier).

You can test that too. Download zip attached and run cmd. Go to the unzipped directory in cmd. When you are there write: RunBatchFile test.bat and press enter. You should see that first command SetupandConnect will pass.

 

I forgot to say, you have to edit first line of "test.bat", and put your localization to conf.ocd, for example I have:

"C:\Users\stn_dak\Desktop\FlashAccess\conf.ocd" bolded and underlined text will be different on your PC, depends where you unpacked the zip.

 

FlashAccess.zip

Edited October 9, 2014 by Dawid

[Rolf Kalbermatter]

OK, so you are now at the same point I am. The two first commands returns 0, and disconnect returns 1 (the first command should return 1 even if you don't have hardware - I test that with cmd exe program prepared by supplier).

You can test that too. Download zip attached and run cmd. Go to the unzipped directory in cmd. When you are there write: RunBatchFile test.bat and press enter. You should see that first command SetupandConnect will pass.

 

I forgot to say, you have to edit first line of "test.bat", and put your localization to conf.ocd, for example I have:

"C:\Users\stn_dak\Desktop\FlashAccess\conf.ocd" bolded and underlined text will be different on your PC, depends where you unpacked the zip.

 

Well!!!! If you add a call to FlashErrorText() after each failed function call you will find out that it first reports after the FlashSetupAndConnect():

 

C:\Program Files (x86)\National Instruments\LabVIEW 2013\cpu.ini does not exist.

then after the FlashErase():

Requires Prior Call to FlashSetup()

which is logical since the SetupAndConnect call had failed.

 

So what does this tell us?

 

The flashaccess.dll attempts to find the file cpu.ini in the directory for the current executable.

 

Unless there is a way to tell the DLL in the ocd file to look for this elsewhere, you may be required to put this file in the directory where your LabVIEW.exe file resides (and if you build an executable , also into the directory where your executable will be). Basically it is a bit stupid from the DLL to look for this in the executable directory only and not at least also in the DLL directory itself, but alas such is life.

[Dawid]

It's working! You are awesome man, I'm really appreciate  
I write few e-mails to Macraigor Systems with no response so I am doubly grateful for your help

 

PS: The only one problem is that LabView always crash when I'm trying to close VI which is executing the dll commands.  When I click "x" LabView crashes with unexpected error.

 

Dawid

 

Edited October 10, 2014 by Dawid

[Rolf Kalbermatter]

That means that there is still something wrong. Either one or more Call Library nodes are still configured wrong or there is a bug in the flash dll somewhere. The most likely culprit is a badly configured Call Library Node.

 

Have you made sure that any function which returns information in a string or array buffer is called with a properly allocated buffer? If your buffer is even one byte smaller than what the function is going to try to write into, it will inevitably overwrite some memory that will destroy something. This can often result in a 1097 error if the overwriting is serious enough but also can go unnoticed until you try to close LabVIEW and when trying to clean everything up, it stumbles over the corrupted pointers. Or it can crash somewhere between where the overwriting happens and closing of LabVIEW. And if the overwriting is not affecting pointers it may be in data that your program uses to do calculations elsewhere.

[Dawid]

Ok so "FlashErrorText()" crashes the LabView. The Readme file says:

 

int FlashErrorText(char *pterror_text);

Purpose : Fills a caller supplied buffer with any error text generated by the last Flash command
Parameters:
pterror_text - pointer to a 120 character buffer into which this method will write an ascii error text string

 

I found method to declare 120 or 130 (just to be sure) characters in LabView memory. See picture attached.

Edited October 10, 2014 by Dawid

[Rolf Kalbermatter]

Ok so "FlashErrorText()" crashes the LabView. The Readme file says:

 

 

But I don't know how to declare String with 120 characters in LabView. Should I put manually 120 characters in it and connect to library node input?

Maybe I should connect uint8_t array with 120 elements and change the input parameter from Cstr to Array?

 

Simply use an InitializeArray node with the datatype being U8 and length >=120, then convert it to a String with Byte Array to String.

 

Changing the Call Library Node parameter to be an array of U8 would work too, but you would end up with a string that always contains 120 characters, but only the characters until the first NULL byte are meaningful. If you configure the Call Library Node to be a CStr pointer LabVIEW will take care on return to scan the string for this NULL character and limit the string length to be the correct size.

[Dawid]

Simply use an InitializeArray node with the datatype being U8 and length >=120, then convert it to a String with Byte Array to String.

 

Changing the Call Library Node parameter to be an array of U8 would work too, but you would end up with a string that always contains 120 characters, but only the characters until the first NULL byte are meaningful. If you configure the Call Library Node to be a CStr pointer LabVIEW will take care on return to scan the string for this NULL character and limit the string length to be the correct size.

 

Hehe I just did it, post above with picture  Thanks one more time for help.

 

Problem is solved, Topic can be closed.

 

Edited October 10, 2014 by Dawid