Lpc2000

I'm a beginner in LPC2000 and I'm developing a program for lpc2210. I 
have
these questions:

1) Is newlib the best library option for memory allocation usage?

2) Does anyone have expecience with uclibc or diet libc? what's the 
best?


3) Does memory allocation with newlib need sbrk implementation with 
the
compiler arm-elf-gcc? Does anybody have any examples? Is there any
fragmentation problem?

4) How can I determine my program stack size? I tried avrora and
stacktool, but both are for atmel.

At 07:15 PM 11/5/04 +0000, you wrote:


>I'm a beginner in LPC2000 and I'm developing a program for lpc2210. I
>have
>these questions:
>
>1) Is newlib the best library option for memory allocation usage?

Define best.  It depends on what you are doing.  I believe it is a general 
purpose allocator and so subject to all the usual concerns.  Personally for 
an embedded system I wouldn't use mallac and company except at startup to 
provide memory blocks.  On going uses would either use fixed preallocated 
blocks or allocate out of a pool to avoid fragmentation issues.


>2) Does anyone have expecience with uclibc or diet libc? what's the
>best?

No experience with either, make sure the license is compatible with your use.



>3) Does memory allocation with newlib need sbrk implementation with
>the
>compiler arm-elf-gcc? Does anybody have any examples? Is there any
>fragmentation problem?
It does need an sbrk implementation (newlib-lpc provides one), but they are 
not difficult.



>4) How can I determine my program stack size? I tried avrora and
>stacktool, but both are for atmel.

Count :)

Actually, I'm at least half serious about that.  If you are not doing 
recursive calls it's relatively straightforward, if a little tedious, to 
simple count up the stack usage.

The other obvious approach is to mark the stack and see how far down it 
descends by looking for the stack end while running,  Not as foolproof 
against rarely executed paths but more robust against arithmetic errors.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Hi Robert,

I went through the same "wondering".
I noticed that the VICVectAddr gets reset after the vector to weak
irq_handler. I just copped out and replaced

>   ldr pc, [pc, #irq_handler_address - . - 8]

with the classic :

ldr    pc, [pc , # -0xFF0]

That sets up VIC to directly vector to your IRQ handler address programnmed
in.

PS : Don;t forget to update your bootloader checksum in vector table when
you change it !

-- Kris


----- Original Message -----
From: "Robert Wood" <robert.wood@...>
To: <lpc2000@yahoogroups.com>
Sent: Sunday, November 07, 2004 11:17 PM
Subject: [lpc2000] Interrupt Handline


> Hi folks,
>
> I'm struggling to understand how to handle interrupts for the 2294. I can
see
> that when I get an interrupt, the processor jumps off to the following
line
> of code in the startup assembly file:
>
>   ldr pc, [pc, #irq_handler_address - . - 8]
>
> This then jumps off to the following line of code:
>
> irq_handler:
>   b irq_handler
>
> There is a comment that these are defined as weak variables and can be
> redefined in user code. So, at the moment, it's quite easy to see that
when
> there's an interrupt the program just gets stuck on this line of code. It
> seems obvious that I then have to redirect this code to the appropriate
> interrupt handler. I would have thought that I need to read the
VICVectAddr
> which should contain the address of one of the registers VICVectAddr0 to
> VICVectAddr15. I assume that the program would jump to that VICVectAddrX
> register and then from there to the user code which has been written to
deal
> with the interrupt.
>
> What I'm not clear about is how to replace this line of code:
>
> irq_handler:
>   b irq_handler
>
> To something like:
>
> irq_handler:
>   b (VICVectAddr)
>
> In other words, when I get to the line of code
>
> irq_handler:
>
> Then jump to the location pointed to be the contents of VICVectAddr. I
assume
> that if I can set that up, the compiler will sorted out jumping to
wherever
> VICVectAddrX points to.
>
> Am I basically correct in my assumptions, or way off line?!
>
> Many thanks,
>
> Rob
>
>       Yahoo! Groups Sponsor
>             ADVERTISEMENT
>
>
>
>
>
> --------------------------------------------------------------------------
------

> Yahoo! Groups Links
>
>   a.. To visit your group on the web, go to:
>   http://groups.yahoo.com/group/lpc2000/
>
>   b.. To unsubscribe from this group, send an email to:
>   lpc2000-unsubscribe@yahoogroups.com
>
>   c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>

Hi folks,

I'm struggling to understand how to handle interrupts for the 2294. I can see 
that when I get an interrupt, the processor jumps off to the following line 
of code in the startup assembly file:

  ldr pc, [pc, #irq_handler_address - . - 8]

This then jumps off to the following line of code:

irq_handler:
  b irq_handler

There is a comment that these are defined as weak variables and can be 
redefined in user code. So, at the moment, it's quite easy to see that when 
there's an interrupt the program just gets stuck on this line of code. It 
seems obvious that I then have to redirect this code to the appropriate  
interrupt handler. I would have thought that I need to read the  VICVectAddr 
which should contain the address of one of the registers VICVectAddr0 to 
VICVectAddr15. I assume that the program would jump to that VICVectAddrX 
register and then from there to the user code which has been written to deal 
with the interrupt.

What I'm not clear about is how to replace this line of code:

irq_handler:
  b irq_handler

To something like:

irq_handler:
  b (VICVectAddr)

In other words, when I get to the line of code 

irq_handler:

Then jump to the location pointed to be the contents of VICVectAddr. I assume 
that if I can set that up, the compiler will sorted out jumping to wherever 
VICVectAddrX points to.

Am I basically correct in my assumptions, or way off line?! 

Many thanks,

Rob

What toolchain are you using ?
Depending on toolchain, I could send you the modfied startup file directly..

----- Original Message -----
From: "Robert Wood" <robert.wood@...>
To: <lpc2000@yahoogroups.com>
Sent: Sunday, November 07, 2004 11:42 PM
Subject: Re: [lpc2000] Interrupt Handling


> Thanks, Kris.
>
> >> PS : Don;t forget to update your bootloader checksum in vector table
when
> you change it ! <<
>
> Erm, I'm embarrassed to say I don't know how to work out what to change it
to!
>
>       Yahoo! Groups Sponsor
>             ADVERTISEMENT
>
>
>
>
>
> --------------------------------------------------------------------------
------

> Yahoo! Groups Links
>
>   a.. To visit your group on the web, go to:
>   http://groups.yahoo.com/group/lpc2000/
>
>   b.. To unsubscribe from this group, send an email to:
>   lpc2000-unsubscribe@yahoogroups.com
>
>   c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>

Thanks, Kris.

>> PS : Don;t forget to update your bootloader checksum in vector table when
you change it ! <<

Erm, I'm embarrassed to say I don't know how to work out what to change it to!

Apart from the VIC handler, you shouldn't have a pressing need to
change the vector table, they're all weak symbols, so you just need to
define
a handler with the same name to override, doesn't affect your table.

Eg : An swi_handler :

# ifdef    EXCEPTIONS
void swi_handler (void )
{
// do your own thing
}
#endif


the address of your swi_handler function will override
in the linker, so you don't need to change the vector table for that.

-- Kris




----- Original Message -----
From: "Robert Wood" <robert.wood@...>
To: <lpc2000@yahoogroups.com>
Sent: Sunday, November 07, 2004 11:51 PM
Subject: Re: [lpc2000] Interrupt Handling


> >> What toolchain are you using ? <<
>
> Crossworks.
>
> >> Depending on toolchain, I could send you the modfied startup file
> directly.. <<
>
> The datasheet says:
>
> "The reserved ARM interrupt vector location (0x0000 0014) should contain
the 2
> s complement of the check-sum of the remaining interrupt vectors. This
causes
> the checksum of all of the vectors together to be 0."
>
> So, I'm thinking it shouldn't be that difficult to actually work out, but
I'm
> don't understand whether it's just talking about the first few memory
> locations, all the interrupt vectors, both, or something else again.
>
> I should work out how to calculate it really, as there's every chance I'll
> want to mod it again!
>
>       Yahoo! Groups Sponsor
>             ADVERTISEMENT
>
>
>
>
>
> --------------------------------------------------------------------------
------

> Yahoo! Groups Links
>
>   a.. To visit your group on the web, go to:
>   http://groups.yahoo.com/group/lpc2000/
>
>   b.. To unsubscribe from this group, send an email to:
>   lpc2000-unsubscribe@yahoogroups.com
>
>   c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>

>> What toolchain are you using ? <<

Crossworks.

>> Depending on toolchain, I could send you the modfied startup file  
directly.. <<

The datasheet says:

"The reserved ARM interrupt vector location (0x0000 0014) should contain the 2 
s complement of the check-sum of the remaining interrupt vectors. This causes 
the checksum of all of the vectors together to be 0."

So, I'm thinking it shouldn't be that difficult to actually work out, but I'm 
don't understand whether it's just talking about the first few memory 
locations, all the interrupt vectors, both, or something else again. 

I should work out how to calculate it really, as there's every chance I'll 
want to mod it again!

At 12:51 PM 11/7/04 +0000, you wrote:

> >> What toolchain are you using ? <<
>
>Crossworks.
>
> >> Depending on toolchain, I could send you the modfied startup file
>directly.. <<
>
>The datasheet says:
>
>"The reserved ARM interrupt vector location (0x0000 0014) should contain 
>the 2
>s complement of the check-sum of the remaining interrupt vectors. This causes
>the checksum of all of the vectors together to be 0."
>
>So, I'm thinking it shouldn't be that difficult to actually work out, but I'm
>don't understand whether it's just talking about the first few memory
>locations, all the interrupt vectors, both, or something else again.
>
>I should work out how to calculate it really, as there's every chance I'll
>want to mod it again!

That really shouldn't be necessary, the download tool should take care of 
that.  I've never modified it directly myself.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> Hi Robert,
> 
> I went through the same "wondering".
> I noticed that the VICVectAddr gets reset after the vector to weak
> irq_handler. I just copped out and replaced
> 
> >   ldr pc, [pc, #irq_handler_address - . - 8]
> 
> with the classic :
> 
> ldr    pc, [pc , # -0xFF0]
> 
> That sets up VIC to directly vector to your IRQ handler address 
programnmed
> in.
> 
> PS : Don;t forget to update your bootloader checksum in vector 
table when
> you change it !
> 
> -- Kris
> 

Here's the way I do it:

// IRQ exception handler. Calls the interrupt handlers.
__irq __arm void irq_handler(void)
{
	void (*interrupt_function)();
	unsigned int vector;

	vector = VICVectAddr;	 // Get interrupt vector.
	interrupt_function = (void(*)())vector;
	(*interrupt_function)(); // Call vectored interrupt function.
	VICVectAddr = 0;	 // Clear interrupt in VIC.
}

That way you can write the individual ISRs in thumb mode.  The IRQ 
handler must be written in ARM mode because the processor is in that 
mode when an exception occurs.  During linking the weak link to 
irq_handler (or whatever it is called) gets replaced with the C 
function.

Randy Ott

Hi Randy,

Thanks, I must have overlooked something, because I was in the belief that
the VICVectAddr was "lost" once in the "irq_handler", thought could only
handle
it in ASM - must have gotten confused somewhere.

B rgds
Kris

> Here's the way I do it:
>
> // IRQ exception handler. Calls the interrupt handlers.
> __irq __arm void irq_handler(void)
> {
>       void (*interrupt_function)();
>       unsigned int vector;
>
>       vector = VICVectAddr;      // Get interrupt vector.
>       interrupt_function = (void(*)())vector;
>       (*interrupt_function)(); // Call vectored interrupt function.
>       VICVectAddr = 0;      // Clear interrupt in VIC.
> }
>
> That way you can write the individual ISRs in thumb mode.  The IRQ
> handler must be written in ARM mode because the processor is in that
> mode when an exception occurs.  During linking the weak link to
> irq_handler (or whatever it is called) gets replaced with the C
> function.
>
> Randy Ott

It also keeps you from fiddling with the startup code when you want 
to write apps with or without IRQ.

I should also mention that if you are using GCC you will need to use 
something like "__attribute__((interrupt)(IRQ))" instead of 
the "__irq" and "__arm" modifiers.

Randy

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> Hi Randy,
> 
> Thanks, I must have overlooked something, because I was in the 
belief that
> the VICVectAddr was "lost" once in the "irq_handler", thought 
could only
> handle
> it in ASM - must have gotten confused somewhere.
> 
> B rgds
> Kris
> 
> 
> > Here's the way I do it:
> >
> > // IRQ exception handler. Calls the interrupt handlers.
> > __irq __arm void irq_handler(void)
> > {
> >       void (*interrupt_function)();
> >       unsigned int vector;
> >
> >       vector = VICVectAddr;      // Get interrupt vector.
> >       interrupt_function = (void(*)())vector;
> >       (*interrupt_function)(); // Call vectored interrupt 
function.
> >       VICVectAddr = 0;      // Clear interrupt in VIC.
> > }
> >
> > That way you can write the individual ISRs in thumb mode.  The 
IRQ
> > handler must be written in ARM mode because the processor is in 
that

> > mode when an exception occurs.  During linking the weak link to
> > irq_handler (or whatever it is called) gets replaced with the C
> > function.
> >
> > Randy Ott

Hi Robert,

Did you ever solve the vector table checksum problem?  Like you, I've 
tried the algorithm described in the manual (the one you typed below) 
and the boot code won't start when the file is loaded with IAP.  From 
the description, the checksum covers the first 8 words. 

My application uses IAP for firmware updates, so long-term dependency 
on the Philips downloader is not an option.

Thanks,

Tom



--- In lpc2000@yahoogroups.com, Robert Wood <robert.wood@a...> wrote:
> >> What toolchain are you using ? <<
> 
> Crossworks.
> 
> >> Depending on toolchain, I could send you the modfied startup 
file  
> directly.. <<
> 
> The datasheet says:
> 
> "The reserved ARM interrupt vector location (0x0000 0014) should 
contain the 2 
> s complement of the check-sum of the remaining interrupt vectors. 
This causes 
> the checksum of all of the vectors together to be 0."
> 
> So, I'm thinking it shouldn't be that difficult to actually work 
out, but I'm 
> don't understand whether it's just talking about the first few 
memory 
> locations, all the interrupt vectors, both, or something else 
again. 
> 
> I should work out how to calculate it really, as there's every 
chance I'll 
> want to mod it again!

At 06:30 PM 11/18/04 +0000, you wrote:
>Did you ever solve the vector table checksum problem?  Like you, I've
>tried the algorithm described in the manual (the one you typed below)
>and the boot code won't start when the file is loaded with IAP.  From
>the description, the checksum covers the first 8 words.
>
>My application uses IAP for firmware updates, so long-term dependency
>on the Philips downloader is not an option.

Take a look at the source for Martin's LPC21ISP.  It does the calculation 
and it should be simple to adapt.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

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




--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 06:30 PM 11/18/04 +0000, you wrote:
> >Did you ever solve the vector table checksum problem?  Like you, 
I've
> >tried the algorithm described in the manual (the one you typed 
below)
> >and the boot code won't start when the file is loaded with IAP.  
From
> >the description, the checksum covers the first 8 words.
> >
> >My application uses IAP for firmware updates, so long-term 
dependency
> >on the Philips downloader is not an option.
> 
> Take a look at the source for Martin's LPC21ISP.  It does the 
calculation 
> and it should be simple to adapt.
> 
> Robert
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try 
to

> chew a radio signal. "
> 
>                          Kelvin Throop, III

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@...>
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
>
>
>
>
> --- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...>
> wrote:
>> At 06:30 PM 11/18/04 +0000, you wrote:
>> >Did you ever solve the vector table checksum problem?  Like you,
> I've
>> >tried the algorithm described in the manual (the one you typed
> below)
>> >and the boot code won't start when the file is loaded with IAP.
> From
>> >the description, the checksum covers the first 8 words.
>> >
>> >My application uses IAP for firmware updates, so long-term
> dependency
>> >on the Philips downloader is not an option.
>>
>> Take a look at the source for Martin's LPC21ISP.  It does the
> calculation
>> and it should be simple to adapt.
>>
>> Robert
>>
>> " 'Freedom' has no meaning of itself.  There are always
> restrictions,
>> be they legal, genetic, or physical.  If you don't believe me, try
> to
>> chew a radio signal. "
>>
>>                          Kelvin Throop, III
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Endian-Problem ?

----- Original Message ----- 

From: <capiman@...>
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@...>
> 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
>>
>>
>>
>>
>> --- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...>
>> wrote:
>>> At 06:30 PM 11/18/04 +0000, you wrote:
>>> >Did you ever solve the vector table checksum problem?  Like you,
>> I've
>>> >tried the algorithm described in the manual (the one you typed
>> below)
>>> >and the boot code won't start when the file is loaded with IAP.
>> From
>>> >the description, the checksum covers the first 8 words.
>>> >
>>> >My application uses IAP for firmware updates, so long-term
>> dependency
>>> >on the Philips downloader is not an option.
>>>
>>> Take a look at the source for Martin's LPC21ISP.  It does the
>> calculation
>>> and it should be simple to adapt.
>>>
>>> Robert
>>>
>>> " 'Freedom' has no meaning of itself.  There are always
>> restrictions,
>>> be they legal, genetic, or physical.  If you don't believe me, try
>> to
>>> chew a radio signal. "
>>>
>>>                          Kelvin Throop, III
>>
>>
>>
>>
>>
>>
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

At 09:42 PM 11/18/04 +0100, you wrote:
>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 ?

Inverting and adding 1 is a twos complement negation so I would expect it 
to be that same.  I think you are right though a comparison would be useful.

Tom what processor are you running this on?

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

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
> >>
> >>
> >>
> >>

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
> > >>
> > >>
> > >>
> > >>