S12 / MagniV MicrocontrollersのトピックRe: undocumented bits in ESTAT or FSTAT

undocumented bits in ESTAT or FSTAT

imajeff — Sat, 26 Aug 2006 03:48:21 GMT

I've been experimenting with writing and verifying that EEPROM is blank (MCU is MC9S12DG128B). I've found two undocumented features.

1. In ESTAT, bit0 is always set where docs say it is clear. I have no clue why.

2. Bit1 seems to be the "EEPROM not blank" error flag, which is also not documented. The problem is that since nothing says there was such a flag, then who would know that this flag must be cleared before any further operation??

When I used cmd 0x05 to test for blank EEPROM, ESTAT became 0xc3. "Fine", I thought, because bit0 is always set and bit1 is just another way to tell that bit2 (BLANK) is not set. So I typed `mm 800 ff` so that D-Bug12 would clear the word that was programmed. Woops, that crashed D-Bug12, because even it did not know that 0x02 must be written to ESTAT first to clear the undocumented flag.

Does anyone know about this, or is it documented anywhere?

Re: undocumented bits in ESTAT or FSTAT

DanielM — Fri, 08 Sep 2006 01:03:27 GMT

Hi,

have a look into S12XDP512 documentation, bit 1 works the same way (this is an ommision in the older S12 manuals). It is there only in special modes (i.e. only when you debug the chip). The documentation is correct as far as normal modes (i.e. normal code execution without the debugger) goes. If you switch mode to normal you should not see it anymore.

I am not sure why bit 0 is set, I believe that it does not have any real function at all.

Daniel

Re: undocumented bits in ESTAT or FSTAT

imajeff — Fri, 08 Sep 2006 02:04:36 GMT

Oh great, another omission that will never be fixed because it is fixed in some newer part number.

DanielM wrote:
I am not sure why bit 0 is set, I believe that it does not have any real function at all.

So I guess you are still saying the documentation is not correct for normal mode either, because of bit0.

Re: undocumented bits in ESTAT or FSTAT

Alban — Fri, 08 Sep 2006 17:15:40 GMT

Or simply an omission nobody reported to the Technical Publication for them to fix.........................

Entering a Service Request with document reference and what problem is in makes the correction in the next release of the datasheet.

How to get Tech Support ?!

Alban.

Message Edited by Alban on 2006-09-08 11:18 AM

Re: undocumented bits in ESTAT or FSTAT

imajeff — Fri, 08 Sep 2006 20:28:42 GMT

Are you serious, Alban?
That didn't even work to fix the simple error on the website which said the MC9S12C32 had something like 2 gig of RAM. Unless you think that the next update of the web data wasn't scheduled for over a year from the time I reported it.

Re: undocumented bits in ESTAT or FSTAT

imajeff — Fri, 08 Sep 2006 21:32:11 GMT

I am trying to enter a Service Request, but I don't see a category/topic for reporting documentation errors. I only see Documentation -->
"Cannot Locate Information"
or "Request Literature"

Why is there only options for me to admit fault, but no options to submit a Freescale documentation error?

Also what should I choose when they want me to say it's only one device I want help on. They just won't let me decide for myself what I want to say. Sometimes they give me a single field for the "document" in question, yet I want to talk about all the documents involved.

Re: undocumented bits in ESTAT or FSTAT

DanielM — Fri, 08 Sep 2006 23:04:08 GMT

imajeff,

I have tried to help you to my best knowledge. You do not seem to appreciate the fact that someone is trying to help you; I will not bother the next time...

Daniel

Message Edited by DanielM on 2006-09-08 11:05 AM

Re: undocumented bits in ESTAT or FSTAT

imajeff — Sat, 09 Sep 2006 00:30:17 GMT

DanielM wrote:
You do not seem to appreciate the fact that someone is trying to help you; I will not bother the next time...

Hey DanielM, don't get me wrong. Before I posted, I experimented and learned what the bits do (at least in special mode). I was asking if there was any documentation or anyone else who knew about it. You responded and showed that 9S12X docs are correct, thank you. I appreciate your added information.

Now maybe the subject has changed, although not really, but Alban and I are talking about how to tell Freescale that their document is wrong and they should correct it. I am not sure how you got that I did not appreciate your technical help, which is not related to my latter posts.

I do know what you mean about frustration of not being appreciated, belieeeeeve me. I had vowed to never post here again, and I don't know what got into me because apparently I did. As far as helping the forum, I don't know what you're worried about. You rank very high on feedback. I was doin good until some ignorant people started blasting me with lowest ratings possible I suppose because they didn't understand me. Thank you and Bye.

Message Edited by imajeff on 2006-09-08 11:38 AM

[INFO] Where to Report Documentation ERRORS or missing data

Alban — Mon, 11 Sep 2006 18:22:53 GMT

Dear Imajeff and all,

Here is where you can report Documentation Faults

Cheers,

Alban.

v=='hide')?'hidden':v; } // Added for webdesign..No longer using the visibility attribute for div tags, instead using Display..START dis = (v == 'visible')?'block'v=='hidden')?'none':v; obj.display = dis; //obj.visibility=v; // Added for webdesign..No longer using the visibility attribute for div tags, instead using Display..END } } function goToRUHP() { document.location="ruhp.secure_home.framework"; }

New Service Request

Please enter the following required fields to open a New Service Request.

*Required Fields

Step 1:

Category*:

Step 2:

Topic*:


Topic	When to use this Topic
CodeWarrior	Questions regarding usage/features/problems concerning CodeWarrior Software Development Environment
Design Question	Questions during design phase related to device usage or clarification question
Device Evaluation	Evaluation of possible device usage in future application/project; product information gathering - which is not content of the datasheet; Replacement parts; Packaging and Solderability; Reliability interest (MTBF, FIT);
Device Quality	Part behaviour related to DC/AC-parameters changed or is out of specification according to the datasheet; EMC-behavioral issues like EME, EMS; part functional failure;
Documentation	Documentation unclear, wrong, missing important data
Games Development Tools	Questions regarding usage/features/problems concerning Games Development Tools
HW/SW Tools (not CodeWarrior)	Questions regarding usage/features/problems concerning Freescale Hardware & Software tools/utilities, 3rd party issues
Linux BSP	Questions regarding installation and use of Freescale's Platform Creation Suite, LTIB, or Linux board support packages.

Re: [INFO] Where to Report Documentation ERRORS or missing data

imajeff — Wed, 13 Sep 2006 03:42:56 GMT

I went home and slept for a few days so I've cooled down enough to
make one more comment here. I have a response from my SR (Service
Request), and I suppose that I've contacted the wrong person because
they deny any error in the docs. I don't remember what I chose, but
I think it was "Technical Request --> Documentation" as Alban suggests.

The odd thing is that after scolding me for not masking
bits that are "reserved" bits, they go on to tell me that if I
download the latest document then I would see that
it is already documented. Are we not speaking the same language?

First let me say, yes, I have seen some bits documented as
"undefined" and some registers "reserved". I know that means I should
ignore whatever value I may read, or not use them. That is what this
guy was talking about, realistically.

Clearly those bits are not documented as such,
contrary to the SR response. In section 3.3.6 they are shown in the
diagram as being '0'. Obviously this would mean "always reads 0" (and
has always been the case until now). Second, right below that is
text: "Register bits CBEIF, PVIOL and ACCERR are readable and
writable, bits CCIF and BLANK are readable
and not writable, bits 3, 1 and 0 read zero and are not writable."
In technical english terms, this means that they always read zero,
not that they are undefined.

Does anyone find somewhere in the doc that would indicate these bits
are "reserved" or "undefined" in such a way that they should not
always read '0'? If not, then why can I not convince them that it is
a documentation error? Still, if it does contradict itself somewhere
else, that still does need corrected.

[RANT ON]

They told me in the SR response that the bits are for internal
use. Well duh, I wouldn't have been saying that was the case
if I did not know it already.

I know that nobody cares, but for the record I did not have some kind
of trouble making it work because of not masking these internally used
bits (which is what FSL assumed while trying to "support" me). I'm
smart enough to mask bits I don't need if I don't need more speed. I
am not complaining that I am stupid and do not know how how it works,
as Rafael seemed to think in the SR.

The closest thing to having trouble was when I found that when the
undocumented "FAIL" flag is set (because EEPROM was not blank), it
does not allow another EE command until it is cleared. This
definately is not documented, and will not be solved by assuming we
must ignore those undocumented internal flags!

I know most of you agree with me, but I continue for those who still
are clueless (i.e. FSL support personel). Here is the reasons why I am
insisting the documents be fixed:

[Editor: I don't mean all FSL support personel, those on this forum have been swell. Just that I've had more than a couple responding to my SRs that I repeatedly have trouble communicating with]

While I am an advanced technical engineer, there are many of us
who are not, and therefore the documentation (even for MCU that are
not the latest new thing) needs to guide them, not intuition and
tedious experimentation.
While Rafael was right that we should mask unused bits and only
look at relevant bits, these undocumented reserved bits actually
interfere with normal functionality, specifically when the FAIL flag
is set, and I would have to deliberately clear that before I can
execute the command to bulk erase.
I hereby demonstrate my point that it is near imposiible for me to
convince FSL to fix errors in their webpage or documentation. They
simply tell me I'm the one who is wrong (but give no feasible reason).

[RANT OFF]

Message Edited by imajeff on 2006-09-12 02:50 PM

[INFO] Support Satisfaction Survey forms

Alban — Wed, 13 Sep 2006 18:17:53 GMT

Hi imajeff,

Support is always a sensitive subject. I do understand the frustration we can get from them. I'm always kind of reluctant to contact any support organisation... However:

Freescale support system should send you a satisfaction survey about a month after the Service request is closed (to be sure it is closed as can be re-opened within 30 days).

Support personel is ranked on this feedback and this form does have an impact as actions are taken on them and they are distributed internally to managers.

I'm not saying you should beat them up Still if you explain why your not satisfied the support manager will analyze it. I can certify he has a passion for a job well done !

Cheers,

Alban.

Re: [INFO] Support Satisfaction Survey forms

imajeff — Thu, 14 Sep 2006 21:13:38 GMT

1. This SR contact is turning out better. Maybe I'm just learning not
to anticipate failure. He explained himself better after I gave my
concerns. Before stating that downloading the latest document would
show the missing information, he had said, "the only family that has
that functionality in the whole family is the S12C". So he was only
saying that if you download the datasheet for S12C128, the bits are
documented. Even bit 0 that I thought was always '1'.

Well of course I confused him again trying to explain that was not
good enough because the C family has no EEPROM module and I was
specifically looking in ESTAT. But that's another discussion.

Hopefully I can get the message across to FSL that these bits cannot
simply be ignored, as he is telling me. When the FAIL is set on any
device implementing it (which is undocumented in S12D family),
it prevents ANY further operation including Erase.

2. I haven't been able to complete an effective survey from any
company. They are too involved in automating the process that it
becomes impersonal and distorts the simple sentence that I could have
written quickly if they only asked, "in one or two sentences, how did
it go?"