On Monday 24 April 2006 09:54, John Heenan wrote: > The 'first thing', as falsely claimed on the web site, has to wait > eight ARM instructions to complete after reset with additional wait > states imposed by accessing the VPB. If it was genuinely the 'first > thing' it would only require three ARM instructions to complete! It's likely that you're talking about different versions of the bootloader. Bootloader version 1.63 on a LPC2294 does what Jaya describes on his page. It swaps the content of PINSEL2 with a 0x0 in the first three instructions. Anyway, I don't think that it matters if it's done in the first three or eight instructions - the window is too small for the necessary number of JTAG cycles. I said it before, and I'm happy to repeat it: CRP is safe in that regard. > ATMEL fuse bits are nothing more than non volatile storage bits, > which guess what, so is address 0x1FC where the CRP value is held! One difference is that a "fuse" could be evaluated by the hardware itself, without relying on software (e.g. use the fuse value to force nTRST). This is more complicated with flash, which could be the reason why Philips made CRP at least partly a software feature. > ADDITIONALLY WHAT IS YOUR PROBLEM WITH ACCEPTING MY CENTRAL POINT > THAT AN ENABLED JTAG DOES NOT MEAN NECESSARILY INTERNAL DEBUG > SIGNALS JTAG MAY BE ATTEMPTING TO ASSERT WILL BE ALLOWED TO ACT? THIS > IS OBVIOUS TO ANYONE WITH EVEN A MODEST COMPETENT KNOWLEDGE OF > ELECTONICS AND MICROCONTROLLER ARCHITECTURE. I don't understand why you're repeating this claim again and again. At least I haven't seen any evidence that suggests that what you're saying is true - at least not for the LPC2294. There's nothing in the code path that would enable "internal debug signals" after the bootloader determined that CRP isn't enabled, so they have to be enabled right out of reset. The LPC2294 lacks the CSPR register, but maybe you could test this: Attach your debugger to the target, halt it, read the CSPR and write 0x87654321 to the CSPR location. Would be interesting to see if this has any effect on the debug functionality. Regards, Dominic Rath
Message
Re: [lpc2000] Re: CRP (Code Read Protection) investigation by stepping through the boot loader
2006-04-24 by Dominic Rath
Attachments
- No local attachments were found for this message.