MCF5301X Config documentation errors - Serious (?)!

[Dec]

Good morning,

We have a MCF53014 based design which is about to hit production.

Latest field tests have shown a problem whereby the board will not always boot.

This has been traced to the oscillator not starting on power up.

According to the datasheet address lines A17-A21 are used to configure the chip during reset when RSTOUT is active.

It states that none of the other address lines have any effect.

I noticed on the Freescale dev board schematic that they also drive A16 and A22 during this RSTOUT period.

By driving these lines I can make our board boot reliably.

As we are not driving these lines they are left to float and while they boot 99%+ of the time sometimes they fail.

From my tests it appears that A16 needs to be driven high during the RSTOUT period, driving it low prevents the oscillator from starting.

I've yet to determine what A22 does.

I'm waiting for a response from support but thought I'd ask if anyone else has had this problem and can confirm my findings ?

We are using a 20mhz crystal connected to the chip with the required parallel resistor and capacitors to 0V.

I do not have access to a Freescale dev board otherwise I would try my findings on that.

If the above is correct and A16/A22 need driving to known states during RSTOUT it's not a simple fix for us (Unless we bodge it by using pull-up/down resistors and don't actively drive the lines)

Thanks

Dec

[TomE]

There's nothing in the Reference Manual or Errata mentioning FB_A16.

However, given that these manuals are all made up by pasting together edited versions of previous manual chapters, sometimes it is worth doing some "genetic archaeology".

So I'm searching for all other Coldfire chips that reference "FB_A16" (or FB_A<anything>) in their Reference Manuals. Most chips override the Data lines on reset. Very few seem to override the Address lines. The search turns up...

Check the Reference Manual for the MCF52277 (MCF52277RM.pdf):

9.4.1.2 Reset Configuration (BOOTMOD[1:0] = 10)Pin(s) Affected  Affected CCM    Override Pins  Function                 Register Bit(s)   in Reset----------------------------------------------------------(none)           RCON[1]         FB_A16         Oscillator Mode                                       0             Crystal oscillator mode                                       1             Oscillator bypass mode

 FB_A18 is documented as the pin controlling the Oscillator Mode on the MCF5301X, but maybe there's a "leakage" from FB_A16.

The manual says to "pull up the other address lines or leave them floating" and maybe the development boards did that.

> it's not a simple fix for us (Unless we bodge it by using pull-up/down resistors and don't actively drive the lines)

You'll have read the Reference Manuals where they always give big warnings to "actively drive the lines during reset" and not not use pullups or pulldowns. That warning shows up in all the manuals:

MCF53017RM.pdfNOTEThe logic levels for reset configuration on FB_A[21:17] must be actively driven when BOOTMOD is 10 or 11.MCF52277RM.pdfNOTEThe logic levels for reset configuration on FB_A[21:16] must be actively driven when BOOTMOD equals 10.MCF5208RM.pdfNOTEIt is recommended that the logic levels for reset configuration on D[9,7:1] be actively driven when RCON is used.MCF5329RM.pdfNOTEIt is recommended that the logic levels for reset configuration on D[9:86:1] be actively driven when RCON is used.

Notice a pattern? You might be surprised to know that I have only ever found ONE Freescale Reference Design Board (the MCF5329 Validation Board) that obeys those recommendations. All the rest i've seenl use pullups and pulldowns on the address or data lines! So bodge away, that's what they do on the Reference Designs!

> I do not have access to a Freescale dev board otherwise I would try my findings on that.

So hunt for the Development Boards and see if you can find the schematics. Like these ones:

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=M53017MOD&fsrch=1&sr=1

http://cache.freescale.com/files/32bit/hardware_tools/schematics/M53017MODSCH.pdf?fpsp=1

That board pulls A17-A21, but seems to leave the others floating. Of course it uses resistors and not "active drivers".

You don't expect Development boards to be reliable, do you? There's often a lot of things different with them, like heavily loaded busses or bus beffers so they can be used with everything. i had a serious crystal/bus/startup problem with the MCF5329 that could be fixed by a very slow startup power supply ramp. Like the one you get with a plug-pack powering the development board. So the Devel board wouldn't show the problem until I started unplugging the power cable at the board. Then it failed to boot sometimes, and it was that proof that got this problem into the Errata.

This isn't your problem, but with regards to FB_A22, check that you're driving FB_A21 to an appropriate level during reset.

FB_A21 determines RCON[5] AKA CSC. If high, then FB_A[23:22] are FB_A[23:22] after reset, otherwise they're FB_CS[3:2].

Are you expecting them to be Address or Chip Select lines? Are they being used in any address decode, or are they feeding a ROM chip?

Keep us informed, especially if you get a sensible answer from Support. If you get an hilarious nonsense response, then post that too

Tom

[TomE]

The conversion to different web site software has mangled by previous answer. So here's an attempt at de-mangling:

Check the Reference Manual for the MCF52277 (MCF52277RM.pdf):

You'll have read the Reference Manuals where they always give big warnings to "actively drive the lines during reset" and not not use pullups or pulldowns. That warning shows up in all the manuals:

MCF53017RM.pdf
NOTE The logic levels for reset configuration on FB_A[21:17]
 must be actively driven when BOOTMOD is 10 or 11.
MCF52277RM.pdf
NOTE The logic levels for reset configuration on FB_A[21:16]
 must be actively driven when BOOTMOD equals 10.
MCF5208RM.pdf
NOTE It is recommended that the logic levels for reset configuration
 on D[9,7:1] be actively driven when RCON is used.
MCF5329RM.pdf
NOTE It is recommended that the logic levels for reset configuration
 on D[9:86:1] be actively driven when RCON is used.

Notice a pattern? You might be surprised to know that I have only ever found ONE Freescale Reference Design Board (the MCF5329 Validation Board) that obeys those recommendations. All the rest i've seenl use pullups and pulldowns on the address or data lines! So bodge away, that's what they do on the Reference Designs!

[Dec]

Hi Tom,

Thankyou for your reponse.

I think I may have confused you when I mentioned A22.

This line is operating correctly in my design but I noticed that on a Freescale dev board they actively drive it during the reset configuration period so I wondered why they were doing that.

I have a schematic for a Freescale MCF53015 dev board and that actively drives A16 and A22 using a buffer and switches to select the required configuration.  Interestingly, in the manual for this board it says...

SW5-1 A16 ON MASTER MODE

SW5-1 A16 OFF RESERVED

SW3-3 A22 ON RESERVED

SW3-3 A22 OFF DEFAULT

When the switch is ON the signal is driven high, when OFF it is driven low.

The required settings for that board are SW5-1 ON and SW3-3 OFF.

Unfortunately it doesn't say what A22 does during configuration mode, it might not do anything.

I also have a schematic for another MCF53017 eval board.  This also actively drives A16 to A22.  The recommended settings for this board is both switches off.

One thing the above boards have in common is the default settings for various jumpers on the board select an oscillator module rather than a crystal connected directly to the device.

As you say, Freescale documentation can be very confusing.

Another test I've done is to remove all chips connected to A16.  The oscillator starts as normal but any load on A16 such as a scope probe or 1M resistor prevents it from starting.  It seems the state of this line is very sensitive and it may be that most boards work most of the time.

I have just had a response from Freescale saying they are investigating my inquiry and will provide a comprehensive reply when they've finished.  I will post when I get a reply.

Thanks

Dec

[Dec]

Hi,

Well, I've now got a reply and know what needs to be done.

FB_A16 to FB_A22 should be actively driven during the reset period when BOOTMOD is set to 10.

FB_A16 should be driven high.

FB_A22 should be driven low.

If FB_A16 is driven low the chip does not work at all.

I've yet to find any information on what FB_A22 does.

Please note that the above is despite the fact that in the datasheet it says

"The logic levels for reset configuration on FB_A[21:17] must be actively driven when BOOTMOD equals 10. FB_A[23:22,16:0] should float or be pulled high.

Tech support then told me :

"The logic levels for reset configuration on FB_A[21:17] must be actively driven when BOOTMOD equals 10. FB_A[23:22,16:0] should be pulled high."

So they decided floating wasn't an option.

They then changed their minds yet again and finally decided on FB_A16=1, FB_A22=0.

Apparently this is what they do on their eval boards, strange as I've a schematic which doesn't do that and nor does it actively drive - unless you call pull-up/down resistors actively driving.

As the above is not covered in the documentation I asked if it was going to be corrected.

"To my knowledge there is not a plan to update the reference manual, but I will submit a bug report to the documentation team, just in case"

Freescale really need to get their act together when it comes to documentation and indeed chip testing.

This is the second serious problem that has been identified on this device.

I wonder how many other companies boards are working purely because FB_A16 just happens to float in the right direction ?

As you might imagine I am seriously unimpressed with Freescale over this matter.

[TomE]

> Tech support then told me :

I think their first response is to read the same manuals you're reading, on the assumption that you haven't.

> Freescale really need to get their act together when it comes to documentation

Let me show you part of the well trodden path.

Read this important document (specifically page 4-25) and see if you can see the corruption. Freescale couldn't:

http://www.freescale.com/files/netcomm/doc/ref_manual/COLDFIRE3UM.pdf

Follow the details here:

https://community.freescale.com/message/98636#98636

Then type "freescale bear pit" into Google, and if I'm not in a "filter bubble" you should end up here:

https://community.freescale.com/thread/70487

That documents over 10 year old bugs in *ALL* the Freescale product manuals and code headers for devices that have a PIT timer in them. All code I can find (even Linux) programs these timers incorrectly, leading to inaccurate timing. Any chance of an App Note, Chip Errata or Manual Errata? Not so far.

We'd all like Rolls Royce quality in our documentation, but we'll only pay (insert cheapest car brand) prices for the chips. Would you pay double (or even an extra 10%) for better documentation?

If you have a good product rep, get them to forward the serious bugs you've found back to Freescale through the "Distributor Channels" and see if they can force a new Errata document. I managed one (SECF196), so it is possible.

Tom

[Dec]

Hi Tom,

I've followed most of the threads above over a period of time.  I have to say they make pretty depressing reading :smileysad:

I'm not looking for Rolls Royce documentation, I'd settle for Skoda but Freescale are falling well short of that.

While I agree we all want chips as cheap as possible you have to add up the costs that aren't immediatley visible.

First prototype boards scrapped due to modules not working in LQFP versions of MCF5301X

Relaying of pcbs to use BGA devices.

More mods on 2nd prototype batch due to above A22/A16 problem.

Extra costs and difficulty in building and repairing boards with BGA devices.

Delays in new product being ready.

etc etc

I like Freescale products but hate the poor support to the point where I would seriously consider alternative products in the future.