Eric Gregori wrote:
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
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.
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
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
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
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.
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.
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.
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));
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.
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)
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
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?
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