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.


Topics - TomM

Pages: [1]
1
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

2
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

3
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]