Lpc2000

Hi,

This turns out to be what I think is an interesting result.

I am maintaining state of each image in flash by clearing bits in a 
state word.  This includes the boot program, which has a little 
header offset from the vector table by a few bytes.

I noticed the other day that when I over-write the flash with a value 
that writes '0's where there are already '0's, I will get a "disturb" 
elsewhere in the word.  In the specific case I found, I was writing 
0xFFF0 to a value (alread in flash) of 0xFFF5 and getting 0xF7F0 when 
I read the result back.

What was happening with my vector table is that some bit(s) in the 
first 32 bytes were being corrupted by the over-writing of a word in 
the header, outside of the vector table. 

To correct the problem, I now fill my write buffer with 0xFF's and 
zero the exact bit(s) I need to, and then write the whole page to the 
flash.  End of problem--the board boots.

I am using an LPC2294, but I suspect that this behavior would likely 
be common to all parts in the LPC2xxx family.

Thanks to those who provided pointers while I was tracking this down.


Tom


--- In lpc2000@yahoogroups.com, "tom_laffey" <tom_laffey@y...> wrote:
> 
> Martin,
> 
> 2's complement can be generated a few ways; I chose the 
> textbook "flip the bits and add 1".  Subtracting from 0 as you have 
> done produces the same value.
> 
> I'm generating the checksum on a PC (little endian) and the LPC is 
> little endian, so no trouble found there.  
> 
> I'm thinking that the checksum is a red herring, so I'm looking at 
my 
> IAP flash write function to see where there could be a problem.  If 
I 
> find something, I'll post here.
> 
> Thanks,
> 
> Tom
> 
> 
> 
> --- In lpc2000@yahoogroups.com, capiman@t... wrote:
> > Endian-Problem ?
> > 
> > ----- Original Message ----- 
> > From: <capiman@t...>
> > To: <lpc2000@yahoogroups.com>
> > Sent: Thursday, November 18, 2004 9:42 PM
> > Subject: Re: [lpc2000] Re: Interrupt Handling (Vector checksum)
> > 
> > 
> > >
> > > Have you compared what value you get with your routine and 
> perhaps load 
> > > the
> > > same with my routine ?
> > > Is it really the same ? I see you are doing a +1 at the end ?
> > >
> > > Regards,
> > >
> > >        Martin
> > >
> > > ----- Original Message ----- 
> > > From: "tom_laffey" <tom_laffey@y...>
> > > To: <lpc2000@yahoogroups.com>
> > > Sent: Thursday, November 18, 2004 8:40 PM
> > > Subject: [lpc2000] Re: Interrupt Handling (Vector checksum)
> > >
> > >
> > >>
> > >>
> > >> Hi Robert,
> > >>
> > >> Thanks for your reply.  I found Martin's checksum code, which 
is
> > >>
> > >>        ivt_CRC = 0;
> > >>        for(i = 0;i < 8; i++)
> > >>        {
> > >>            if(i == 5) continue;            // Jump over 
address 
> 0x14
> > >>            ivt_CRC += BinaryContent_as_unsigned_long[i];
> > >>        }
> > >>
> > >>        ivt_CRC = 0 - ivt_CRC;              // Negate result
> > >>        BinaryContent_as_unsigned_long[5] = ivt_CRC;
> > >>
> > >> The code I am using is in a program to add this checksum to a
> > >> binary program file before downloading:
> > >>
> > >> // pBuf is char *, aligned 4
> > >> unsigned long * pVectors = (unsigned long *) pBuf;
> > >>
> > >>        pVectors[5] = 0;
> > >>        for( checksum = index = 0; index < 8; index++)
> > >>        {
> > >>            checksum += pVectors[index];
> > >>        }
> > >>        pVectors[5] = ~checksum + 1;
> > >>
> > >> which looks like it does the same thing as Martin's.
> > >>
> > >> This has me wondering what I am missing.  When I modify the 
> binary
> > >> image and load it with my ISP program, it is not recognized by 
> the
> > >> Philips boot loader.  I can tell by stopping the CPU and 
looking 
> at
> > >> the PC: pc=0x7fffef32.  Downloading the same image using the 
> Philips
> > >> downloader (and a hex version of the executable), the program 
> boots.
> > >>
> > >> Thanks,
> > >>
> > >>
> > >> Tom
> > >>
> > >>
> > >>
> > >>