Topics

1

µTasker general / Text File EOLs Messed Up in IE Only

« on: October 15, 2009, 10:38:39 PM »

Our product has a method for a user to download a bunch of settings via a link on a web page. The settings are presented as a text file with CRLF line endings, where each line is a separate setting.

This works just fine in Firefox, Safari, and Chrome; if you left-click on the link, the text file opens in the browser and is totally legible, and if you right-click the link and choose "Save File as..." or equivalent, the default name for the file is "settings.txt" as intended.

However, with any version of Internet Explorer, left-clicking the link opens the text file in the browser but the line endings are all messed up; it appears that the CRLFs are stripped out. I believe the browser is interpreting the file as HTML instead of text, even though the URL ends with "settings.txt". Also, right-clicking the link and choosing "Save Target as..." offers the default file name "settings.htm". Whether you save the file with the offered extension "htm" or change it to "txt", the file content ends up correct, with CRLF line endings.

Of course if you look at the file going across the network with a sniffer, the content is the same regardless of browser, and always has CRLF line endings.

Does anyone know of a way to make this file look like a text file to Internet Explorer, as it does to the other browsers?

Thanks,

Dan

2

µTasker general / File upload using cURL

« on: January 17, 2009, 01:17:06 AM »

Hi Mark,

I am trying to get a file to upload to my target using cURL instead of a web browser. It seems to almost work; that is, the entire file is transferred, but the target does not seem to recognize this. I am using this command line:

curl -F datafile=@1000.dh 10.10.5.132/HS.bin

I've attached a 'good' Wireshark capture (successful upload from web browser), and a 'bad' Wireshark capture (unsuccessful upload using cURL).

Can you see what's wrong with this approach? (I do see the extra 'Expect: 100-continue' in the bad capture, but I don't know how this might affect things.)

Thanks,

Dan

3

µTasker general / Lost Ethernet Frames - Collision?

« on: November 10, 2008, 10:24:18 PM »

Hi Mark,

On my M52235 target, I have a task that sets up a listener on a UDP socket. When a particular sort of frame is received (a broadcast frame from a special utility), then the unit sends a response frame containing various data. This was implemented months ago, and has been working very reliably; the unit always responds very quickly to the broadcast frame.

Recently, and for the first time, I started running two of the targets side by side. At this point I noticed that when the units are both running, I usually don't see the response frames at all. By "usually" I mean that occasionally I do see the response frames; it's always both units, not just one or the other. I have some debug output that shows that the code that sends the response is always getting hit, whether I see the response frames on the network or not.

This is with both units connected to the same ethernet hub. I found that if I connect the units to separate hubs or switches, the problem is not seen. I suspect this is a collision issue. In fact I can see the "Collision" LED on my hub flash briefly each time. Probably when it works it's because one or both of the units lost the ARP entry of the host and had to re-ARP, thus changing the timing of things.

I could add some kind of random delay at the application level. But shouldn't the ethernet driver be handling that, if this is indeed a collision issue?

Thanks,

Dan

4

µTasker general / Simulator Stops Sending Serial Output

« on: August 02, 2008, 01:21:19 AM »

I use one of the serial ports on my 52235 target board for debugging. One of the things I do with it is dump a bunch of settings. This works fine on my target board; but I just started doing the same thing running in the simulator, and sometimes it just hangs instead of sending the data.

Here's a test case that easily reproduces the issue:

Code: [Select]

   uStrcpy(buf, "This is a test, this is only a test!\r\n");
   for(i = 0 ; i < 50 ; i++) {
      while(!fnWrite(SerialPortID, 0, uStrlen(buf)))
         ;
      fnDebugMsg(buf);
   }

It hangs in the while loop that checks if there is space in the TX buffer, sucking up cpu cycles. I tried sticking a call to Sleep() in the while loop, and while the simulator doesn't then suck up cpu cycles, it still never gets out of the loop. If I just remove the loop it never hangs, but it only actually sends a subset of the data as you would expect.

Sometimes it works, sometimes it doesn't. I haven't figured out any pattern to it. I have tried it with COM2, which is on an internal PCI card, and I have also tried it on COM8, which is on an external USB-serial device. I get the same results either way.

Keep in mind it always works fine on my target board.

Has anyone else tried something like this with uarts in the simulator?

5

NXP^TM M522XX, KINETIS and i.MX RT / Ethernet LED Support

« on: June 05, 2008, 01:46:54 AM »

I recently started paying closer attention to the ethernet LEDs that are driven by the PORTLD pins on the M5223x. (On our target, only the Link and Activity LEDs are connected.) I noticed that, when LAN_REPORT_ACTIVITY is undefined (the starting state of the uTasker project), the LEDs are handled directly by the microcontroller. That is, there is no application code controlling them, and in fact they are updated even if I stop the debugger and the application code is no longer running. There is some odd behavior in this mode, which is that if you pull the cable while the activity LED is lit, that LED stays lit even though the link LED turns off. (It's not hard to do this because the activity LED also seems to stay on a bit long when there is activity.)

If I define LAN_REPORT_ACTIVITY, then the LEDs are updated by the Network Indicator task instead, and the activity LED doesn't stay on so long (although still plenty long to see the activity), and pulling the cable while the activity LED is lit (such as during a file transfer) the LED goes off as it should. And now of course the LEDs stop getting updated if I stop the debugger.

Just curious if anyone else notices this behavior with the built-in LED support...

6

µTasker general / Keeping Track of "Any Network Connection Established"

« on: June 04, 2008, 11:08:26 PM »

In my project I want to use an LED to show whether there are any ongoing TCP sessions (or, more generally, any "network connection").

I've tried using a global counter that is incremented when a session is established, and decremented when a session is closed; so, if the counter is greater than zero, then it means there is some session established.

I haven't really gotten this to work well. What happens is that the counter ends up getting decremented multiple times when a session closes. I searched out the places in tcp.c where the listening application is sent the TCP_EVENT_CONNECTED and TCP_EVENT_CLOSED, but it seems like in some cases several of the TCP_EVENT_CLOSED locations are hit when the session is closed. The behavior I see is that if I just open and close a Telnet session, the status works fine. But if I copy files to the unit via FTP while the Telnet session is still open, the status gets changed back to "no session established' (i.e. the counter gets decrement to <= 0), even though the Telnet session has not been closed.

I realize another way to do this would be to update the global counter at the application level (i.e. in the Telnet server, and Web server, and FTP server, and so on, but it would obviously be better for it to be more generic.

Can anyone suggest a way to do this?

7

NXP^TM M522XX, KINETIS and i.MX RT / Ethernet Loopback Test

« on: April 20, 2008, 07:26:22 AM »

I am trying to find a way to do a loopback test of the ethernet port on our target board. Ideally I would like to do this with just a loopback connector on the ethernet interface, and not require any external active device to be connected.

What I am seeing is that, when running in the simulator, the application can send a broadcast UDP frame, then receive that same frame. But when running on the target board, it definitely sends the frame (I can see it in Ethereal) but does not receive it.

I have the unit send a broadcast UDP frame, using IP address of 255.255.255.255 (using fnAddARP() to add something to the arp cache so the UDP send function does not try to arp it and fail). A UDP receive task is setup to see this frame, and currently, to send a 'response' frame (also a broadcast frame).

Here is the code to send the 'request':

Code: [Select]

   unsigned char ip[4] = {255, 255, 255, 255};
   unsigned char mac[6] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
   UDP_MESSAGE udp;

   uStrcpy((CHAR *) udp.ucUDP_Message, "Request");

   fnAddARP(ip, mac, ARP_FIXED_IP);
   fnSendUDP(socket, ip, A32_TEST_SERVER_PORT, (unsigned char *) &udp + 2, uStrlen((CHAR *) udp.ucUDP_Message), OWN_TASK);

And here is the code to receive the 'request' and send a 'response':

Code: [Select]

extern void test_svr(TTASKTABLE *ptrTaskTable) {

   if(!((socket = fnGetUDP_socket(TOS_MINIMISE_DELAY, udp_listener, (UDP_OPT_SEND_CS | UDP_OPT_CHECK_CS))) < 0)) {
      fnBindSocket(socket, TEST_SERVER_PORT);
      ptrUDP_Frame = uMalloc(sizeof(UDP_MESSAGE));
   } else {
      return;
   }
}

// UDP data server - reception call back function
//
extern int udp_listener(USOCKET SocketNr, unsigned char ucEvent, unsigned char *ucIP, unsigned short usPortNr, unsigned char *data, unsigned short usLength) {

   unsigned char new_ip[4] = {255, 255, 255, 255};
   unsigned char new_mac[6] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};

   switch(ucEvent) {
      case UDP_EVENT_RXDATA:
         if(uMemcmp(data, "Request", 7) == 0) {
            fnAddARP(new_ip, new_mac, ARP_FIXED_IP);
            uStrcpy((CHAR *) data, "Response");
            usLength = uStrlen((CHAR *) data);
            fnSendUDP(socket, new_ip, TEST_SERVER_PORT, (data - sizeof(UDP_HEADER)), usLength, OWN_TASK);
         }
         break;
   }
   return 0;
}



This works fine in the simulator; the frame gets sent, and the UDP receiver task sees the frame and then sends a similar but slightly different frame. When I run on the target board, it never sees the 'request' frame that it sent. If I run my target board AND the simulator on the same net, the target board receives the 'response' frame from the simulator, but not from itself; the target board does not see its own 'request' frame.

Maybe this just means the ethernet interface is running in half duplex mode? I'm not sure what determines that; the target and the PC running the simulator are connected to the same hub.

Anyone have any other suggestion for testing the ethernet port with a minimum of external hardware?