an2295 bootloader erasing flash at $FFB0 when attempting to erase $EE00 on QT4demo board.

[jimw]

I tought the mask rom was 3L89J but reading it again it could be 3L69L as in

errata http://www.freescale.com/files/microcontrollers/doc/errata/MSE908QY4_3L69J.pdf

I can reproduce this everytime.

1. Flash the bootloader from AN2295 on the QT4DEMO board using a MON08 type programmer. Verify S19 record. Verify $F4 in flash protect. Disconnect MON08.

2. Start bootloader master on PC. Power up Demo Board. All looks good and select continue.

3. The PC master reports programming $EE00 and hangs.

4. Look at the memory using the MON08 and find $FFB0 - $FFBF contains $FF.

The errata says. Do not write any other Flash address while page erase is in progress. The bootloader uses on chip flash routines and I don't think it returns until the operation is complete. (?)

The errata also says disable the COP, which the bootloader does, MOV #%10000001,CONFIG1. ( but why set short timeout?).

The SCI Read routine does touch the COP but should not have an effect on this and commenting out the STA COPCTL  still produces the same error.

I can't see what code is writing to FLASH while an erase is in progress.

Any one know how  I can get around this? I rather not wait to get another QT4 to test.

[eckhard]

Hello,

I don´t think the code is so confidential. You can access it with the debugger and it is not much code, so everyone who knows a little HC08 assembler should be able to reverse engeneer it. The ROM locations are documented and if not you can loof where $FEFF points to. The QT4 will differ a bit because parallel transfer of he security bytes is not an option on this MCU. The source code of the User Monitor for the QT/QY chips is a good source of information too. It covers what the P&E software expects to receive.

Eckhard 

[eckhard]

Hello,

Jed Margolin has disassembled the Monitor Entry code for the GP32.

http://www.jmargolin.com/project/cdrom2.htm

It seemd that there is saome logic that takes care if the first access to the reset vector is a read or a write and then decides if the FLASH is secured or not.

Eckhard

[Alban]

Eh Eckard,

Interesting site indeed. I'm surprised the guy doesn't fear any legal action. I mean I didn't think posting publicly reverse engineering was authorized.

Anyway, the GP32 is really, but really old and the Monitor ROM code is different on the much more recent QT4.
Still, it has to perform the same kind of operations, of course.

Alban.

[jimw]

Pavel,

Thank you for your response. I tought about having a look at the ROM but did not want to bother disassembling it.

It would be nice if the ROM source listing was available. Is it?

I would think relocating the upper page would still make the reset vector table vunerable. The code would have to check and re-flash the upper page if needed, but then a power outage at the wrong time would require a monitor mode re-flash.

But since any newer MASK shouldn't have this problem why bother codeing a solution for just one part.

[Alban]

Hi Jim

The ROM content is Freescale Confidential Proprietary information.

You won't be allowed to get the source, I'm afraid. It contains info on how the security is handled and I guess it's easily understandable...

Cheers,
Alban.

[ok2ucx]

Hi,

unfortunately the ROM code actually does the write to COPCTL (0xFFFF). Unfortunately I've never dealt with this buggy maskset so never experienced this erasure.

The only way how to overcome this is probably to shift memory allocation of the bootloader one erase page lower avoiding any code at 0xFFB0-0xFFBF locations. I thought of squeezing some code to save 12 bytes but I don't see any possible candidates (beside COPCTL control in READ and WRITE routines). Other way would be to create own Erase routine which would cost some additional memory too.

It's rather better to obtain later maskset with this bug removed.

I know it doesn't help too much but at least I will add a warning into next AN2295SW release.

Regards,

Pavel, Freescale Roznov p.R.

AN2295 author

[JM]

QT4 ZRPG Mask set of my DemoBoard is like Mask set 3L69J ... buggy !

The problem is known since 3L69J and the solution too.

The rom routine ERARNGE (the page erase routine) doesn't implement the solution.

ZRQG Mask set do no have this problem !

How about a thread on Mask set errors ?

How many Mask sets between 3L69J and ZRQG ?

What does those letters stand for ?

Do we have to find them the hard way ?

[Alban]

Hi JM,

ZRQG is not a mask set reference.
Masks sets are 1 number, 1 letter, 2 numbers, 1 letter.

The first number being the minor revisions on the mask.
For instance, 3L69J is Rev3 of L69J.
BUT: it doesn't mean that 0, 1 or 2 are available to you or even existing in packages !!!

Cheers,
Alban.

[JM]

Hi Alban,

These markings are on the chips.

They don't follow the rules, maybe they are non standard devices. 

[Alban]

Yo,

Just back...
Not that the device is not standard, but on the small devices there isn't the space to write everything
Freescale doesn't ship "non-standard" devices, except Engineering Samples for customers who need to start NOW even if product is not fully validated.
Parts you will get through a distributor will always be the fully qualified ones. A worry less !

Cheers,
Alban.

[JM]

Hi Alban,

If it's not written on the chips it's useless!

What does the middle line on theses little chips mean ?

Jean Mercier 

[Alban]

Well Jean, that's one way to see things...
If it's written so small nobody can read it, it's not of great use either !

The code given is enough for the quality people to find the source of your product, if it's a quality incident.

What is the middle line content you want explained ?

Cheers,
Alban.

Message Edited by Alban on 2006-06-07 11:18 AM

[JM]

Hi Alban,

Chips with second line marking : ZRPQ

are buggy.

Chips with second line marking : ZRQG

are OK.

So that's why I tought, these markings were related with mask sets somehow !

[peg]

>Chips with second line marking : ZRPQ

>are buggy.

Zeeze aRe Poor Quality?????????????

>Chips with second line marking : ZRQG

>are OK.

Zeeze aRe Quite Good????????????

>So that's why I tought, these markings were related with mask sets somehow !

Sorry!

I have got QY2 with RMAA0514 and QY4 with RMEV0448.

So what mask set do these use?

Regards David

[Alban]

<NiceVoice>
                         Please hold the line whilst I'm trying to get the info...
</NiceVoice>

[Alban]

Yo Peg,

MC68HC908QY2CP with RMAA0514 and MC68HC908QY4CP with RMEV0448 will both be 0L04Y from reply I got.

Cheers,

Alban.

[bigmac]

Hello Peg,

I believe the last four digits of the code represent the date of manufacture.  So "0514" would represent week 14 of 2005, and "0448" would represent week 48 of 2004.

I have some earlier QY2 devices in a DIP marked "ZRTK0248", and some QY4 devices in SOIC marked "5NN0307".  I know these QY2 devices do not have the COP reset bug within the ROM based routine ERARNGE (I have checked the disassembly against the latest AN1831).  I am not sure about the PTA3 bug.

I find the argument that there is insufficient room to print the mask set ID a bit unbelievable for a 16-pin DIP, or even an 8-pin one.

Regards,
Mac

[peg]

Hi Bigmac,

Yeah, almost all IC's use the year/week coding as these seem to do.

The thought that there is insufficient room on a DIP16 holds no water as QG8's manage it with 3 rows of text.

e.g.

M9S08QG8
CPBE 3M77B
RMAA0607

Regards David

[rocco]

Regardless of whether the mask code is printed on the chip, I would like to see the mask identified in a read-only register, so that the firmware can handle the mask errata.

If Intel can do this, why can't Freescale?

[Nabla69]

I'll be cheeky...

I think FSL doesn't do this because they are trying to fix things for the next mask.
Also I don't understand how you can write a software for a future mask.

If you work in automotive, you would buy particular MCUs and you don't need to do a distinction as you know what you get.

For the mask thing it's indirectly linked to the 2nd line mentioned. I mean once a product is fixed, I would think they stop producing the one with the Erratum. Therefore from the date, and when the erratum was published, you can see if the product was produced on a new mask or not. So when you go into production, you validated your code on one MCU/Mask.

Anyway, I don't think the politics is to make anyone write for a Mask. It's already painful enough to have to change module soft from one device to another without having to do so within the same one. (S12 have a PARTID register, not mask)
I never came across a workaround on one mask which was incompatible with the next one. I don't say it doesn't exist, I say I've never had the issue.

Alvin...