topic Re: Future Appnotes - FeedBack in ColdFire/68K Microcontrollers and Processors

Future Appnotes - FeedBack

ericgregori — Sat, 25 Aug 2007 14:05:55 GMT

We are working on getting some new appnotes how on the ColdFire.

Specifically, we want to do a appnote to cover each of the modules in the ColdFire family ( A/D, PWM, timers, DMA, ... ).

If there is a specific module you would like to see an immediate appnote on, please let me know.

We are trying to prioritize the appnotes through editing based on immediate needs.

Some sample appnotes that are in the works:

DMA to UART functionality

PWM

Timers

A/D converter

MAC module

interrupt controller

eric.gregori@freescale.com

Re: Future Appnotes - FeedBack

Marcia — Tue, 04 Sep 2007 03:13:55 GMT

Eric,

Out here in the community, we very much appreciate all your work on the MCF5223x, and I'm surprised no-one has had the courtesy to respond to your posting.

I'd say that we are all pretty happy with the initialisation provided for the peripherals by CFInit, and the software initialisations templates and DBUG source provide much more useful references for all the CF parts.

So, do we need more Apps Notes on the peripherals - I'd say NO we don't. What is helpful is apps notes showing us how to use the more complex peripherals, such as MAC/PHY with Interniche, USB (with CMX) and the more esoteric peripherals, like DMA and CAU.

Hope that's OK, please add this into the mix.

Bye for now,

Marcia

Re: Future Appnotes - FeedBack

ericgregori — Tue, 04 Sep 2007 08:58:46 GMT

Marcia,

Thanx!!!

Check out AN3470 and AN3492.

I wrote AN3470 specifically to answer as many questions as I could about the ColdFire TCP/IP stack.

There is some coverage of the FEC, but if we need more please let me know.

For USB check out AN3492. I cover the USB OTG module very thoroughly in that appnote.

I am writeing a appnote on DMA based on a driver that you can find on my website.

http://www.emgware.com/files/pub/ColdFire_OTHER/test_ser_dma_r09.zip

The application I wrote is a serial driver using the DMA engine to transfer data to and from the UART.

A CAU appnote is also in the works.

Re: Future Appnotes - FeedBack

nordy — Wed, 07 Nov 2007 11:00:34 GMT

Eric:

I, too, appreciate all the work you've done. It seems every time I Google for info on the M5223x (and that's been often lately) your name appears.

I agree with an earlier post that what's needed, at least by those of us on the early part of the learning curve, is more "startup" info. I'm teaching an Embedded Networks class this semester, and we've purchased M52233DEMO boards for the lab, but it's turning out to be quite a struggle to do simple things. The app notes I've read (3455, 3470, and 3518), as well as some of your other pubs (TCP/IP stack deep dive) and the code samples have a lot of info, to be sure, but it still feels like drinking from a firehose!

WRT TCP/IP, I'd like to see a couple of simpler, starter-level examples. (I've seen references to an HTTP Client app, which sounds like a nice evening snack, but haven't been able to find the sample code). Maybe a superloop example or two showing TCP and/or HTTP clients in action (avoiding the RTOS at first should make for a much simpler learning experience). Anything like this available? Other advise for a rookie to the M5223x TCP/IP world?

Again, sure appreciate all you're doing for the community. Any/all help greatly appreciated. TIA!

Regards,
nordy

Message Edited by nordy on 2007-11-07 03:01 AM

Re: Future Appnotes - FeedBack

admin — Sun, 25 Nov 2007 22:58:59 GMT

Possibly, it's a time to update AN1062 'Using the QSPI for Analog Data Acquizition', which was written for mc68332.

AN1062 misses significant case of wraparound mode.

Specifically, need better explanation of timing (for questions similar to 'how to arrange exact XYZ interval between the ADC samples') and dealing with interrupt.

At least one difference between AN1062, and actual ColdFire mcf5270 timing follows: bus frequency (half of system frequency) needs to be used instead of system frequency.

Re: Future Appnotes - FeedBack

sps — Fri, 04 Jan 2008 23:27:48 GMT

As a new Coldfire user, I see the need for simple and quick USB implementation (mainly CDC, virtual com port for command interface and generic HID). Your an3492 is a good intro to the CMX kit, but the project is directory mess and does not integrate well into the latest CodeWarrior - which we love due to auto-built startup, lcf files, headers, and API docs. I hear many times from our partner developers: if we could just get a quick/simple/small footprint USB virtual comm port up on Coldfire, we'd be happy. We also develop with STMicro Cortex and Cypress PSOC - getting a generic HID and virtual comm working on those parts is built in to the IDE - minutes work and fully integrated into the part configuration tool.

Thanks - Steve

Re: Future Appnotes - FeedBack

Reibax — Thu, 11 Sep 2008 17:16:42 GMT

I agree with SPS. I would also aprreciate a simple and quick USB implementation (mainly CDC, virtual com port for command interface) for MCF532x family of microcontrollers.

Re: Future Appnotes - FeedBack

TurboBob — Fri, 02 Jan 2009 06:02:53 GMT

I have to agree. The simpler peripherals are easy enouogh to figure out, and the beans in processor expert do a decent job of getting basic applications going quickly.

I am implementing a HID device with an 08JM, and am considering stepping up to the MCF51 part. Since the USB issues were the toughest part of this project, this is the only thing that is making me reluctant to jump to the CF parts.

A drop-in USB module / app note that is compatible with Processor Expert that is either CDC or HID would be a huge help to me as well as others.

The next item would be a USB bootloader that is Processor Expert compatible. The current app note doesn't look promising, as PE likes to control things like start-up and the vectors. The mass-storage class USB idea that the badgeboard uses is intrigueing, but I doubt it would work with an app that uses the USB port for something else.

Bottom line, USB seems to be a common need. HID is nice as it is a driverless install. CDC seems to be mentioned most often as the host side (PC) communication tasks are easier.

Thanks,

Bob Bailey

Re: Future Appnotes - FeedBack

james_edwards — Thu, 23 Apr 2009 04:56:15 GMT

I've got to say that the SEC on the MCF5485 is a cryptic beast (small pun). And an appnote that illustrates how to use it would be very helpful.

James

Re: Future Appnotes - FeedBack

ve3id — Mon, 18 Jan 2010 01:36:47 GMT

Hi,

I have done a lot of design wiht the HC11 and 9S12, but I need to explore coldfire for work (I teach college) so I bought myself a M5213 badge board.

I thought it might be useful to try out in a ham radio project I am working on, to monitor the CAN bus that I am using to communicate between cards in my repeater controller.

Is there any info out there, or better still sample code, for accessing the CAN bus and possibky picking out packets for analysis?

Also, I am trying to figure out how to use the supplied CW with the badge board. With the 9S12 I use either the serial monitor or a Tech Arts and PE debug pod. I don't have a JTAG pod to use with the 5213 so I was expecting CW to be able to talk to the firmware already on the board just like the serial monitor. Is this not so?

cheers,

Nigel Johnson

Re: Future Appnotes - FeedBack

mjbcswitzerland — Mon, 18 Jan 2010 05:44:07 GMT

Hi Nigel

The Coldfire boards don't have a serial monitor in them as is the case of some 9S12 types.

I don't known the "5213 badge board" and it doesn't seem to be sold directly by Freescale - the Freescale M5213EVB is delivered together with a P&E BDM (http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=M5213EVB&fsrch=1 - total price $299). There is a demo board http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=M5211DEMO&fsrch=1 costing $99, which contains an in-board P&E BDM.

Generally I wouldn't recommend the M5213 for teaching projects since the newer Kirin3 is much better suited: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=M52259DEMOKIT&fsrch=1 - also for $99 its demo board (or new tower system for $119 (http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=TWR-MCF5225X&fsrch=1 ) will give you much more for your money and much more flexibility (the M5213 is specifically for CAN and otherwise rather limited, whereas the Kirin3 also has the same CAN controller, more memory, Ethernet and USB on top - opening many more possibilities). The Freescale demo boards have integrated BDM so can be used without having to purchase extra tools.

Unfortunately with the Badge board that you have (possibly the one that I could track down on eBay: http://cgi.ebay.com.my/ws/eBayISAPI.dll?VISuperSize&item=160383559679 ?) can not work without a BDM, which will cost about $250 if the standard P&E is chosen (http://www.pemicro.com/products/product_viewDetails.cfm?product_id=163&menu_id=details&CFID=3212551&CFTOKEN=94286562 ). There are some cheaper (but slower) ones around and also some that you can build yourself. Some people prefer to buy a cheaper demo board and cut out the in-board debugger for use with other boards...

For teaching projects you can also look at the uTasker project - it supports all V2 Coldfires, including the M5213 as well as the more advanced ones like M5225x - including a CAN driver (see http://www.utasker.com/docs/uTasker/uTaskerCAN.PDF ) as well as everything else needed for projects with these boards (OS, TCP/IP stack, USB CDC, all device drivers, FAT support for SD cards and a real-time Coldfire simulator). The simulator will also allow students to develop software for Coldfires, test it without the need for HW and debuggers, as well as analysing existing code and protocols. Use is free of change and also fully supported for educational and other non-commercial work.

Regards

Mark

www.uTasker.com

Re: Future Appnotes - FeedBack

stalisman — Tue, 19 Jan 2010 18:07:47 GMT

I would like to see something practical as regards USB on the MCF5445x at FS say.

In particular the aspect of having to loop until the priming of the endpoints has taken place before proceeding. Technical responses from freescale do not seem to doubt that there is any problem in this area. However even with the acceptence of packets and their immediate 'dumping' i.e no further processing there are still an excessive number of Naks being generated, suggesting that the wait on Priming is not ideal.

At HS there are slighlty different symptoms and are a sufficient cause for concern for us to feel that we have to utilise an off chip ISP1502/3 instead.

Re: Future Appnotes - FeedBack

jkmahan — Wed, 20 Jan 2010 00:26:11 GMT

Have you cranked up the USB priority in the memory crossbar? When we did the Linux port there were all sorts of problems, especially with HS.

Re: Future Appnotes - FeedBack

jkmahan — Thu, 29 Oct 2020 08:44:37 GMT

I probably should have added some info to that last post.

The problems we were seeing was that the USB engine was getting starved for access to the main memory. So issues were seen with USB errors from overruns/underruns in the USB engine.

Increasing the USB priority in the memory crossbar resolved all of these issues.

Here is the code I put in:

   /* Setup SDRAM crossbar(XBS) priorities */   MCF_XBS_PRS2 = (MCF_XBS_PRS_M0(MCF_XBS_PRI_2) |                   MCF_XBS_PRS_M1(MCF_XBS_PRI_3) |                   MCF_XBS_PRS_M2(MCF_XBS_PRI_4) |                   MCF_XBS_PRS_M3(MCF_XBS_PRI_5) |                   MCF_XBS_PRS_M5(MCF_XBS_PRI_6) |                   MCF_XBS_PRS_M6(MCF_XBS_PRI_1) |                   MCF_XBS_PRS_M7(MCF_XBS_PRI_7));

Re: Future Appnotes - FeedBack

stalisman — Wed, 20 Jan 2010 23:18:19 GMT

Hi jkmahan,

Thank's for the responses. I have checked our various projects, and even some 'bought in' software, and none of it modifies anything to do with the crossbar after reset.

So I guess I need to go digging and experimenting.

I'll bang in your code though straightaway.

Cheers.

Re: Future Appnotes - FeedBack

stalisman — Thu, 21 Jan 2010 00:45:29 GMT

Ah well, it was worth a try.

No effect on the major symptom of every packet being Nak'd and then Ack'd so a minimum of a 50% wastage ... even with no processing of the data.

(I down loaded a large data file and just threw the data away)

Message Edited by stalisman on 2010-01-20 04:45 PM

Message Edited by stalisman on 2010-01-20 04:47 PM

Re: Future Appnotes - FeedBack

jkmahan — Thu, 21 Jan 2010 01:06:38 GMT

Do you have a 54455EVB? If so can you put the latest linux BSP on it and try doing the same transfer? When we tested it we didn't have these problems (that I recall -- it's been a long time and we no longer work for freescale.. So things have gotten hazy).

Re: Future Appnotes - FeedBack

stalisman — Thu, 21 Jan 2010 18:02:00 GMT

I have an EVB but do not use the linux BSP. I am developing standalone firmware for a MCF54450 which I can also run on the EVB, the only difference being that I run at High Speed on the EVB instead of FS.

I put the mods into both builds, including setting Priority mode and parking the SDRAM on the OTG Master.

Again, with the EVB, every Packet is at first NaK'd, followed this time by at least 8 pings before one is Ack'd, and then when the Packet is resent it is Ack'd. Admitedly ther pings saved data transfer but the pings consumed time and hence things clearly are nowhere near optimal. This is however happening with clockwork regularity.

The MQX guys claim to have it working with the 3.4 release but I haven't tested that yet but I presume that if it works with an adequate performance, then they have implemented a work around for an unpublished bug ... so my next step is to trawl their code to see how they have set up the device in both FS and HS modes.

All cloak and dagger hence the request for an application note showing how to do it :smileyhappy:

Cheers

Re: Future Appnotes - FeedBack

stalisman — Thu, 21 Jan 2010 18:54:52 GMT

I thought I'd post these timings as an example of the regularity of it all.

It shows a Packet being accepted followed by two cycles of Nak, Pings, and Ack .... for each packet

(n-1)th
Transaction type<OUT> device<6> endpoint<1> status<ACK> speed<HS> (Packet Accepted)
time<2.521 699 583>

(n)th
Transaction type<OUT> device<6> endpoint<1> status<NAK> speed<HS>
time<2.521 705 383>

ConsecutiveTransaction count<8> type<PING> device<6> endpoint<1> status<NAK> speed<HS> time<2.521 722 767>

Transaction type<PING> device<6> endpoint<1> status<ACK> speed<HS>
time<2.521 882 033>

Transaction type<OUT> device<6> endpoint<1> status<ACK> speed<HS> (Packet Accepted)
time<2.521 902 917>

(n+1)th
Transaction type<OUT> device<6> endpoint<1> status<NAK> speed<HS>
time<2.521 909 033>

ConsecutiveTransaction count<8> type<PING> device<6> endpoint<1> status<NAK> speed<HS> time<2.521 922 767>

Transaction type<PING> device<6> endpoint<1> status<ACK> speed<HS>
time<2.522 081 783>

Transaction type<OUT> device<6> endpoint<1> status<ACK> speed<HS> (Packet Accepted)
time<2.522 103 783>

Anyone any ideas?

Message Edited by stalisman on 2010-01-21 11:00 AM

Re: Future Appnotes - FeedBack

TomE — Fri, 22 Jan 2010 11:30:43 GMT

eric gregori wrote:
We are working on getting some new appnotes how on the ColdFire.

Specifically, we want to do a appnote to cover each of the modules in the ColdFire family ( A/D, PWM, timers, DMA, ... ).

If there is a specific module you would like to see an immediate appnote on, please let me know.

eric.gregori@freescale.com

Please refer to my post in this Forum titled:

MCF5329 LCD Frame Flip Timing, when is LCD_SSAR copied?

The problem I had is that the Reference Manual gives a list of all of the registers in the LCD hardware, but doesn't give much in the way of details (flow charts, operational sequence) to be able to UNDERSTAND the hardware well enough to be able to write software to control it.

For instance there's nothing saying THAT the hardware takes a copy of the SSAR register at one specific point in its operational sequence, and that the register can therefore be written at any time. The LCD controller will "ACK" the reading of this value with an interrupt. There's nothing saying WHEN it does it either. The expectation would be "at the start of a frame", but the actuality is "immediately after the end of the data from the previous frame".

I've solved the problems, but a short example showing how to display a series of images on a QVGA (or equivalent) screen would be a good example for people to then work from.

Working example code is also very useful.