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 - johnr

Pages: [1] 2 3 ... 7
1
NXPTM M522XX, KINETIS and i.MX RT / 52259 BDM debugger recommendation with Code Warrior 10.3
« on: May 14, 2013, 05:24:32 PM »
Hi All,
 We've been using a P&E USB Multilink Rev C BDM debugger with our 522xx products for a number of years. Recently we've started using a 52259 chip and I have noticed that programming and single-stepping in the debugger is not 100% reliable. We have to re-power the device, re-plug the USB when programming, and the single-stepping sometimes crashes. I have used the Freescale CFM52259 Tower kit, which comes with an onboard USB debug interface that works with the OSD Code Warrior driver, and it is much more reliable. Does anyone have any recommendations for 52259 USB BDM debugger?


 Thanks,
 John 

2
NXPTM M522XX, KINETIS and i.MX RT / Re: DHCP with Relay Agent bug
« on: October 12, 2012, 04:35:45 PM »
Mark, I figured someone would have run into this problem by now. We're running version 1.3.9 for the Coldfire, which we modified the network stack to work with our web software. We bought a support license 5 years ago. Do we need a new license to open the 1.4x zip projects?

 Thanks, John

3
NXPTM M522XX, KINETIS and i.MX RT / DHCP with Relay Agent bug
« on: October 11, 2012, 04:28:42 PM »
Mark, we've run into a problem using DHCP with a relay agent. The DHCP server is located on another subnet, so the broadcast request must go through a relay agent. When using this setup, our customer said all the parameters would get set except the IP. He gave us a Wireshark log of the problem,  and we were able to fix it by commenting out the check  (uMemcmp(ucDHCP_SERVER_IP, ucIP, IPV4_LENGTH)) in fnDHCPListner() . Being the incoming IP from the relay agent will be different than the DHCP server IP. it would fail.

 John


 
Code: [Select]
// The UDP listner function for DHCP port
//
static int fnDHCPListner(USOCKET SocketNr, unsigned char ucEvent, unsigned char *ucIP, unsigned short usPortNr, unsigned char *data, unsigned short usLength)
{
           |
           |
            /* check magic cookie */
            if (uMemcmp(data, ucMagicCookie_and_message, MAGIC_COOKIE_LENGTH)) return BAD_MAGIC_COOKIE;  // magic cookie is bad - quit
            data += MAGIC_COOKIE_LENGTH;

FIX            if (ucDHCP_state == DHCP_STATE_REQUESTING) {                 // we do this check here simply to avoid having to pass parameters
---->>>>                if (  /*** (uMemcmp(ucDHCP_SERVER_IP, ucIP, IPV4_LENGTH)) || ***/       (uMemcmp(usOfferedIP, ucDHCP_IP, IPV4_LENGTH))) {
                    return FOREIGN_DHCP_PACKET;                          // server or requested IP not same
                }
            }
            // the initial checks were successful - now we do state specific stuff
            return (fnDoRxDHCP(data, usOfferedIP, (unsigned short)(usLength + UDP_HLEN - (3 + 8 + XID_LENGTH + IPV4_LENGTH + 216))));
    }
    return 0;
}

4
NXPTM M522XX, KINETIS and i.MX RT / 52236/52258 Ethernet issues
« on: January 13, 2011, 04:30:13 PM »
Hi Mark, we are aware of the auto negotiation problem with the old rev 5223x chips so we run 10/100 manual modes which work on all the devices we tested so far. We use 10/100 FULL DUPLEX RX_FLOW_CONTROL.
A customer has complained that with his switches he only connects in half duplex mode. I verified this with a 10/100 switch in house that has LED indicators for the speed/duplex. The switch indicates half duplex even though I initialize the Coldfire for 100 FULL DUPLEX RX_FLOW_CONTROL. When I read the proprietary PHY status register it  says  the device is operating at 100 FULL DUPLEX, as programmed. When we set the Coldfire to auto negotiation, it connected to that switch at 100 FULL DUPLEX according to the switch LED's. Has anyone noticed this ?

 I also starting testing a 52258 Ethernet connection and found that it only connects using auto-negotiation, even when programming for manual connect at various speed/duplexes. Fortunatley it works with all the switches we've tested so far, including the ones that didn't auto negotiate with the 52236.

 Thanks,
 John  

5
NXPTM M522XX, KINETIS and i.MX RT / Re: M52258 and SP9 ethernet problem
« on: November 07, 2010, 01:41:08 AM »
Thanks Mark, the lowercase x was a typo. My co worker may have introduced the _M5223X defines. Our source tree
is heavily modified from the uTasker base.

 John

6
NXPTM M522XX, KINETIS and i.MX RT / Re: M52258 and SP9 ethernet problem
« on: November 05, 2010, 09:06:37 PM »
Hi Mark,
 We're developing products based on the 5223X and 5225x from the same
source tree. We define either 5223X or 5225x  based on the actual Coldfire chip we're
targeting. So far the SPI EEPROM, serial port and Ethernet code is working with only the 5225x
defined on the new project.
 We did have to add #if defined(M5223X) || defined(M5225X) in a number of places. Why  are there two versions of the defines. ie  _M5223X and M5223x. I originally thought the _M5223X was used in assembly code and M5223x in compiler code, but it's not the case.

 Thanks,
 John
 

7
NXPTM M522XX, KINETIS and i.MX RT / M52258 and SP9 ethernet problem
« on: November 05, 2010, 05:26:27 PM »
Hi Mark, We're using an M52258, CW10 , and porting our modified uTasker SP6 code, which we've been
running on a M5223x, to run on the new M5225x using the SP9 changes you made. I've found that in the function entry_eth() in eth_driv.c that I had to change the

     #ifdef _M5223X to #if defined(_M5223X ) || defined(_M5225X )  in the 3 places it's used to
get the ethernet to work. Without this change the ethernet buffering isn't handled properly. Is there
some other option that I'm overlooking here ?

 John


8
NXPTM M522XX, KINETIS and i.MX RT / MCF5222x and CW10
« on: August 12, 2010, 06:48:11 PM »
Hi Everyone, it's been a while since I was on this site. We're been selling a product
based on a MCF52235 and uTasker V1.3 SP6. Thanks to Mark for his fine code and
support.
  We plan on developing a product based on the MCF5222x which has 256K
of internal Flash. This requires that we update from CW V6.3 to CW V10.
 I started poking around on the FreeScale site and Google and see that people have been having
problems importing old projects into CW V10. I've tried importing our old project and
get a vague error, " unsupported settings panel version in M52235EVB_ROM". A
guy also posted this error on the FreeScale site without getting any solutions. It seems the
V10 importer isn't very good. People complained about not being able to import FreeScale
sample code either.
 Anyone have any luck doing this ?

 Thanks,
 John

9
NXPTM M522XX, KINETIS and i.MX RT / Re: SPI software upload
« on: September 25, 2008, 09:02:51 PM »
Hi Mark, I had to erase the app + file system areas in the boot code before programming
the new image, so now it works. The original code just erased the app area.


 Thanks,
 John

10
NXPTM M522XX, KINETIS and i.MX RT / Re: SPI software upload
« on: September 24, 2008, 09:53:15 PM »
Hi Mark,
 The size of the image is about 147K, layed out as

 120K code + 8K padding + 16K file system

 I'll step through the boot loader and see what's going on.
From what I understand, we should be able to do this.

 Thanks,
 John
 


11
NXPTM M522XX, KINETIS and i.MX RT / SPI software upload
« on: September 24, 2008, 09:23:51 PM »
Hi Mark. I'm using the SP5 code with the external SPI web upload feature and
everything works Ok when I do a normal code upload.
 I've written a utility to take the elf.bin code and add a file system on top. This project
doesn't use the parameter blocks because we have a EEPROM to store params. So basically I build an image

  elf.bin code + padding + Filesystem image

 I run the image through uTaskerConvert,  upload it,  and get the success message.
After reboot I get stuck in the boot loader. When I restart the debugger the app code crashes.
so I guess we did a partial program flash.
Looking at dumps of the image it looks like uTaskerConvert just adds an 8 byte header, consisting of the code length and CRC, to the beginning of the file.

 Any ideas why this doesn't work ?


 Thanks,
 John

12
NXPTM M522XX, KINETIS and i.MX RT / Re: TCP sending getting PARTIAL_ACKS
« on: April 16, 2008, 07:52:23 PM »
Mark,
 "fnSendTCP() error" gets logged when it returns <=0. I would then expect
a REGEN to resend the packet or I'll timeout waiting.
SUPPORT_PEER_WINDOW  is enabled for the project.
It's getting clearer now. I'll keep testing and logging.

 Thanks,
 John
 

13
NXPTM M522XX, KINETIS and i.MX RT / Re: TCP sending getting PARTIAL_ACKS
« on: April 16, 2008, 02:57:20 PM »
Mark, Here's a log of the my testing. The way it is setup is
that the uTasker task runs every 1 sec. When it sees that a
packet  arrived, it sends one back to the server. The uTasker
task sends packets of 12 bytes lengths and the server sends 9 byte lengths. The server sends packets at variable rates from
.1 to about 1 second.
 The PARTIAL_ACKS occur at the end of the
log. The PortLen returned was 12, which is the size that was
transmitted out. I stopped the server from sending data at this
point, got a REGEN, resent the data, then got an ACK. My protocol keeps track of packet sequence numbers so I know the
server was never getting an out of order or missed packet up to
this point.
 Under normal operations with our protocol, one side would
send a packet, then wait for a response back. One side would
never stream packets like the test server is doing here.
It looks like when the server stopped sending, we finally got the
ACK, instead of partial acks.
 Does this make any sense ?

 Thanks,
 John


Code: [Select]
0 - fnSetNextIMS_INIT --> OPEN_REQUESTED
0 - fnSetNextIMS Ok
1 - fnIMSListener() Event=CONNECTED State=OPENING
1 - fnSetNextIMS_OPENING --> IDLE
1 - fnSetNextIMS Ok
13 - fnIMSListener() Event=WIN_UPD State=IDLE
13 - fnIMSListener() Event=DATA State=IDLE
13 - fnHandleData() len=9 Offs=0
13 - fnSetNextIMS_IDLE --> PACKET_READY
13 - fnSetNextIMS Ok
13 - fnIMSListener() Event=WIN_UPD State=PACKET_READY
13 - fnIMSListener() Event=DATA State=PACKET_READY
13 - fnHandleData() len=9 Offs=0
13 - fnIMSListener() Event=WIN_UPD State=PACKET_READY
13 - fnIMSListener() Event=DATA State=PACKET_READY
13 - fnHandleData() len=9 Offs=0
13 - fnIMSListener() Event=WIN_UPD State=PACKET_READY
13 - fnIMSListener() Event=DATA State=PACKET_READY
13 - fnHandleData() len=9 Offs=0
13 - fnIMSListener() Event=WIN_UPD State=PACKET_READY
13 - fnIMSListener() Event=DATA State=PACKET_READY
13 - fnHandleData() len=9 Offs=0
13 - fnIMSListener() Event=WIN_UPD State=PACKET_READY
13 - fnIMSListener() Event=DATA State=PACKET_READY
13 - fnHandleData() len=9 Offs=0
13 - fnIMSListener() Event=WIN_UPD State=PACKET_READY
13 - fnIMSListener() Event=DATA State=PACKET_READY
13 - fnHandleData() len=9 Offs=0
14 - setup_sendpkt(), seqnum=0
14 - sendpkt(), sending 12 bytes
14 - send_pkt() sent 12 bytes
14 - fnSetNextIMS_PACKET_READY --> WAIT_ACK
14 - fnSetNextIMS Ok
14 - sendpkt returned 12
14 - fnIMSListener() Event=ACK State=WAIT_ACK
14 - fnSetNextIMS_WAIT_ACK --> IDLE
14 - fnSetNextIMS Ok
14 - fnIMSListener() Event=DATA State=IDLE
14 - fnHandleData() len=9 Offs=0
14 - fnSetNextIMS_IDLE --> PACKET_READY
14 - fnSetNextIMS Ok
14 - fnIMSListener() Event=WIN_UPD State=PACKET_READY
14 - fnIMSListener() Event=DATA State=PACKET_READY
14 - fnHandleData() len=9 Offs=0
14 - fnIMSListener() Event=WIN_UPD State=PACKET_READY
14 - fnIMSListener() Event=DATA State=PACKET_READY
14 - fnHandleData() len=9 Offs=0
14 - fnIMSListener() Event=WIN_UPD State=PACKET_READY
14 - fnIMSListener() Event=DATA State=PACKET_READY
14 - fnHandleData() len=9 Offs=0
14 - fnIMSListener() Event=WIN_UPD State=PACKET_READY
14 - fnIMSListener() Event=DATA State=PACKET_READY
14 - fnHandleData() len=9 Offs=0
14 - fnIMSListener() Event=WIN_UPD State=PACKET_READY
14 - fnIMSListener() Event=DATA State=PACKET_READY
258 - fnIMSListener() Event=WIN_UPD State=IDLE
258 - fnIMSListener() Event=DATA State=IDLE
258 - fnHandleData() len=9 Offs=0
258 - fnSetNextIMS_IDLE --> PACKET_READY
258 - fnSetNextIMS Ok
259 - setup_sendpkt(), seqnum=214
259 - sendpkt(), sending 12 bytes
259 - send_pkt(): fnSendTCP() error
259 - fnSetNextIMS_PACKET_READY --> WAIT_ACK
259 - fnSetNextIMS Ok
259 - sendpkt returned 0
259 - fnIMSListener() Event=REGEN State=WAIT_ACK
259 - send_pkt() sent 12 bytes
259 - fnSetNextIMS_WAIT_ACK --> WAIT_ACK
259 - fnSetNextIMS Ok
259 - fnIMSListener() Event=ACK State=WAIT_ACK
259 - fnSetNextIMS_WAIT_ACK --> IDLE
259 - fnSetNextIMS Ok
259 - fnIMSListener() Event=WIN_UPD State=IDLE
259 - fnIMSListener() Event=DATA State=IDLE
259 - fnHandleData() len=9 Offs=0
259 - fnSetNextIMS_IDLE --> PACKET_READY
259 - fnSetNextIMS Ok
260 - setup_sendpkt(), seqnum=215
260 - sendpkt(), sending 12 bytes
260 - send_pkt() sent 12 bytes
260 - fnSetNextIMS_PACKET_READY --> WAIT_ACK
260 - fnSetNextIMS Ok
260 - sendpkt returned 12
260 - fnIMSListener() Event=ACK State=WAIT_ACK
260 - fnSetNextIMS_WAIT_ACK --> IDLE
260 - fnSetNextIMS Ok
260 - fnIMSListener() Event=WIN_UPD State=IDLE
260 - fnIMSListener() Event=DATA State=IDLE
260 - fnHandleData() len=9 Offs=0
260 - fnSetNextIMS_IDLE --> PACKET_READY
260 - fnSetNextIMS Ok
261 - setup_sendpkt(), seqnum=216
261 - sendpkt(), sending 12 bytes
261 - send_pkt() sent 12 bytes
261 - fnSetNextIMS_PACKET_READY --> WAIT_ACK
261 - fnSetNextIMS Ok
261 - sendpkt returned 12
261 - fnIMSListener() Event=ACK State=WAIT_ACK
261 - fnSetNextIMS_WAIT_ACK --> IDLE
261 - fnSetNextIMS Ok
262 - fnIMSListener() Event=WIN_UPD State=IDLE
262 - fnIMSListener() Event=DATA State=IDLE
262 - fnHandleData() len=9 Offs=0
262 - fnSetNextIMS_IDLE --> PACKET_READY
262 - fnSetNextIMS Ok
263 - setup_sendpkt(), seqnum=217
263 - sendpkt(), sending 12 bytes
263 - send_pkt(): fnSendTCP() error
263 - fnSetNextIMS_PACKET_READY --> WAIT_ACK
263 - fnSetNextIMS Ok
263 - sendpkt returned 0
263 - fnIMSListener() Event=REGEN State=WAIT_ACK
263 - send_pkt() sent 12 bytes
263 - fnSetNextIMS_WAIT_ACK --> WAIT_ACK
263 - fnSetNextIMS Ok
263 - fnIMSListener() Event=ACK State=WAIT_ACK
263 - fnSetNextIMS_WAIT_ACK --> IDLE
263 - fnSetNextIMS Ok
315 - fnIMSListener() Event=WIN_UPD State=IDLE
315 - fnIMSListener() Event=DATA State=IDLE
315 - fnHandleData() len=9 Offs=0
315 - fnSetNextIMS_IDLE --> PACKET_READY
315 - fnSetNextIMS Ok
316 - setup_sendpkt(), seqnum=252
316 - sendpkt(), sending 12 bytes
316 - send_pkt(): fnSendTCP() error
316 - fnSetNextIMS_PACKET_READY --> WAIT_ACK
316 - fnSetNextIMS Ok
316 - sendpkt returned 0
316 - fnIMSListener() Event=PARTIAL_ACK State=WAIT_ACK
316 - fnIMSListener() PortLen=12
316 - fnIMSListener() Event=DATA State=WAIT_ACK
316 - fnHandleData() len=9 Offs=0
318 - fnIMSListener() Event=PARTIAL_ACK State=WAIT_ACK
318 - fnIMSListener() PortLen=12
318 - fnIMSListener() Event=DATA State=WAIT_ACK
318 - fnHandleData() len=9 Offs=0
319 - fnIMSListener() Event=PARTIAL_ACK State=WAIT_ACK

414 - fnIMSListener() Event=PARTIAL_ACK State=WAIT_ACK
414 - fnIMSListener() PortLen=12
414 - fnIMSListener() Event=DATA State=WAIT_ACK
414 - fnHandleData() len=9 Offs=0
415 - fnIMSListener() Event=PARTIAL_ACK State=WAIT_ACK
415 - fnIMSListener() PortLen=12
415 - fnIMSListener() Event=DATA State=WAIT_ACK
415 - fnHandleData() len=9 Offs=0
417 - fnIMSListener() Event=PARTIAL_ACK State=WAIT_ACK
417 - fnIMSListener() PortLen=12
417 - fnIMSListener() Event=DATA State=WAIT_ACK
417 - fnHandleData() len=9 Offs=0
418 - fnIMSListener() Event=PARTIAL_ACK State=WAIT_ACK
418 - fnIMSListener() PortLen=12
418 - fnIMSListener() Event=DATA State=WAIT_ACK
418 - fnHandleData() len=9 Offs=0
421 - fnIMSListener() Event=REGEN State=WAIT_ACK
421 - send_pkt() sent 12 bytes
421 - fnSetNextIMS_WAIT_ACK --> WAIT_ACK
421 - fnSetNextIMS Ok
422 - fnIMSListener() Event=ACK State=WAIT_ACK
422 - fnSetNextIMS_WAIT_ACK --> IDLE
422 - fnSetNextIMS Ok

14
NXPTM M522XX, KINETIS and i.MX RT / Re: TCP sending getting PARTIAL_ACKS
« on: April 16, 2008, 12:23:53 AM »
Hi Mark,
 I have written a test TCP server using port 9002 running under Windows XP. I programmed it using Borland
Delphi 7, which comes with  Internet Server components ready to use.
I found that I would get an ABORT event on the initial connect. When this happens while I'm in the
"CONNECTING" state, I just keep retrying the connection, at 1 second intervals, until it works.
I logged the listen events and my states so I can see what is going on.
 My current test setup waits for the server to send a short packet, then responds back with a short packet,
waits for an ACK, then goes idle. The server sends packets at rates from 1 every .1 to 1 secs. uTasker checks
every 1 sec to see if it needs to respond, so the the server can send multiple packets before the uTasker
responds. It works for a while, but then I get partial acks. I'll take a closer look at my logs to see whats going on.

 Thanks,
 John
 

15
NXPTM M522XX, KINETIS and i.MX RT / TCP sending getting PARTIAL_ACKS
« on: April 15, 2008, 10:04:24 PM »
HI Mark, I haven't been testing the TCP for a while, but I'm back on it.
I have a test server that I can send and rcv short messages. Everything
works OK but I sometimes get PARITAL_ACK events back. How should I handle
these ?

 Thanks,
 John

Pages: [1] 2 3 ... 7