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

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


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.


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;

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.


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 ?


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


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 ?


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 ?


NXPTM M522XX, KINETIS and i.MX RT / TCP socket connection
« on: April 01, 2008, 04:49:23 PM »
Hi Mark, I am using the non buffered mode and try to connect to
a TCP host from uTasker. uTasker is set to IP
and the remote host has IP After connecting the listener
gets an EVENT_ABORT. Here's the Wireshark log. It looks like uTasker
sends an ARP broadcast out asking who is, then
send out 3 ARP broadcasts asking who is then stops.
It looks like uTasker is not sening back the ARP request to

 The connect code returns OK. I got a valid socket number, 6,
and I'm using remote port 9002.
Code: [Select]
if  (fnTCP_Connect(IMS_TCP_socket, ipIMS, IMS_HOST_PORT, 0, 0)       >= 0)

 I can ping uTasker from Ok and acces the uTasker web
server with no problems.


No.     Time        Source                Destination           Protocol Info
      4 10.032296   Advantec_37:40:40     Broadcast             ARP      Who has  Tell

No.     Time        Source                Destination           Protocol Info
      5 294.297014  Phonetic_00:1f:30     Broadcast             ARP      Who has  Tell

Address Resolution Protocol (request)

No.     Time        Source                Destination           Protocol Info
      6 302.262124  Advantec_37:40:40     Broadcast             ARP      Who has  Tell

No.     Time        Source                Destination           Protocol Info
      7 303.298232  Advantec_37:40:40     Broadcast             ARP      Who has  Tell

No.     Time        Source                Destination           Protocol Info
      8 304.294644  Advantec_37:40:40     Broadcast             ARP      Who has  Tell

No.     Time        Source                Destination           Protocol Info
      9 406.338065  Vmware_26:8d:5d       Broadcast             ARP      Who has  Tell

Frame 9 (42 bytes on wire, 42 bytes captured)
Ethernet II, Src: Vmware_26:8d:5d (00:0c:29:26:8d:5d), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)

No.     Time        Source                Destination           Protocol Info
     10 406.338440  Vmware_26:8d:5d       Broadcast             ARP      Who has  Tell

No.     Time        Source                Destination           Protocol Info
     11 406.338644  Phonetic_00:1f:30     Vmware_26:8d:5d       ARP is at 00:07:f9:00:1f:30

No.     Time        Source                Destination           Protocol Info
     12 406.338789               ICMP     Echo (ping) request

Frame 12 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: Vmware_26:8d:5d (00:0c:29:26:8d:5d), Dst: Phonetic_00:1f:30 (00:07:f9:00:1f:30)
Internet Protocol, Src: (, Dst: (
Internet Control Message Protocol

No.     Time        Source                Destination           Protocol Info
     13 406.339256               ICMP     Echo (ping) reply

NXPTM M522XX, KINETIS and i.MX RT / fnSendTCP() behaviour
« on: March 27, 2008, 06:40:38 PM »
Hi Mark, I plan on using fnSendTCP()  as described in my previous post ,due
to our low bandwidth needs and it's more efficient memory usage.
 Does fnSendTCP() return <= 0 only when it can't resolve the ARP entry ?
After returning >0 the listener will get a TCP_EVENT_ACK when the other side acks us
or  a TCP_EVENT_REGENERATE on a timeout ?
 Where is the TCP send/rcv buffer size defines used in in non-buffered mode ? I should
set these to handle the largest packets I expect to send/rcv.
 If we have to break up a packet with multple fnSendTCP() calls, it loks like we would
always need to prepend the MIN_TCP_HLEN space and set the push flag to 0
except on the last packet fragment.


NXPTM M522XX, KINETIS and i.MX RT / Writing a TCP socket
« on: March 26, 2008, 06:22:42 PM »
 Is it possible to return the number of bytes written when
calling =fnSendTCP() ? The end of fnSendIP() contains the following code
which I wouldn't think would do it. It looks like it returns <= 0 on an error.
 I am porting some linux type net code to run in uTasker that would loop writting the socket until all the data went out. I see the data buffer passed in  fnSendTCP() must also contain an uninitialized TCP header area ,which isn't included in the length. If  fnSendTCP()  doesn't
return the actual byte count that was sent, what would be a safe
max that I could use to break up the data ?

Code: [Select]
    fnWrite(Ethernet_handle, dat, usLen);      // add the pay load
    return (fnWrite(Ethernet_handle, 0, 0));   // transmit the  EHERNET frame


NXPTM M522XX, KINETIS and i.MX RT / Register passing in SP5
« on: February 04, 2008, 11:08:36 PM »
Mark, how hard is it to enable register passing in the SP5 code, assuming we
recompile any libs, and check the assembler .S files for param passing ?


NXPTM M522XX, KINETIS and i.MX RT / LCD Display
« on: January 07, 2008, 04:50:59 PM »
Hi ,
 We're trying to run a HDM20416H LCD display, which is 4 lines*20 chars. I #defined
SUPPORT_LCD and the LCD works in the Simulator. When I run it in the real board
I get part of the "Hi uTasker !"  msg displayed. It looks like the timing may be off or we're writing to the wrong display memory for this chip. I tried adding redundant writes in
CLOCK_EN_HIGH and LCD_DRIVE_DATA to stretch out the timing but it still didn't work.
The registers and bit masks for this LCD look the same as the one uTasker is setup to use.

 I want to debug this using CW 6.3 light, but it doesn't break on any code in LCD.C.
I notice that when you have the source code displayed in the right hand pane, in the
left hand column of the source code there are dash lines where you would click on to set a break point. After setting the break point a red ball would appear. Some source file have dashed lines where the red ball is displayed and you can set breakpoints in these files, unfortunatley they do not show up in LCD.C. Anyone have any idea why this happens ?


NXPTM M522XX, KINETIS and i.MX RT / SW upload via Web post
« on: November 12, 2007, 10:46:24 PM »
Hi, I'm trying to do a SW upload via a Web Post after increasing the
code size from 96K to 104K. I do not have SPI_SW_upload enabled. When I leave the code size at 96K I can do the upload and see the new version displayed. I increase the code size in app_hw_m5233x.h as follows:

Code: [Select]
// FLASH based File System setup
    // #define uFILE_START 0x18000                                          // FLASH location at 96k start
    #define uFILE_START 0x1A000                                          // FLASH location at 104k start

    #define SINGLE_FILE_SIZE (1*FLASH_GRANULARITY)                       // each file a multiple of 2k
    //#define FILE_SYSTEM_SIZE (80*SINGLE_FILE_SIZE)                       // 160k reserved for file system (including parameter blocks)
    #define FILE_SYSTEM_SIZE (76*SINGLE_FILE_SIZE)                       // 152k reserved for file system (including parameter blocks)

 I change every instance of 160*1024  as follows in webinterface.c

//#if FILE_SYSTEM_SIZE >= (160*1024)                                   // support posting new firmware only with large file system
    #if FILE_SYSTEM_SIZE >= (152*1024)                                   // support posting new firmware only with large file system

 After changing the file system size I erase the whole flash and program
in the boot loader and BM code.  I then change the version number,
run make and bm_convert.bat to generate the H_Upload.bin.
After selecting the file and hitting the upload button it says
upload successfull, reboot in 10 sec. After rebooting it displays the old
version. Am I missing something in the code ?


NXPTM M522XX, KINETIS and i.MX RT / Flash memory layout
« on: November 02, 2007, 06:43:40 PM »
Hi, I've been reading though the docs and code and have
a few questions concerning the memory layout. The code size
is limited to 96K and the file system size at 160K. Being you can
use up to 62 files, each mapped to a 2K block, this allows up
to 62*2=124K of space allocated for files. I see that the SW upload
code checks for at least 160K file size.
 Is it possible to increase the code size and decrease the file system
size and still have SW uploads ?


NXPTM M522XX, KINETIS and i.MX RT / Web binary file download
« on: October 24, 2007, 03:38:08 PM »
Hi, I'm going to store some NV params in a file, Z.BIN, which our application can save and load on bootup. I'm using a file instead of the paramter block because it would require less hacking into the code when
services packs etc are released. We can download this file via Firefox 2.0
and save it on the PC. It pops up a "Save as" box when it determines it's
a binary file.  I was looking at the Ethereal trace and it doesn't look like the web server sends HTP headers describing the file, so Firefox must determine this by the extension or maybe it looks at the file contents. When we do a software update we can then FTP the paramater file back up to the unit.
 When I tested this on IE 6.0 ,it doesn't pop up a "Save as" box, but just dumps this on the screen. I added a binary header to the start of the file,
thinking maybe IE analyzes the file to determine what to do with it, but
it still just dumps it. I then added HTP headers

"Content Type: application/octet-stream\r\nContent-Type: application/force-download\r\n\Content-Length=2048\r\nContent-Transfer-Encoding: binary\r\nContent-Disposition: attachment\r\n\r\n"

 to the beginning of the file, but IE still doesn't pop a "Save as" box. I can see the header in Ethereal, so they're getting out on the line.
Is this a IE issue ? I googled around and they suggest adding the above
header to force IE to save the file. IE doesn't seem to have any settings
to tell it what to do with MIME type of application/octet stream.

 Anyone have any ideas on this ?

 Monitoring an Appache web server and accessing a .bin file on it, I notice
that it sends down an HTTP header file in a sperate packet containing

HTTP/1.1 304 Not Modified
Date: Wed, 24 Oct 2007 20:28:16 GMT
Server: Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8 mod_ssl/2.2.3 OpenSSL/0.9.8c
Connection: Keep-Alive
Keep-Alive: timeout=15, max=84

 IE doesn't know what kind of file it is and pops up the "Save As" box.
It seems like IE will interpret a file as text/HTML if it has no header and
the HTTP header must be in a seperate frame from the actual data.


Pages: [1] 2