Future Appnotes - FeedBack

[ericgregori]

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

[TomE]

Eric Gregori wrote:

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

Some sample appnotes that are in the works:

DMA to UART functionality

PWM

Timers

A/D converter

MAC module

interrupt controller

The original post was in August 2007. It is now January 2013.

What new App Notes for the Coldfire family have been written since then?

Freescale's Search engine is very good at answering that question. Start here:

http://www.freescale.com/webapp/search/Serp.jsp?SelectedAsset=Documentation

Then select "Application Notes" and then select "Coldfire" and then drill down to the parts you're interested in. There are currently 219 App Notes under "ColdFire+/ColdFire MCUs and Processors and 16 under "V3 Embedded Processors", the ones I'm interested in. Of the more than 30 modules in the chip I use, only two have App notes. That's not good coverage.

The latest ones there (for the V3 processors) are AN3631 on USB, AN3632: on the MCF5227x touch screen and AN3757 on uCLinux, all from 2008. AN4189 on MQX from 2010 and AN4307 on the CAU module from 2011.

> Also, I'd like to add that I did'nt know about this Appnote feedback

> which I think is a very important link between manufacter and developer.

There was ONE request from a Eric 5 years and 5 months ago, and no obvious response from Freescale since then. Not much of a "link" and no sign of any ongoing "feedback process" either.

> Lots of chip manufacturers are releasing libraries and starter kits / demo

> boards to work with the Google Android ADK.

I would suggest you start with one of them.

Tom

[RRRitchey]

I have been struggling with USB and bootloaders for the JM family.  Using the Medstack USB is just out of the question, its basic size is close to 13K.  Of the app notes you have out there for the Coldfire USB bootloaders most are very poorly documented and really, I hate to say this, kind of hacks.  It would be nice if you guys really sat down and wrote a really good bootloader that was a bit extensible (for instance I am also trying to load an external flash PROM via SPI.  If you provided one good vendor command bootloader and maybe extended that to also include an HID bootloader (the vendor command bootloader could be used as the basis with and HID extension) that would be great.

[TurboBob]

me too. Some of the recent MSD bootloaders are HUGE, which is "redicularious". A bootloader should be lean and mean, not take almost half of the larger chip (64K chip would be unusable) Most of the coldfire bootloaders require that the application run with the interrupt vectors in RAM. Ok for a desktop machine or non-critical application I suppose, but embedded stuff should run from flash and refresh all ram variables.... (my opinion) The AN2295 stuff is decent, the latest beta is very close but has a couple bugs. Hoping Pavel answers my posts there. Bob

[TurboBob]

Another good one:

Google just released its ADK,  Accessory Development Kit.  It requires a MCU with USB OTG,  so the MCF51JM would be a good candidate.

The ADK is a way to communicate with android devices over their USB ports (phones, tablets, etc)

Lots of chip manufacturers are releasing libraries and starter kits / demo boards to work with the Google Android ADK. 

Freescale should get into the mix as soon as possible,  or the Pics and Arduinos will own the market segment.  (TI, NXP, and others are in this also)

TurboBob

[sebasira]

I agree with Robert!

I'm trying to develop and android accessory with a K60, and there's no info on that from Freescale. Let's face it, android is continiuosly growing and have the advantage of provide a simple, intuitive , ready-to-use user interface that makes any development much easier and increase its impact on the market.

Also, I'd like to add that I did'nt know about this Appnote feedback which I think is a very important link between manufacter and developer.

SebaS

[kalexander]

Hi,

I have a strong need for an appnote for using UARTs via DMA on the MCF54418. The processor can't seem to handle all much traffic on all 10 uarts at 115200 with an interrupt driven driver, I am hoping DMA will speed things up enough to solve these problems but I haven't been able to get it working. An appnote on that would likely be enormously helpful.

Thanks,

Kurt

[seaside]

There is very little on setting up the PWM.  It would be nice to have sample code for all of the peripherals on the Badge Board (my development platform).

[vboccanf]

Hi, I'm new to Coldfire CPUs and I am using the MCF52259 for a project. I've been going through the Processor Expert examples which are great, but I haven't seen any examples (or AppNotes) for reading/writing to the internal Flash. Are there plans for an internal Flash App Note for the MCF5225X? Can I use the internal Flash App Note for the MCF5223X? Thanks in adavance for your help!

Regards,

Vince

Message Edited by vboccanf on 2010-02-08 08:45 PM

[TomE]

---

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.

[stalisman]

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.

[jkmahan]

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.

[jkmahan]

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));

 

[stalisman]

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.

[stalisman]

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

[jkmahan]

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).

[stalisman]

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

[stalisman]

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

[ve3id]

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

[mjbcswitzerland]

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

[sps]

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