Jump to content
Dawid

Pointer Problem dll JTAG Macraigor Systems

Recommended Posts

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

post-52806-0-06813300-1412837091_thumb.p

post-52806-0-53384500-1412837102.png

post-52806-0-14255800-1412837103.png

OCDandDLLl.zip

Edited by Dawid

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

post-52806-0-48009500-1412844710_thumb.p

usbWiggler.vi

ExampleMSCPP.zip

Edited by Dawid

Share this post


Link to post
Share on other sites

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 :oops: . 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.  :rolleyes:

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Dawid

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

It's working! You are awesome man, I'm really appreciate :worshippy: 
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. :angry: When I click "x" LabView crashes with unexpected error.

 

Dawid

 

post-52806-0-41801300-1412926706.png

Edited by Dawid

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

post-52806-0-64011400-1412939562.png

Edited by Dawid

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Dawid

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By torekp
      DLL functions or shared variables?  Or something else?
      I have a Labview 2014-64 executable (or I can build a DLL) that runs one piece of equipment, the X-ray.  The other engineer has a large CVI Labwindows 2015 + MS Visual Studio 2012 (C++) executable that runs everything else.  I want the Labview code to be a slave of the CVI code, accepting commands to turn X-ray On or Off, reporting failures, and the like.  Translating the X-ray code into C++ would be possible in principle, but not fun.
      Shared variables look easy, but I'm kinda scared of them.  I would define all the shared variables in my LV code, since I'm more familiar with LV, then use them in both.  There's a thread in here called "Shared Variable Woes" so maybe I should be scared.  In the alternative, I tried building a proof-of-concept DLL in Labview, and calling its functions in CVI/C++, and it works, but it's kinda clunky.  (I'm attaching it below in case you want to play, or advise.)
      Your advice would be appreciated.
      XrayDLL.zip
    • By patufet_99
      To use a controller from LabVIEW I have to use some functions of a DLL.
      For one of the functions, according to the header file .h there is a structure data with parameters of different types that I have to pass to the dll. Some of the parameres are BYTE (1 Byte)  and WORD (2 Bytes).
      When compiling this kind of structure with Visual C++ and looking at it's size with "sizeof()" it seems to me that 4 Bytes variables have to start in a position multiple of 4. For example if there is a BYTE and then a DWORD, the 3 Bytes after the BYTE are ignored and the DWORD starts at Bytes 5 to 8.
      When defining a LabVIEW cluster to match the DLL structure, will LabVIEW do the same? If in my cluster there is a U8 variable and then a U32, will anyway the U8 take 4 bytes?
       
      Thank you.
    • By torekp
      So I created a DLL from a Labview VI that has a 2D array input (and some scalar inputs) and some 2D array outputs.  Labview creates a .h file with these lines

      And then it defines the 2D array arguments to my function as being of this type: "void __cdecl Linear_discrim_4dll(DoubleArray *dataObsFeat, int32_t grpAsz," etc etc.  Trouble is, I have no idea how to fill out this structure so that the DLL can use it.  Say for simplicity I had a 2 by 3 input called dataObsFeat with elements {1,2,3; 11,12,13}; how would I create the object with these values in C or C++ and pass it to the function?  I am a total C++ noob, in case it isn't obvious.
    • By Fred chen
      Hi
       
      When I call the DLL, there is a structure:
      struct Signal { uint32 nStartBit; uint32 nLen; double nFactor; double nOffset; double nMin; double nMax; double nValue; uint64 nRawValue; bool is_signed; char unit[11]; char strName[66]; char strComment[201]; };  
       
      There is another  Message structure to the above Signal:
       
      struct Message { uint32 nSignalCount; uint32 nID; uint8 nExtend; uint32 nSize; Signal vSignals[513]; char strName[66]; char strComment[201]; }  
        The point is  Signal vSignals[513];
       
      I've tried to solve it like this,but the program will crash.
       
      How to create struct Message ,any good suggestions?  Thanks a lot.
       

      message.vi
    • By x y z
      Hello!

      I'd like to resize LStrHandle string in a C++ based DLL ... which is perfectly working on desktop Windows (ex.:Win7 32/64 bit) platform by include "extcode.h"  and linking "labviewv.lib", with calling "NumericArrayResize" function.
      BUT I'd like to do the same on Windows Embedded Compact 7.0 with ARM(Cortex-A8).
      When I build the DLL project on "Smart device / WindowsCE" platform it compiled successfully but the linker stopped because "NumericArrayResize" is unresolved symbol ... I think the reason is that the "labviewv.lib" generated for x86 architecture not for ARM.

      So my question is: Is there any libviewv.lib for ARM platform?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.