2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

Hi all,

I wanted to confirm the following operation of the LPC2124 on bootup.

1. The current Philips LPC2124 bootloader is Philips proprietary
- Please confirm

2. Bootloader operation
- Can you please confirm my interpretation of the power on reset and
bootloader action (This is what I have interpreted from the LPC2124
User Manual)

-Bootloader lives in the highest part of flash memory (8k size)
-On Reset.... The bootloader is remapped to the top of a 2Gbyte boundary
-64 bytes of the bootloader vectors are mapped in to 0x00000000 to
0x0000003f (the original interupt vectors).
-The bootloader is always mapped in to the same location (top of
2Gbyte) so, execution of bootloader address is always fixed.
-LPC2124 executes the first instruction at 0x00000000 jumps to a
fixed address in the remapped 8k bootloader at the top of 2Gbyte.
-bootloader code executes and looks for a low on P0.14.
. ..... etc.... then follow the bootloader flow charts in the user
manuals.

3. Please confirm the bootloader s/w checks the status of P0.14 and is
not a fixed as a hardware test.
Does my executive summary of the start up of the boot loader seem
feasable?
Thanks.

Joe G

=20

=20

=20


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hey,

1. yes, the bootloader is proprietary
2. everything happens exactly the way you describe it.
3. yes, reading P0.14 is done in software.

Regards,

Dominic

On Tuesday 23 May 2006 16:09, phlpcmicro wrote:
> Hi all,
>
> I wanted to confirm the following operation of the LPC2124 on bootup.
>
> 1. The current Philips LPC2124 bootloader is Philips proprietary
> - Please confirm
>
> 2. Bootloader operation
> - Can you please confirm my interpretation of the power on reset and
> bootloader action (This is what I have interpreted from the LPC2124
> User Manual)
>
> -Bootloader lives in the highest part of flash memory (8k size)
> -On Reset.... The bootloader is remapped to the top of a 2Gbyte boundary
> -64 bytes of the bootloader vectors are mapped in to 0x00000000 to
> 0x0000003f (the original interupt vectors).
> -The bootloader is always mapped in to the same location (top of
> 2Gbyte) so, execution of bootloader address is always fixed.
> -LPC2124 executes the first instruction at 0x00000000 jumps to a
> fixed address in the remapped 8k bootloader at the top of 2Gbyte.
> -bootloader code executes and looks for a low on P0.14.
> . ..... etc.... then follow the bootloader flow charts in the user
> manuals.
>
> 3. Please confirm the bootloader s/w checks the status of P0.14 and is
> not a fixed as a hardware test.
> Does my executive summary of the start up of the boot loader seem
> feasable?
> Thanks.
>
> Joe G
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Just a quick question to see if there's anyway of using the inbuilt timer
functionality of a LPC2119 as a counter. Ie to count the number pulses
(rising or falling edge) from an external source over a given time frame.
Basically we have a pot that changes a source input frequency from 36khz to
around 48khz and driving an IRQ for each pulse doesn't strike me as being a
good idea. All I need to realistically know is roughly what frequency it's
being driven at.

Ideas?

Andy





(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi,

If your processor clock speed is reasonably fast (e.g. 60 Mhz),
you'd see little impact on performance if you configure an FIQ
interrupt to increment a single counter whenever the rising or
falling edge happens.

By pre-loading the banked ragisters before you start (e.g. with the
address of the counter etc.), you'd probably get the code down to
less than about six assembler instructions in total, and you
probably wouldn't even have to save any context. Even with the
standard interrupt latency, you'd almost certainly be less than
about 30 cycles on average (being generous).

At 48KHz interrupt rate and a clock of 60 Mhz, you have 1250 cycles
to play with: 30 of these to handle the interrupt, or 2.4% of the
available CPU.

A much slower timer interrupt could periodically read (and reset)
the counter to calculate the frequency.

Although it's not particularly "clever" (being something of a
sledgehammer) it would work, and has the virtue of simplicity.

We've used 40 Khz interrupts and an interpolating filter to output
an 8KHz sampled data (to reduce noise), and it works very well.

Regards
Brendan
--- In l...@yahoogroups.com, "Andrew Berney" wrote:
> Just a quick question to see if there's anyway of using the
inbuilt timer
> functionality of a LPC2119 as a counter. Ie to count the number
pulses
> (rising or falling edge) from an external source over a given time
frame.
> Basically we have a pot that changes a source input frequency from
36khz to
> around 48khz and driving an IRQ for each pulse doesn't strike me
as being a
> good idea. All I need to realistically know is roughly what
frequency it's
> being driven at.
>
> Ideas?
>
> Andy
>





(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )