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
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.
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.
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
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.
Hi Alban,
These markings are on the chips.
They don't follow the rules, maybe they are non standard devices.
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
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
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 !
>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
<NiceVoice>
Please hold the line whilst I'm trying to get the info...
</NiceVoice>
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
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
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...