Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: re lpc2100_fan's objection to CRP thread

2006-02-28 by John Heenan

I don't believe I have got any facts wrong. The best interpretation 
is that Jaya is very naive and has no idea just how deficient his 
knowledge of electronics and the ARM architecture is and has no real 
experience of how a support system works.

Below is probably a normal commencement to a genuine support issue.

1) Notify a problem
2) Expect to get a stock reply pulled from a support database from an 
excessively polite overworked junior level support person who is not 
very knowledgeable and is desperate to get a good feedback rating.
3) If the stock reply does not answer the issue, try and clearly 
explain the problem again and ensure the problem can be replicated 
with information you give. Keep fingers crossed.
4) Hope the problem will be escalated and that feedback will be 
received.

My guess is that Jaya's supposed problem eventually made its way to 
someone who had real knowledge and insight, saw the correspondence, 
gave correct information to the support person, realised Jaya has no 
idea of what he is talking about and realised the support person  
pulled the wrong information out. If this were the circumstances then 
Philips had no real choice except to apologise.

The point here is that IT IS NORMAL TO EXPECT UNRELIABLE INFORMATION 
in private communications from big companies. 

What is really sad is that there is probably some junior support 
person with a black mark in his file cursing they had the misfortune 
to receive confused ramblings from someone without any real insight.

Thanks Jaya for demonstrating you cannot tell the difference between  
a break pedal and a break pad. My guess is that you won't even 
understand the analogy I have made.

John Heenan

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> John, you seem to have some of your facts wrong.
> 
> --- In lpc2000@yahoogroups.com, "John Heenan" <l10@> wrote:
>  > Fact 1. JTAG hardware operates independently. Nothing JTAG does,
>  > including reset signals, will make the slightest bit of 
difference
>  > unless the signals JTAG passes are not blocked and so are 
allowed to
>  > act. Simple invertor and OR logic gates are perfectly adequate to
>  > block signals.
> 
> Could you explain what your point is in the above paragraph 
please.  I read 
> it a few times but cannot make out what you intend to point out.
> 
>  > Fact 2. The boot loader decides if CRP (Code Read Protection) is
>  > enabled and so decides if it will allow signals from JTAG to act.
> 
> Wrong.  JTAG signals are enabled or disabled on reset by pulling 
specific 
> GPIO pins low on boot [see notes on page 120 of 2294 user manual]. 
The boot 
> loader *disables* it, and then at a later time enables it if it 
thinks that 
> CRP is not enabled.
> 
>  > Fact 3. Even if CRP is an afterthought, so what if it works.
> 
> The problem is afterthoughts like this are more likely to fail.  In 
this 
> case, where the hardware designers have not included security 
features, it 
> is usually not possible to add this as an afterthought using 
> software.  Indeed, if it works for LPC, then it would also work for 
the 
> other ARM cores ... but ... one wonders none of the others are 
claiming 
> they have CRP.
> 
>  > Fact 4. A lot of contradictory statements from Philips have been
>  > quoted including an apology and clarification (P3) that parallel
>  > programming uses either JTAG and/or ISP.
> 
> I noticed this too, and this is perhaps the main reason why I have 
rated 
> Philips as not credible.
> 
>  > Fact 5. Use of an incomplete statement (C1); admitted to be in
>  > a 'different context' that contradicts directly Philips 
apparently
>  > later clarification in Fact 3. Reuse of C1 as C5.
> 
> When you examine evidence, there is the notion of "contemporary" 
evidence 
> for which I give more weight, than further evidence in the process 
of 
> defensive examination that contradicts it.  This is quite common 
practice 
> in industry.
> 
> It is quite possible that had I posed the first question in 
relation to CRP 
> issues, I would have got quite a different answer and the 
availability of 
> parallel programming option would not have been raised at all.
> 
>  > John Heenan
> 
> Send instant messages to your online friends 
http://au.messenger.yahoo.com
>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.