Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - TomM

Pages: [1]
1
Hi Mark,

First off, I did not try to add the code you provided yet. I got side tracked on debugging more basic issues in the application's behavior like handling the multiple Listeners correctly and you didn't provide a reference to where it should be placed.  Unfortunately I am now consistently getting an "undef_int()".  This appears to be caused by a uMemcpy() in tcp.c which is being passed a ptrTo value of 0. 

So 1st question is: I'm still using the old copy of tcp.c (uTasker-1.4.006?) with the newer copy of telnet.c (uTasker-1.4.013).  I think I chose not to update due to the effort involved and reviewing the differences I thought it should be OK.  What are your thoughts?

The second is could you have a look at the snap shots from the debugger I've attached and see if you can suggest a way to catch this that I haven't explored.  I know the fault always happens on the same message type, but not every occurrence of the message.  The message address which is passed looks OK.  I'd appreciate you assistance since I'm not seeing issues with the data being passed.

Thanks,

Tom

2
Mark,

This post is merely a question relating to TCP buffering, i.e. the Telnet Server and Client are operating nicely. 
Somewhere along the line I got the idea that I could queue multiple data packets to a Telnet Socket and not start the send until I placed what I wanted in there, maybe 120 bytes .  After rereading the document you wrote captioned "how to use buffered TCP to transmit TCP frames" I realized I appear to have gotten the wrong idea.  So do I any options except to have my application buffer the messages before sending?

Regards,

Tom

3
Mark

As usual, you seem to have found the thing I was missing, i.e. the duplicate MAC addresses. I really do know better but... after correcting that, returning to the default window size and fixing a couple of host packet processing issues, both applications are merrily communicating as expected :)

Thanks for the assistance.

Tom

4
Hi Mark,

I have been looking at Wireshark captures between the Telnet Client and the Telnet Server.  I have attached two capture files which demonstrate issues with the ACK and Sequence numbers being generated by the Telnet Client (at 192.168.0.10).  In the first file I only had TELNET_session->usTelnetMode set to TELNET_RAW_MODE.  Backtracking through the code I found the check "        if ((TELNET_session->usTelnetMode & (TELNET_CLIENT_MODE | TELNET_CLIENT_NO_NEGOTIATION)) == (TELNET_CLIENT_MODE)) { // acting as a client with negotiation not edisabled".  I appeared to me that the negotiation this was allowing had the ACK being miscalculated.  So I changed to TELNET_session->usTelnetMode = (TELNET_RAW_MODE | TELNET_CLIENT_MODE | TELNET_CLIENT_NO_NEGOTIATION).  This resulted in the second Wireshark file which has different ACK/SEQUENCE values which are still in error until a RETRANSMIT occurs. 

I'd appreciate your assistance since this appears to be a Telnet Client Code issue.

Regards,

Tom

5
Mark, 

My Version of uTasker must be too old.  I did a search for the string TELNET_CLIENT and got zero results.  My copy of application.h defines SOFTWARE_VERSION as "V1.4.011".  I recall that you provided a pointer to the latest code a while ago, but I don't think my team members ever downloaded it.  I can look back and see where you pointed me before and/or you could suggest how else I can add the CLIENT functionality.

Regards

Tom

6
On my last project at Mark's suggestion, I used Telnet to implement a Server (though there was only one client).  In the end that has worked out quit well.  My current project however now just needs client functionality.  So I've been looking at the Telnet code and wonder if I duplicate the start function and change the fnTCP_Listen() call to an fnTCP_Connect() call, if that would give me what I think I want?

Thanks in advance for your thoughts.

Tom

7
Hi Mark,

I've got two MCF52258's on the same PCB using a direct cross linked TXD2/RXD2 to perform SIPC (Serial Inter-Processor Communication).  I've implemented message packets that include packet length info and checksums so I can try to make sure I don't process junk.  My problem is that I'm occasionally seeing checksum errors in the received data from one processor, i.e. the one that doing most of the transmitting.  At this point, the retry logic in the code detects the UNACKED message and resends the exact same data using the same code to transmit it again. This last point combined with the fact that I've included verification that fnWrite() did queue the entire message makes me fairly confident my code is sending what it thinks it is. 

So the real issue is that when I use a logic analyzer set to trigger on the checksum error (software activated testpoint), the serial message on the wire is one byte short of what it should be, i.e. 87 instead of 88.  It required the 1st byte of the retry message to complete the packet processing and decide the checksum was incorrect, however the retry message is 88 bytes as expected.

So I'm wondering if you recall any issues with the serial driver losing one character in a transmission block?  I searched the Forums and didn't see any likely entries.

FYI:
The baud rate being used is 750kb and I've attached a file containing the serial port initialization.

Thanks Tom

8
NXPTM M522XX, KINETIS and i.MX RT / Re: KDS Highlighting issues
« on: March 19, 2015, 02:01:56 PM »
Hello Hans,
While I don't use the KDS tool, I am using CW 10.5 which is also Eclipse based.  I had similar issues and after doing much searching of Eclipse CDT posts, I now have things working OK.  If my memory is correct, the key point was setting Projects/ Properties/ C/C++ General/ Code Analysis to "Use Project Settings".  Obviously you also need to define the appropriate Macros in the Preprocessor section so that the Code Analysis realizes what the base defines are.  However, as Mark mentioned OPSYS_CONFIG and TaskConfig.h will still display as not being compiled.  When I really want to see that file in the compiled context, I do a temporary local edit and add #define OPSYS_CONFIG.

Hope that helps!

Tom

9
NXPTM M522XX, KINETIS and i.MX RT / Re: uTaskerConvert hangs up
« on: March 27, 2014, 10:11:33 PM »
Hi Mark,

I'll try that tomorrow, but I'm wondering why the CW7.2 files could be combined before converting?   

On a related note, I mentioned I was having problems flashing with a USB Multilink.  I found a thread on FreeScale where someone reported the same issue with an MFC52259.  Seems they fixed it by creating a project from scratch instead of importing from a CW 7.2 project.  So even though I started from your CW 10.xx project, I gave it a try.  Amazingly, from the PE project, I can program flash and debug in RAM.  Although, the debugging doesn't seem to stop at breakpoints in RAM.?  Anyway it's progress.  :)

Thanks

Tom

10
NXPTM M522XX, KINETIS and i.MX RT / Re: uTaskerConvert hangs up
« on: March 27, 2014, 02:25:32 PM »
Hi Mark,

I did check out your CW10.x guide as I moved the project and it was very helpful. :)  Also, I was using V1.6 of utaskerConvert, so I updated.  Unfortunately that did not change the results.  uTaskerConvert is still reported as crashing by W7.  I've attached a text file with the commands used to invoke combine and convert along with the crash details from the dialog box.  I'll send the *.bin file in a private email for you to take a look at.

Thanks!

11
NXPTM M522XX, KINETIS and i.MX RT / uTaskerConvert hangs up
« on: March 26, 2014, 09:29:08 PM »
Hi all,

I'm trying to move my project (MCF52258) from CW 7.2 to CW 10.5 and have run into a snag.  I've searched and found answers to most of the issues encountered but the final step is evading me.  I've added a post-build step to run a batch file for converting to a downloadable binary file.  Only thing is that when the routine runs uTaskerConvert, the program hangs and Windows (7-64bit) opens a dialog box stating that uTaskerConvert.exe has stopped working.  I verified in a DOS window that the paths specified are correct and in fact I've tested the command manually in a DOS window and it hangs there too.  The only other thing I can think of is I'm not generating the correct form of binary file.  I selected "Generate Binary Image" and did not select "Generate Raw-Binary Image".  As an aside, I'm also having trouble getting the P&E USB ColdFire Multilink to flash the device or start a debug session.

Any suggestions would be appreciated. :)

Pages: [1]