Looking for a definition of MCF5272VM66 package markings

[rossjohnston]

Looked on website and can't find any documentation which defines the MCF5272VM566 package markings. I've got the silicon version 'K75N' but I am specifically interested in the data code of manufacture - devices I have  - have markings of CTEE1336 - and CTKK1429. I assume CTxx refers to a China manufacturing facility. How to the numbers relate to year and month of manufacture?

[miduo]

Hi,

The device marking informatin is NXP confidential and we do not disclose it. If customer really concern this issue, please contact our distributor you ordered the chip from to get the authority of this kind of information. Thanks for your consideration.

Best Regards,

Fang

[TomE]

> The device marking informatin is NXP confidential and we do not disclose it.

Unbelievable. I'd call that a competitive disadvantage.

Here's a picture I found of an MCF5272:

Windows vs Linux vs SnapGear: A Connection Sharing Odyssey

Which parts are "secret". The word "COLDFIRE"? The Part Number that matches the Data Sheet, Mask Number that is documented in the Errata or the word "KOREA"?

The Data Code ("0123" in the above for 23rd week of 2001 - yes, the article I lifted this from is dated 2001) is in "Industry Standard" format.

So the only "secret" bit in the whole of the markings seems to be the "SBGA" in the above, or the "CTEE" or "CTKK" in the original post.

But the OP wanted to know about the Date Code.

That's already been answered. Back to the original poster:

> I am trying to investigate an issue in one of our designs

Why don't you detail the issue you're having? Someone here might have a fix or a suggestion.

Tom

[rossjohnston]

Hi Tom, Thanks for your feedback - so based on your date code info - I guess my 'confidential' codes CTEE1336 and CTKK1429 yield the 36th week of 2013 and the 29th week of 2014. Additionally - our issue is that we missed tying DRESETEN to ground - signal is just floating. We don't use the SDRAM I/f in our design - however we make use of the CS7[which is also SDCS] . So during power on the SDRAM I/F has 'unpredictable' behaviour (as DRESETEN is floating) [see datasheet sheet 20-21, section 20.12] -consequently we sometimes get bus contention with our parallel Flash immediately after power up - as the SRAM  (CS7) is getting incorrectly enabled at the same time as the Flash. I am just trying to determine if one batch of processors are more sensitive to this 'unpredictability' than others.

[TomE]

> we missed tying DRESETEN to ground - signal is just floating.

That pad is N12. Not something you can get to easily if there's no via and no track.

These are old CPU chips (2001). Is this an old product that has only just started showing these problems?

That really needs a new PCB to fix. It isn't just the CPU batch as it is probably sensitive to temperature, humidity, board leakage, reset timing, power-supply ramp timing, PCB cleaning residue and heaven knows what else. It might behave differently under "brownout" conditions where the board is turned off and on again quickly.

I've had SDRAM/FLASH contention on the MCF5329 with correct resets as the SDRAM controller wakes up "random" even when it is reset, and it needs clock pulses to clock it out of bad states. But on a fast power on the rails are up before the crystal starts. Read through the following. The keyword for this problem is "undeterministic".

MCF5329 (MCF5xxx) + SDR DRAM = lockup, anyone else?

It wouldn't fail when powered from the SDK wall-wart when switched on at the mains as the power came on slowly. If the wall-wart was turned on and then connected to the board the fast ramp would cause failures. Likewise in a car with a switch connecting to a battery - fast ramp caused failure. We were able to fix it with a design change around the power supply to slow down the switch-on.

Which might help you. The controller might eventually get "sane" even if it isn't reset if it gets enough clock pulses.

Is it any more or less reliable if re-reset? Try changing the power-on ramp timing. If this can get you reliable it may be something you can fix with a component change in the power supply circuitry.

If anyone needs to "guarantee" the hardware design, or it has to start every time (don't they all?) then it may need a new PCB.

Tom

[rossjohnston]

Yeah - I have got an available via where a mod wire can be added to tie DRESETEN to ground. I've also re-turned the board (ie new PCB) to ensure the signal is tied to the ground plane for future orders. The issue is how to handle the existing boards already out in the field with customers (several thousand boards). Majority of customers do not see this issue. Hang condition appears to be recovered by power off and power on. Maybe I'll take a closer look at the on board switch-mode PSU (which generates 3v3) to see if I can slow its start-up down a bit. Happy days!!!

[miduo]

You are correct that the device marking for "CTEE" is our internal information. Why I mentioned that we do not disclose this information is because that customer mentioned: " I assume CTxx refers to a China manufacturing facility."

[rossjohnston]

I am sorry for mentioning China manufacturing facility. I have obviously caused offense? So - it is still not possible for NXP to confirm the date and year code numbering?

[rossjohnston]

We procure our boards from a subcontract assembly house and I am trying to investigate an issue in one of our designs so I am trying to determine if the processors fitted on the boards are from different batches - hence I am trying to determine the date code of the processor. Surely this information can be shared by NXP? Additionally I do not know where our subcontract assembly house procure their processors i.e. I don't know if they buy direct from NXP or buy from distribution.

[TomE]

https://en.wikipedia.org/wiki/Semiconductor_package#Date_code

Tom