Yahoo Groups archive

Lpc2000

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

Thread

LPC2106

LPC2106

2005-05-07 by Amir Sherman

Pl's see below my customer summery of the LPC2106 requirements : 
 
1. Act as an I2C PROM via the I2C channel.
2. Receive configuration orders from the I2C channel.
3. Read HW configuration via IO pins.
4. Configure an external component using a multiplexed 8 bit data/address bus, should be implemented by GPIO.
5. Drive several HW pins according to configuration (including LEDS).
6. A frequency divider (externally sourced).
 
Open questions :
1. Our clock source is a 25MHZ clock signal. it will not be available immediately with power up but as an output from another component. is this o.k. ? will the wakeup timer handle it?
2. Vector interrupt controller explanation.
3. Timers mechanism explanation.
 
Thanks
Amir Sherman

		
---------------------------------
Discover Yahoo!
 Stay in touch with email, IM, photo sharing & more. Check it out!

[Non-text portions of this message have been removed]

RE: [lpc2000] Processor won't run without JTAG interface

2005-10-16 by Paul Curtis

The checksum?

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors 
Show quoted textHide quoted text
> -----Original Message-----
> From: Robert Wood [mailto:robert.wood@...] 
> Sent: 16 October 2005 18:53
> To: lpc2000@yahoogroups.com
> Subject: [lpc2000] Processor won't run without JTAG interface
> 
> Hi folks,
> 
> I have some code in an LPC2194 which runs fine with the JTAG 
> interface plugged in (using Crossworks if that's relevant). 
> However, if I unplug the wiggler and power cycle the board, 
> it will not run. P0.14 and P1.20 are pulled high, and RTCK is 
> pulled low.
> 
> Are there any common problems with this issue I should look out for?
> 
> Cheers,
> 
> Rob
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> --------------------~--> Fair play? Video games influencing 
> politics. Click and talk back!
> http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/dN_tlB/TM
> --------------------------------------------------------------
> ------~-> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
> 
>

Processor won't run without JTAG interface

2005-10-16 by Robert Wood

Hi folks,

I have some code in an LPC2194 which runs fine with the JTAG interface 
plugged in (using Crossworks if that's relevant). However, if I unplug 
the wiggler and power cycle the board, it will not run. P0.14 and P1.20 
are pulled high, and RTCK is pulled low.

Are there any common problems with this issue I should look out for?

Cheers,

Rob

RE: [lpc2000] Processor won't run without JTAG interface

2005-10-16 by Paul Curtis

Hi Robert, 

>  >> The checksum? <<
> 
> Hmmm, yes. That was it. 

Nothing like online support on a Sunday eveinging...

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

Re: [lpc2000] Processor won't run without JTAG interface

2005-10-16 by Robert Wood

>> The checksum? <<

Hmmm, yes. That was it. I went back to one I'd commented out for some 
reason. I don't understand this checksum business or why it's there. The 
datasheet makes no sense to me.

Anyone know of a website with a LPC2000 checksum for dummies type page?! ;~)

Re[2]: [lpc2000] Processor won't run without JTAG interface

2005-10-16 by rob@usbmicro.com

Robert,

> Anyone know of a website with a LPC2000 checksum for dummies type page?! ;~)

This is what I do.

The vector table for the processor (The first 32 bytes of memory)
normally has branches to the routines. Since routine addresses change
as code is changed, the checksum changes.

I created a table of seven addresses located immediately after the
vector table. These seven addresses are the start addresses for reset
and the interrupts. The branch instructions of the interrupt vector
table were replaced with a load PC instruction pointing to the
appropriate address.

The hex file will then have the checksum. My startup code below:

@---------------------------------------------------------------------------
@ Interrupt vectors
@---------------------------------------------------------------------------
intvect:

        LDR     pc, startaddr
        LDR     pc, undefinstaddr
        LDR     pc, softintaddr
        LDR     pc, preabortaddr
        LDR     pc, dataabortaddr
        .word   0xb8a06f60
        LDR     pc, interruptaddr
        LDR     pc, fastintaddr

startaddr:
        .word   start

undefinstaddr:
        .word   undefined_instruction_routine

softintaddr:
        .word   software_interrupt_routine

preabortaddr:
        .word   prefetch_abort_routine

dataabortaddr:
        .word   data_abort_routine

interruptaddr:
        .word   interrupt_routine

fastintaddr:
        .word   fast_interrupt_routine


@---------------------------------------------------------------------------
@ Start up code
@---------------------------------------------------------------------------

start:

 <code...>



The checksum is done over the first 8 integers (32 bit
integers) of flash memory excluding the area where the checksum is
stored. That is, in the assembly code above, the stuff between the
label "intvect:" and the label "startaddr".

Although the location for start and all of the routines may change as
code is developed, all of those changes happen after the label
"startaddr:" (as resolved by the linker).

The net result is that the first 32 bytes (address 0000 to 001F)
will always contain the same values, and thus the checksum (two's
compliment sum) will also remain the same. The hex file will have
these first two lines: 

:10 0000 00 18F09FE5 18F09FE5 18F09FE5 18F09FE5 C0
:10 0010 00 18F09FE5 606FA0B8 14F09FE5 14F09FE5 1D

(I added spaces to make it easier to understand.)

You can see the ".word   0xb8a06f60" in the hex file which is the
two's compliment sum of the other integers. (Note the byte order is
reversed.) 0xb8a06f60 doesn't need to change, even when the routines
move.

So no need for any external program to do the calculation each time
that the source is compiled.

I anticipate using a loader other than the Philips utility, so I
wanted to resolve the checksum calculation without needing to use the
Philips utility. This way the hex file has the checksum.


-Rob
www.usbmicro.com

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.