Two ColdFire Families Announced Today

[mnorman]

In case you missed it... today Freescale announced two new ColdFire families. These two families, the MCF5222x and MCF5223x (that's right, five digit part numbers) are closely related to the MCF5211/2/3.

The MCF5223x (x=0-5) family of devices are single-chip solutions with an integrated Ethernet interface (FEC) and an on-chip Ethernet Physical Layer (PHY). Here is a link to the superset device:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCF52235&nodeId=0162468rH3YTLC00M9809...

The MCF5222x (x=1,3) family of devices are single-chip devices that feature an integrated USB host and On-The-Go (OTG) controller. Here is a link to the superset device:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCF52223&nodeId=0162468rH3YTLC00M9814...

Message Edited by mnorman on 04-04-2006 12:22 PM

[annjohanna]

Regretfully, the seminars are currently limited to the Americas. It appears that there will probably be one in September or so in Zurich, Japan, where I currently reside. So, as soon as a DEMO board becomes available, I'll try to get one. Since the DEMO board has a larger user base than the EVB (at least for the DEMO board, I have a lot of contacts with one, but almost none with the EVB), we prefer to support it. In fact, we have half a dozen different projects that were prototyped using the DEMO board because of its adorable housing and power supply, which allow customers to use it until their board arrives Here.

[MarcV]

So when will the M52233DEMO become available other than on seminars? I noticed that the manuals can be found on the AXMAN Manufacturing web site but those people don't seem to sell the board either...
...and I want it!

[EMontanez]

Hi Marc,

The M52233DEMO board is being held up by ROHS compliance. However, you can talk to your distributor to order the M52230DEMO board, which is not ROHS compliant.

Ed

[mjbcswitzerland]

Hi

I would like to order the new DEMO board but didn't find a link to it. Is it already deliverable and if so, how best to order?

We have been supporting the NE64 with the uTasker operating system and integrated TCP/IP stack for a year or so and it seems logical to upgrade support to the new Coldfire devices with Ethernet. The uTasker V1.2 for the NE64 is presently being released, including free serial debugger and software to convert the DEMO9S12NE64 into LAN capable BDM. There are online demos - see http://212.254.22.36:8080 for web cam; http://212.254.22.36 and http://212.254.22.36:8081 for on line devices (login with ADMIN / AL6000S and anon / anon resp.). A simple web based NE64 BDM is online at http://212.254.22.36:8083 also using anon / anon login.

The uTasker environment includes a unique chip simulator allowing almost complete real-time development and debugging on PC. It is free for educational and non-commercial use, with free email support - anyone interested can contact me for application.

There is a new complete project with tutorial for the NE64 (which is planned to be upgraded to Coldfire support) demonstrating powerful FTP and HTTP features. If someone at Freescale contacts me directly with an Email address I will send over a copy under the educational license for evaluation - you may be suprised at what it can do...! [needs VisualStudio 6.0 or higher for the simulation environment and compiles also to target].

Cheers

Mark Butcher
ww.mjbc.ch

[EMontanez]

Hey Mark,

The M52235EVB is available to the public today, the low-cost M52233DEMO board will be be available to the public soon, but can be acquired faster through some upcoming seminars. Read below:

COMING SOON: The M52233DEMO, an ultra-low cost version of the M52235EVB. Sign up for the Freescale ColdFire Ethernet Seminar Series and be one of the first to use this low cost, fully functional development tool. This board will be available to the public in late May or early June.

To sign up for the seminar, follow the link:
http://www.freescale.com/files/abstract/overview/TSP_8870_COLDFIRE_LP.htm?tid=tcRDck

[mjbcswitzerland]

Hi Moderator

Unfortunately the seminars are presently only available in the Americas. I have seem that there is likely to be one in Zurich, Switzerland, where I am, in September or so. Therefore I will see whether I can grab a DEMO board as soon as it is available. We prefer to support the DEMO boards since the user base is must greater than the EVB (at least this is the case for the DEMO9S12NE64 - I have many contacts with one but almost none with the EVB - we have even half a dozen different projects which were prototyped with the DEMO board since its cute housing and power supply make it suitable to even give to customers until their board arrive....)

Regards

Mark Butcher
www.mjbc.ch

[airswit]

is there a chance that any of those will be drop in compatible with the 5213? I am in the process of designing a single board computer around this controller, but wouldn't mind a USB or ETHERNET connection as well. Also, is there any word on when these will be available for sample/purchase?

[jwbodnar]

---

airswit wrote:
is there a chance that any of those will be drop in compatible with the 5213? I am in the process of designing a single board computer around this controller, but wouldn't mind a USB or ETHERNET connection as well. Also, is there any word on when these will be available for sample/purchase?

---

More or less. The USB OTG versions (MCF52221 and MCF52223) drop into the 64-pin LQFP/QFN 5211/2/3 footprint with the proviso that the 16-bit timer pins GPT[3:0] are replaced by USB_DPLS, USB_DMNS, USB_VDD, and USB_VSS.

The same applies to the 81-ball MAPBGA versions of these same families, except that the missing GPT pins now replace the dedicated PWM pins. The PWMs are available as second functions of the GPTs, just as they are on the 5211/2/3.

The 100-pin LQFP is a little trickier, as the PWM and GPT pins are interleaved on the MCF5211/2/3. The GPT pins still replace the PWM pins (as is the case on the 81-ball MAPBGA), but they've been shifted up and down to wedge the 4 dedicated USB pins between them.

One last tidbit: The MCF52221/3 take a 48 MHz crystal to supply both the reference for the system PLL and the USB. This is a change from the MCF5211/2/3.

BTW, the Ethernet parts (MCF5223x) are designed to drop into the 80- and 112-pin 9S12NE64 footprints, but the differences are a little more extensive (S12 BDM vs. ColdFire BDM, no flow control on S12 SCI vs. flow control on ColdFire UARTs, etc).

Message Edited by jwbodnar on 04-06-200602:37 PM

[EMontanez]

See the press release below for more information on sample availability:
http://biz.yahoo.com/bw/060404/20060404005598.html?.v=1

Pricing and Availability

The MCF5223x is now available in sample quantities, with production quantities planned for late 2006. MCF5222x samples are planned for June 2006, with production quantities planned for late 2006. Suggested resale pricing in 10,000-piece quantities start at $5.49 (USD) for the MCF5222X devices and at $7.99 (USD) for the MCF5223X devices.

The M52233DEMO demonstration board is available now for the suggested resale price of $99 (USD). The M52235EVB evaluation board is available for the suggested resale price of $299 (USD).

MCF5213 vs MCF522xx pin compatibility

I know for a fact that the Ethernet device M5223x is not pin to pin compatible with the M5213 rather it is pin compatible with the MC9S12NE64. On the other hand, the USB device M5222x is pin similar to the MCF5213. The main difference are the pins driving USB signals. See pg. 15 in the data sheet:

http://www.freescale.com/files/32bit/doc/data_sheet/MCF52223DS.pdf

[MarcV]

What kind of TCP/IP software comes with these demo boards?

[EMontanez]

Marc,

The EVB and DEMO boards both will come with "ColdFire TCP/IP Lite" by InterNiche. See link below for more information on this stack:

http://www.freescale.com/files/32bit/software/protocol_stacks/COLDFIRE%20TCPIP%20LITE.zip

[mjbcswitzerland]

Hi Moderator

Perhaps you can give me some tips with the problem which I now have:

I received the M52235EVB. It is supplied with a CD with the GNU compiler for the Coldfire. I would like to make a GNU project (as well as CodeWarrior).

I think that the the CD is the wrong one since it has only manuels and tools for older Coldfire version but I think that I have been able to download everything from teh Freescale web site. Also teh install of the GNU compiler from the CD didn't work - it hung every time at the end the the compiler didn't work due to a missing DLL (at least that is what the error message said). I downloaded a GNU 4.1.0 binary for the Coldfire which is the latest version.

1. I can compile my source code but I can't work out how to control it when linking. With the HCS12 I used a file called memory.x to control this but it seems as though this is not used with the Coldfire.

2. The linker always complains that it can't find the entry symbol _start. My HCS12 project has this defined in the vector table but I assume it is missing from some start up code since I also have a similar vector table - although I don't yet know whether it is used in the same manor (?).

3. I have read in the GCC docs that one should define mcpu=5200 for the coldfire but this just results in an error. I have found that mcpu=5208 works but don't know whether this is correct for this Coldfire type.

4. I don't seem to be able to find any documentation about linking for the Coldfire.

Is there any example project somewhere which could help?

Many thanks in advance.

Regards

Mark Butcher

www.mjbc.ch

[jakob]

Hi Mark,
did you try the tcp/ip stack from interniche?

http://www.freescale.com/files/32bit/doc/support_info/ColdFire_Lite_Doc.zip

i am working on my diploma with the demoboard .

best regards

jakob

[mjbcswitzerland]

Hi Jakob

No I didn't try the Interniche stack but I managed to port our uTasker to the new device.

See the following with on-line demo:
http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=274

If you would like to see it running on your demo board you can load the demo project from here (it has a web server, ftp, telnet and smtp).
http://www.mjbc.ch/software/uTasker/M5223X/uTaskerV1.2beta005_m5223X.s19

For educational and hobby use it if free of charge, including free email support, coming with an operating system, TCP/IP stack and M5223X simulator - the complete project runs in real time on a PC and can be tested in a real-network where it is not noticable that it is a simulator and not the real device running. It can save a lot of project development time since complete applications can be coded and tested before having to move to the real target - also the internal coldfire peripherals are simulated so low level debugging is very comfortable.

Cheers

Mark Butcher
www.mjbc.ch

[TomFreescale]

Hello,

Mark, can you tell me how much of the 32k ram is used by utasker and the tcp/ip stack for the following two conditions:

1. No active tcp connections
2. One active tcp connection. If the buffer size is configurable, what is the min/max?

Does anyone know what these numbers are for the Interniche rtos/stack?

The reason I am asking: Lets say I am running an application that uses the rtos and tcp/ip stack to create a web server. When a client connects with a web browser a tcp connection is established that will require a certain amount of ram to maintain (until it is closed by the web server). I need to make sure my application does not use too much much ram, so the tcp stack has enough space when it needs it.

The next logical step is to support 2 simultaneous TCP connections. One connection to do the actual product function (for example, data logging), and the second for the web server to handle configuration of the device. There will be times when the device is functioning and a user is accessing the web server at the same time. This would require enough resources for 2 TCP connections at the same time.

Thanks,

Tom

[mjbcswitzerland]

Hi Tom

uTasker requires about 54 bytes of memory for each tcp socket and about 40 bytes for a http session. (A http session needs one TCP socket and the number of http sessions is defined by #define NO_OF_HTTP_SESSIONS). This means, for example,  that 4 parallel http sessions will require about 376 bytes of SRAM.

I say 'about' because there are a number of TCP settings which can influence it slightly (eg, if you want to support MSS, windowing, etc.).

However the web server is a bit of a special case since it is possible to reconstruct messages when repetitions are needed to be performed (it is not necessary to backup transmitted data since it can be reconstructed when needed, even when dynamically generated. The source is essentially in a file system and can be fetch as required.).

Other TCP protocols can have very different characteristics - a good example is an application where data received from a serial port is being sent over a TCP connection. In this case the data has to be buffered locally and deleted only when you know that the data has been successfully delivered. If a repetition is necessary it must still be available otherwise no repetition will be possible. A second fairly similar case is when debug messages from code are being  formated to a TCP connection (the connection used as a sort of debug output as is often done over the serial port). In this case the transmit data is being put quite randomly into the output buffer and must also be stored until completely delivered as the code is non capable of reconstructing such messages if they need to be repeated.

For this second case the uTasker allows TCP sockets to be individually set up with a transmit buffer, each socket's buffer is user definable depending on the application's requirements. The TCP code then takes over the work of managing the buffer transparently. Of course this buffer eats memory... for Telnet debugging I find a buffer for this socket of about 2,5k a good compromise between performance and comfort (of course each used socket will need its own buffer...). When a buffer becomes full (queued TCP frames have not yet been delivered) it causes flow control to kick in which is noticable in reduced throughput - hopefully for only a short time, but noticable nevertheless [eg. the serial port case would have to deassert CTS or send XOFF until more place is available.]

Therefore the answer to the memory utilisation is not so easily answered in a general case, it will always depend on the application's individual requirements and protocol used, but it is best when it can at least be easily configured and controlled. Browse to a uTasker demo on-line at http://212.254.22.36 and look at the administrator web side. It will show you the worst case memory utilisation of stack and heap it has experienced. If you telnet to it "telnet 212.254.22.36" or ftp it, you can see that the heap size will change (grow slightly) (command a reset of the device from the administrator side so that it starts off fresh beforehand - It takes memory only when actually required so the value will grow to a max. after which you can be sure that it will never require more). By the way the uTasker supports also dynamic heap size allocation so the heap available can be easily optimised to real requirements, even automatically for multiple configurations.

On top of the discussed memory use, which is dynamic, there is also some basic code RAM requirements - static. tcp and http, for example, require 3 resp. 60 additional bytes of static ram, irrespective of the number of sessions to be used. There is a comparison of static FLASH and RAM sizes in the uTasker tutorial - see page 16 of the following document. (the compiler used is also quite critical...!!)

http://www.mjbc.ch/documents/uTasker/NE64/uTaskerV1.2-Tutorial.PDF

The FLASH requirements on the Coldfire increase by about 80% (unfortunately) due to the fact that it is a 32 bit machine and has longer instructions but the Coldfire demo application is still only about 50k in size, showing that quite a lot can be packet in to the M5223X...(It takes up about 24k on a 16 bit device or an ARM in Thumb mode)

Regards

Mark

www.mjbc.ch

[TomFreescale]

Thanks Mark. Great answer!