TCP(UDP) connection with Blackfin

[G-Money]

Alexander,

           Also, the issue I was having before with not getting the code to run at all were that TCP Debugging was on and that I had debugging mode set to TCP instead of JTAG. I think my issues is the ports that I'm trying to write with (I'm trying different ones than what was in your code now) but I don't know. I've statically set the IP address and Subnet but nothing seems to help. I'll let you know when the R&D Team gets back to me. 

[azukov]

Grant,

That is why I disabled debugging completely to avoid any interference between debug processes and my program.

This is really interesting that your LEDs are blinking constantly. What version of LV/VisualDSP++ do you have?

Also, what is your BF version?

Thanks,

Alexander 

[G-Money]

Alexander,

       I have the new LabVIEW 2009 and LabVIEW for Blackfin 2009. I have VisualDSP++ 5.0.6.0 and my board is BF537 with 0.2 silicon revision. I just turned on the debugging mode to JTAG/USB and just disbabled it in the Application Information.

[azukov]

I see. I am with 8.6 now. I hope I'll upgrade within couple of weeks and we'll be on the same page. The BF537 with 0.2 revision is my case as well.

[G-Money]

Alexander,

        I don't know of any updates that would have helped in this case but I will try it out on 8.6 and see what I get. I will let you know tomorrow if the LEDs blink there as well.

[G-Money]

Alexander,

         I got the VIs to work!! I started wondering if the UDP Read on the BF537 was even reading anything or if there were any errors. So I plug some of the indicators, error cluster codes, IP address, and local port to CCG Console Output.VI and monitored the status window when I ran the VI. I noticed that I was getting a timeout error (which is expected when I don't send any packets across) but more importantly I noticed that the IP Address I was using was incorrect. My local work network doesn't handle the 192.168.x.x IP address that you used so I had turned on DHCP in the Build Specs and also tried using port 60000 for the Remote Port. When I changed the UDP Sender.VI to the IP Address that was on the Output of the Status Window and sent the data packet then it showed up and the LED blinked (I bumped up the timeout to -1 so I could make sure). The other 2 LED lights continued to blink in the mean time until the timeout happens (all the LEDs freeze for a second until the timeout processes and the code continues). The Output has its own buffer and is very slow when using USB/JTAG so give it just a couple of seconds and you can see the data that came through. I have attached a picture showing what I changed on the Block Diagram of testNW-udp.VI (All I changed on UDP Sender.VI was the IP Address and Remote Port used). Let me know if you are able to run the code if you:

1) Change to DHCP in the Communication Options of the Build Specifications

2) Add the CCG Console Output.VIs so that you can get the IP Address

3) Use port 60000 for the Remote Port

4) Disable "Enable cache" in the Advanced Options of the Build Specifications

[azukov]

Grant,

I had no problem with talking, my packets were received in the very beginning. So I had no IP issues. Although your diagram yields IP = 0.0.0.0 because "String to IP" haas no input. 

My problem was (and is) freezing of all 3 loops while waiting packets. As soon as the packet is received the loops wake up but then freeze again waiting for next transmission.  

Can  you confirm that your diagram makes LED6 blink (once per 5 seconds) regardless any data being sent from UDP sender or not (with debug disabled)?

If yes, can you replicate the same with LV8.6 and send me the complete project (with build specifications)?

Thanks a lot for your help,

Alexander 

[G-Money]

Alexander,

         You are totally right!! I ended up developing this in LabVIEW 2009 (I forget what version I have opened sometimes) last night and it works fine. I tried the same thing in 8.6.1 and it doesn't. The String to IP function will actually return the host system's IP address if not wired with an input. Since I had the BF target set to DHCP, I didn't really know what IP address was going to be assigned so I used this to let me know what it had. This function doesn't work in 8.6.1 apparently because I tried using 2009 (works), using 8.6.1 on my Windows machine (works), using 8.6.1 on the BF (doesn't work) so I have filed a CAR for that and informed the R&D Team about it. More importantly I hacked the code into bits to see what is actually causing the code to hang and its the UDP Read. The UDP Open works just fine and doesn't give any error but as soon as I add the UDP Read into the while loop then everything hangs. I am looking through the c code that is generated and comparing it with the LabVIEW 2009 code that works to see what is different. I will also get back with the R&D Team to see what they think and will let you know. Here is proof though that it was working (attached screenshot). The code that is running is the same one I posted a picture of yesterday and everytime I sent the data packet the LED6 would flash faster than 5 seconds but otherwise it was flashing every 5 seconds after the timeout. The 110 error is the timeout and that would equal the flash and the blank space is because nothing was written to the UDP port so it put in a filler. I'll let you know what I find out.

[azukov]

Grant,

That's great news! At least the problem is localized and connected to specific LV version. I'll try my code as soon as I get LV2009.

Thanks a lot for your help,

Alexander 

[G-Money · Accepted solution]

Alexander,

          Yea I don't know the what the issue is (after talking extensively with the R&D team) with the UDP Read in this case. We haven't had any other issues with the VI as a whole but somehow the driver doesn't like this setup. The UDP driver comes from ADI directly and apparently there has been some updates with the newest one. I wasn't able to trace the problem down to a specific area that is solved by a specifc fix, but it does work with LabVIEW 2009. Sorry for not being more help then this but I wasn't able to find a workaround and it's hard to get R&D to work on a workaround for an older version when it is already fixed in a newer one. If there is anything else I can help with this issue though, just let me know. Thanks!!