LabVIEW Embedded

cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to use the Freescale M5329EVB target server

Hi everybody,

I have created a new target on Labview embedded which is based on the Freescale M5329EVB example. The target is a powerpc from Xilinx and it runs a linux on it.

What I want to do is to use the "target server" from the Freescale example. I copied all LEP_plugin VIs of this target example and modified them to work with my target.
According to the porting guide, the target server needs a TCP connection, Telnet server and a TFTP client. I implement all of this on my embedded linux and test them. I can connect through telnet and get files through tftp from my linux host.

When I click on the "Download" command, the target starts, connects to the target through telnet and then tries to connect with TFTP. The problem is with the last one, it puts me a message "Awaiting target connection on port 69 ..." but it never connects.

I tried to look to the target server VI's but its quite difficult to understand. The problem seems to be located in EMB_Utility_TFTPD_Listen.vi at the UDP_Read function.

Also, when I netstat my windows, the tftp service is started, so port 69 seems to be opened. Netstat on my target tells me that my windows host is connected to it. The windows firewall is also disactivated.

If anyone has an idea on what's going wrong ...,

Thanks for your help,

François



0 Kudos
Message 1 of 12
(8,142 Views)
I believe the target server uses a single command line to fetch the compiled code via tftp.  There is a target server config which shows all the commands that get sent to your target.  For my linux target; tftp was the older berkley version which didn't support command line parameters.  I had to build atftp for my target in order to get the LabVIEW Embedded target server working.  Just a thought.


0 Kudos
Message 2 of 12
(8,138 Views)
Hi,

Yes, that was it, the problem came from the tftp client. I change it with an atftp client and it works well. But now I have another problem.
The tftp client download the executable file but when the transfert finish, it tells me "Failed to download file '/home/default/executable'" and puts me the error : "Wait for Pattern '[\#\$]\s*$' in Telnet_MatchPattern.vi"

I look to the downloaded file on my target and seems to be downloaded well. The problem appears when the target server tries to check the file size. Looks like the telnet server doesn't find the right path or something else.

Thanks for your help,

FP
0 Kudos
Message 3 of 12
(8,126 Views)
It appears that the target server is not recognizing your system's prompt.  I would recommend manually doing a telnet and atftp from your LabVIEW machine and check the prompt returned.  I believe that I had to add a ">" prompt in the regular expression parsing parameters found in the target server configuration cluster; to get the target server working properly with my target.

0 Kudos
Message 4 of 12
(8,098 Views)
Hi,

Try the attached VI. It goes in: vi.lib\LabVIEW Targets\Embedded\Utilities\TargetServer\utils\. It adds is a buffer flush after download and redirects any output during download to /dev/null (the output was interfering with parsing after download).



--
Michael P
National Instruments
0 Kudos
Message 5 of 12
(8,093 Views)
Hi,

Thanks for your help, your VI solves my telnet problem, but I still get the error : "Failed to download file '/home/default/executable'".


Message Edité par françoisp le 05-07-2008 10:27 AM
0 Kudos
Message 6 of 12
(8,076 Views)
Are you now able to tell if the application downloads correctly on the target (check with telnet or a terminal on the target)?

Is the application executable on the target?

If you launch the application from command prompt on the target after download, does it work?

One of the steps in the download process returns an error. Set a breakpoint in TargetServer_Download.vi and step through watching for errors.
--
Michael P
National Instruments
0 Kudos
Message 7 of 12
(8,066 Views)
Hi, sorry for being long to answer.

I have two problems, one for the target server and the other for the debug mode.

In release mode, the executable downloads well and the execution is good. The error "failed to execute program" comes from "TargetServer_GetFileSize.vi". The "Match Pattern" box doesn't give the right information (please see CheckFileSize.JPG). The problem seems to come from the "file size regex" wire.

Then, if I skip the "checkfilesize" step, the program tries to connect to the target, but it gives an other error : "Target not found". I set breakpoints in the "nitargetStartTCPDebug.vi". The ip address seems good (it's 10.0.0.213 converted in decimal) (please see TargetNotFound.JPG and Debug.JPG). I wonder if there's a "HOST_IP" to set in the compile argument or something else.

The other problem is when I try to compile a program in debug mode and instrumented debugging. It gives many errors :
" C:\Program Files\National Instruments\LabVIEW 8.5\Targets\NI\Embedded\unix\ml403TGTS\libs\libppc405rtd.a(Debug.o): In function `SetDataToControl':
../../CCodeGen/libsrc/comms/Debug.c:496: undefined reference to `SetPictFieldValue'
C:\Program Files\National Instruments\LabVIEW 8.5\Targets\NI\Embedded\unix\ml403TGTS\libs\libppc405rtd.a(CCGTimeSupport_unix.o): In function `DtToSecs':
../../CCodeGen/libsrc/os/unix/CCGTimeSupport_unix.c:91: undefined reference to `PDAClusterGetElemByPos'
../../CCodeGen/libsrc/os/unix/CCGTimeSupport_unix.c:92: undefined reference to `PDAClusterGetElemByPos'
../../CCodeGen/libsrc/os/unix/CCGTimeSupport_unix.c:94: undefined reference to `PDAClusterGetElemByPos'
../../CCodeGen/libsrc/os/unix/CCGTimeSupport_unix.c:96: undefined reference to `PDAClusterGetElemByPos'
../../CCodeGen/libsrc/os/unix/CCGTimeSupport_unix.c:98: undefined reference to `PDAClusterGetElemByPos'
C:\Program Files\National Instruments\LabVIEW 8.5\Targets\NI\Embedded\unix\ml403TGTS\libs\libppc405rtd.a(CCGTimeSupport_unix.o):../../CCodeGen/libsrc/os/unix/CCGTimeSupport_unix.c:100: more undefined references to `PDAClusterGetElemByPos' follow
C:\Program Files\National Instruments\LabVIEW 8.5\Targets\NI\Embedded\unix\ml403TGTS\libs\libppc405rtd.a(NumText.o): In function `NumToTextStatic':
../../CCodeGen/libsrc/blockdiagram/NumText.c:676: undefined reference to `StrResize'
C:\Program Files\National Instruments\LabVIEW 8.5\Targets\NI\Embedded\unix\ml403TGTS\libs\libppc405rtd.a(NumText.o): In function `NumToTextExpStatic':
../../CCodeGen/libsrc/blockdiagram/NumText.c:1145: undefined reference to `StrResize'
C:\Program Files\National Instruments\LabVIEW 8.5\Targets\NI\Embedded\unix\ml403TGTS\libs\libppc405rtd.a(NumText.o): In function `NumToTextEngStatic':
../../CCodeGen/libsrc/blockdiagram/NumText.c:1271: undefined reference to `StrResize'
C:\Program Files\National Instruments\LabVIEW 8.5\Targets\NI\Embedded\unix\ml403TGTS\libs\libppc405rtd.a(NumText.o): In function `StrPadLeft':
../../CCodeGen/libsrc/blockdiagram/NumText.c:1407: undefined reference to `StrResize'
C:\Program Files\National Instruments\LabVIEW 8.5\Targets\NI\Embedded\unix\ml403TGTS\libs\libppc405rtd.a(NumText.o): In function `StrPadRight':
../../CCodeGen/libsrc/blockdiagram/NumText.c:1431: undefined reference to `StrResize'
collect2: ld returned 1 exit status
"
I compiled the program with these arguments :  -O0 -g -DCStatic -DUsesTCPDebugger=1 -DTCPUDPSupport=1 -w -I. -DCHeadless=1 -Dlinux -fno-strict-aliasing -fno-common -fomit-frame-pointer
and the run time librairies with : -DCHeadless=1 -DNoFileSupport -DSocketSupport=1 -DTCPUDPSupport=1 -DCStatic -DUsesTCPDebugger=1 -D_Include_Scheduler -D_Include_OSScheduler -DPosixFiles=0 -DFileSupport=0 -DDatalogSupport=0 -DPalm5Earlier=0 -Wall -Dlinux -D_LIB -fno-strict-aliasing -fno-common -fomit-frame-pointer -Wa,-Wa, -Wno-pointer-sign

Thanks in advance,

françoisp
Download All
0 Kudos
Message 8 of 12
(7,824 Views)
Hi François,

The linker errors are caused because you are trying to use static memory allocation, which is not supported on without building special runtime libraries. I highly recommend that you do not use the -DCStatic flag.

Also, don't confuse LabVIEW Debugging with release vs debug in the build specification. the build spec release/debug setting refers to how the generated C code is compiled. LabVIEW instrumented debugging adds code to the generated code to allow communication of front panel/block diagram data between the target and the host PC.
--
Michael P
National Instruments
0 Kudos
Message 9 of 12
(7,814 Views)
Hi Michael,

" LabVIEW instrumented debugging adds code to the generated code to allow communication of front panel/block diagram data between the target and the host PC. "
That's exactly what I want to do. The Target Server executes the executable and tries to connect the front panel/block diagram to the application running on the target. But I get the message : "Target not found"
In the labview porting guide, at chapter 16 : instrumented debugging, it is said : " If a Linux target and the host computer are different machines, you must build the run-time libraries with TCP_USE_LOCALHOST undefined and pass the IP address of the debugger as a command line argument to the embedded application." But I didn't find this command line argument. Is the command line argument the only thing to add to get the instrumented debugging working or are there other things to implement or change ?

Thanks for your advice,

François

0 Kudos
Message 10 of 12
(7,760 Views)