topic Re: an2295 bootloader erasing flash at $FFB0 when attempting to erase $EE00 on QT4demo board. in 8-bit Microcontrollers

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

jimw — Wed, 22 Feb 2006 04:53:10 GMT

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.

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

ok2ucx — Wed, 22 Feb 2006 20:58:33 GMT

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

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

jimw — Thu, 23 Feb 2006 02:05:34 GMT

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.

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

Alban — Thu, 23 Feb 2006 19:20:00 GMT

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.

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

eckhard — Thu, 23 Feb 2006 20:53:21 GMT

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

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

Alban — Thu, 23 Feb 2006 22:24:52 GMT

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.

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

eckhard — Thu, 23 Feb 2006 23:02:08 GMT

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

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

JM — Fri, 17 Mar 2006 09:06:45 GMT

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 ?

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

Alban — Fri, 07 Apr 2006 23:41:57 GMT

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.

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

JM — Fri, 26 May 2006 10:23:49 GMT

Hi Alban,

These markings are on the chips.

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

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

Alban — Tue, 06 Jun 2006 18:39:15 GMT

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.

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

JM — Tue, 06 Jun 2006 23:31:29 GMT

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

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

eckhard — Wed, 07 Jun 2006 15:12:23 GMT

Hello,

I have a couple of Nitrons too with this markings and witout Maskset printed on them. It seems that the first batches have no maskset printesd on them. They are regular MC68hc908qy4 parts not XC or anything else. They definitly have the PTA3 bug.

Eckhard

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

Alban — Wed, 07 Jun 2006 17:17:34 GMT

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

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

JM — Wed, 07 Jun 2006 23:09:20 GMT

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 !

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

peg — Thu, 08 Jun 2006 04:35:30 GMT

>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

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

bigmac — Thu, 08 Jun 2006 11:30:05 GMT

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

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

rocco — Thu, 08 Jun 2006 12:19:55 GMT

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?

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

Nabla69 — Fri, 09 Jun 2006 02:44:50 GMT

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

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

Alban — Fri, 09 Jun 2006 02:52:47 GMT

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