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 caseif 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
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"; } 
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 !