Lpc2000

Hello all,

While trying to get interrupts to work on a LPC2106 in
Flash we came
along some strange kind of problem.

The code starts up, and starts initializing
interrupts.
In the InitInterrupt() routine we set the functions
the interrupt
vector should point to:

irqVector1 = MyTimerInterrupt;
irqVector0 = DataAbortInterrupt;

We designed the function 'DataAbortInterrupt()' so
that it only prints
the text "Data Abort" on the Hyper Terminal.

The problem is that assigning the interrupt vectors
gives us a "Data
Abort" error on the terminal. The compiler CANT KNOW
where the
irqVector0 is pointing to because DataAbortInterrupt
is assigned after
MyTimerInterrupt.

Can anyone tell us what's happening here? And why doe
we get those anoying Data Aborts at this point... It's
really getting us crazy...

This is how the VIC-handling part of the startup.s
looks:

@@@@@@@@@@@
.section .startup,"ax"
.code 32
.align 0

b start
b irqVector0
b irqVector0
b irqVector0
b irqVector0
b irqVector0
b irqVector1
b irqVector1

@@@@@@@@@@@@@@@@

@ create a variable to hold a C function pointer to be
called on IRQ

.global irqVector0
irqVector0:
.word 0 @ this should be set to a C function

.global irqVector1
irqVector1:
.word 0 @ this should be set to a C function

@@@@@@@@@@@@

Thanks,
Joris and Tiemen


		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/

Hello,

it is a very strange way to set interrupt vectors...

1) Are you sure that really a "data abort" occurs? All of your "nasty"
vectors pointing to a data abort ISR including undefined instruction,
prefetch abort and SWI!

2) Have you examined where the "data abort" really occurs? If yes: take
a look into assembly code at this position. Data abort only occurs if
you try to access an invalid address (data operand).

3) Where is your vector table located? In RAM or ROM? Why don't you
assign your vectors in your startup file statically?

Regards
  Sten

Joris Hooijberg wrote:
> Hello all,
> 
> While trying to get interrupts to work on a LPC2106 in
> Flash we came
> along some strange kind of problem.
> 
> The code starts up, and starts initializing
> interrupts.
> In the InitInterrupt() routine we set the functions
> the interrupt
> vector should point to:
> 
> irqVector1 = MyTimerInterrupt;
> irqVector0 = DataAbortInterrupt;
> 
> We designed the function 'DataAbortInterrupt()' so
> that it only prints
> the text "Data Abort" on the Hyper Terminal.
> 
> The problem is that assigning the interrupt vectors
> gives us a "Data
> Abort" error on the terminal. The compiler CANT KNOW
> where the
> irqVector0 is pointing to because DataAbortInterrupt
> is assigned after
> MyTimerInterrupt.
> 
> Can anyone tell us what's happening here? And why doe
> we get those anoying Data Aborts at this point... It's
> really getting us crazy...
> 
> This is how the VIC-handling part of the startup.s
> looks:
> 
> @@@@@@@@@@@
> .section .startup,"ax"
> .code 32
> .align 0
> 
> b start
> b irqVector0
> b irqVector0
> b irqVector0
> b irqVector0
> b irqVector0
> b irqVector1
> b irqVector1
> 
> @@@@@@@@@@@@@@@@
> 
> @ create a variable to hold a C function pointer to be
> called on IRQ
> 
> .global irqVector0
> irqVector0:
> .word 0 @ this should be set to a C function
> 
> .global irqVector1
> irqVector1:
> .word 0 @ this should be set to a C function
> 
> @@@@@@@@@@@@
> 
> Thanks,
> Joris and Tiemen
> 


-- 
/************************************************
 Do you need a tiny and efficient real time
 operating system (RTOS) with a preemtive
 multitasking for LPC2000 or AT91SAM7?

   http://nanortos.net-attack.de/

 Or some open-source tools and code for LPC2000?

   http://www.net-attack.de/

************************************************/

Joris, Tiemen,

indeed a strange way to initialize the interrupts.
I've got the same kind of questions as Sten when looking at this code.
If your looking for startup code, have a look at 
http://www.myvoice.nl/electronics/files/i2c-test.zip - that contains a 
complete application, including startup code.

Main question is why you do your vector initialization like this. There 
is a reason for ARM to give us access to all these seperate vectors.
I would indeed specify seperate functions for all the 'nasty' vectors.

If this code is in Flash, not using the mapping of vectors to RAM (using 
the MEMMAP register)  you will get a data abort due to writing to flash.

Regards,

    Rob

> Can anyone tell us what's happening here? And why doe
> we get those anoying Data Aborts at this point... It's
> really getting us crazy...
>
> This is how the VIC-handling part of the startup.s
> looks:
>
> @@@@@@@@@@@
> .section .startup,"ax"
> .code 32
> .align 0
>
> b start
> b irqVector0
> b irqVector0
> b irqVector0
> b irqVector0
> b irqVector0
> b irqVector1
> b irqVector1
>
> @@@@@@@@@@@@@@@@
>
> @ create a variable to hold a C function pointer to be
> called on IRQ
>
> .global irqVector0
> irqVector0:
> .word 0 @ this should be set to a C function
>
> .global irqVector1
> irqVector1:
> .word 0 @ this should be set to a C function
>
> Thanks,
> Joris and Tiemen

Apart from what others have written about better ways to do this 
(using the AIC), I think there is also a problem in the way you have 
written the assembler code.

Unfortunately one of the Philips app notes is written this way, but it 
is wrong. 
 
> @@@@@@@@@@@
> .section .startup,"ax"
> .code 32
> .align 0
> 
> b start
> b irqVector0
> b irqVector0
> b irqVector0
> b irqVector0
> b irqVector0
> b irqVector1
> b irqVector1
> 
> @@@@@@@@@@@@@@@@
> 
> @ create a variable to hold a C function pointer to be
> called on IRQ
> 
> .global irqVector0
> irqVector0:
> .word 0 @ this should be set to a C function
> 
> .global irqVector1
> irqVector1:
> .word 0 @ this should be set to a C function

  b xxx expects xxx to be actual code, not a "pointer to code"


If you want to use a pointer to code, then you should be doing

  ldr pc,irqVector

That will load the pc with the pointer, essentially a jump to the 
code.

As an example of this, consider the code I use for my vectors which 
looks like:


	    ldr   pc,v0	 	 	@ reset vector
            ldr   pc,v1	  		@ Undefined Instruction
            ldr   pc,v2	 	 	@ Software Interrupt
            ldr   pc,v3	  		@ Prefetch Abort
            ldr   pc,v4		  	@ Data Abort
            ldr   pc,v5		  	@ reserved
	    ldr   pc,[pc,#-0xF20]	@ IRQ : read the AIC
	    ldr   pc,[pc,#-0xF24]	@ FIQ : read the AIC
v0:	    .long start
v1:	    .long undef_handler
v2:         .long swi_handler
v3:         .long prefetch_abort_handler
v4:	    .long data_abort_handler
v5:	    .long reserved_handler

Here the vectors v0..v5 are predefined constants, but they could 
equally well be variable pointers.

--- In lpc2000@yahoogroups.com, Rob Jansen <rob@m...> wrote:

> indeed a strange way to initialize the interrupts.
> I've got the same kind of questions as Sten when looking at this code.

OK, it IS a nasty interrupt table... guilty as charged... 

> If your looking for startup code, have a look at 
> http://www.myvoice.nl/electronics/files/i2c-test.zip

The startup code in here is the same as embeddedjanitor's example.
We changed our startup.s like this:


.section .startup,"ax"
         .code 32
         .align 0
 		
         LDR PC,[PC,#resetHandlerAddress - . - 8]
         LDR PC,[PC,#undefHandlerAddress - . - 8]
         LDR PC,[PC,#swiHandlerAddress - . - 8]
         LDR PC,[PC,#prefetch_abortHandlerAddress - . - 8]
         LDR PC,[PC,#data_abortHandlerAddress - . - 8]
         NOP                                         
         LDR PC,[PC,#irqHandlerAddress - . - 8]      
         LDR PC,[PC,#fiqHandlerAddress - . - 8]     

resetHandlerAddress:
  .word start

[etc etc]

irqHandlerAddress:
  .word MyTimerInterrupt

fiqHandlerAddress:
  .word MyTimerInterrupt
  
  
#
# Reserve memory for exception handlers
#
        #0x00000020
HandleReset:

[etc etc]
        #0x00000034
HandleIRQ:

        #0x00000038
HandleFIQ:
 

Running the code gives us A Prefetch error, but the interrupts are
handled correct.
Is seems that the processor doesn't like it when we change the program
counter... Did we forget something?  
 
Anyay, thanks for the help,

Joris

> Running the code gives us A Prefetch error, but the interrupts are
> handled correct.

where i typed Prefetch i meant Data Abort

sorry about that

Joris

--- In lpc2000@yahoogroups.com, "jorishooijberg" <jorishooijberg@y...>
wrote:
>
> --- In lpc2000@yahoogroups.com, Rob Jansen <rob@m...> wrote:
> 
> > indeed a strange way to initialize the interrupts.
> > I've got the same kind of questions as Sten when looking at this code.
> 
> OK, it IS a nasty interrupt table... guilty as charged... 
> 
> > If your looking for startup code, have a look at 
> > http://www.myvoice.nl/electronics/files/i2c-test.zip
> 
> The startup code in here is the same as embeddedjanitor's example.
> We changed our startup.s like this:
> 
> 
> .section .startup,"ax"
>          .code 32
>          .align 0
>  		
>          LDR PC,[PC,#resetHandlerAddress - . - 8]
>          LDR PC,[PC,#undefHandlerAddress - . - 8]
>          LDR PC,[PC,#swiHandlerAddress - . - 8]
>          LDR PC,[PC,#prefetch_abortHandlerAddress - . - 8]
>          LDR PC,[PC,#data_abortHandlerAddress - . - 8]
>          NOP                                         
>          LDR PC,[PC,#irqHandlerAddress - . - 8]      
>          LDR PC,[PC,#fiqHandlerAddress - . - 8]     
> 
> resetHandlerAddress:
>   .word start
> 
> [etc etc]
> 
> irqHandlerAddress:
>   .word MyTimerInterrupt
> 
> fiqHandlerAddress:
>   .word MyTimerInterrupt
>   
>   
> #
> # Reserve memory for exception handlers
> #
>         #0x00000020
> HandleReset:
> 
> [etc etc]
>         #0x00000034
> HandleIRQ:
> 
>         #0x00000038
> HandleFIQ:
>  
> 
> Running the code gives us A Prefetch error, but the interrupts are
> handled correct.
> Is seems that the processor doesn't like it when we change the program
> counter... Did we forget something?  
>  
> Anyay, thanks for the help,
> 
> Joris
>

Hello Joris,

This is a very complicated way to modify the PC. But this immediate
displacment relative to the PC will only work under certain
circumstances. It is quite dangerous! And the data abort vector is
found correctly? Are you sure?
Do you know at which address this error occur? Just check the link
register R14 and see your assembly code what happens.

  Sten

Hi,

I have got the CS8900A talking to the LPC2106 in 8bit
mode. Strange things are happening

Without any delay (without additional delay added in
code) in the Rd & Wr cycles, repeated reads result in
random values.
Then I added delay to stretch the RD_low

RD_low
delay
Read_Data
RD_hi

With this I get consistent reads, but the bytes seem
to be swapped.

For instance, when read 0 (ProductID), read from Data0
== 0x63 & Data1 == 0x0e
yields 0x0e63, but it should have been 0x630e

Similarly I get 0xd000 when I read SelfST. With
different delay values I get 0x0000 for SelfST or
0x6363 for ProdID.

Can someone let me know what delays are required &
where, it will be great!

Thanks a lot,
-Mike.


		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/

I had similar experiences with GPIO and the external memory controller 
on a LPC2292. I found out that in this case, it is possible for a read 
to start on the external memory controller before a write to the GPIO is 
finished. Don't know if this is the same problem because you are only 
using GPIO, maybe you are using both port0 and port1???

Try writing the RD_low twice, that way the first write must be finished 
before the second can begin, the second write does not change anything, 
so the read is occuring when the outputs are in the right state.

Richard Duits


Michael Anburaj wrote:

> Hi,
>
> I have got the CS8900A talking to the LPC2106 in 8bit
> mode. Strange things are happening
>
> Without any delay (without additional delay added in
> code) in the Rd & Wr cycles, repeated reads result in
> random values.
> Then I added delay to stretch the RD_low
>
> RD_low
> delay
> Read_Data
> RD_hi
>
> With this I get consistent reads, but the bytes seem
> to be swapped.
>
> For instance, when read 0 (ProductID), read from Data0
> == 0x63 & Data1 == 0x0e
> yields 0x0e63, but it should have been 0x630e
>
> Similarly I get 0xd000 when I read SelfST. With
> different delay values I get 0x0000 for SelfST or
> 0x6363 for ProdID.
>
> Can someone let me know what delays are required &
> where, it will be great!
>
> Thanks a lot,
> -Mike.
>
>
>            
> __________________________________
> Yahoo! Music Unlimited
> Access over 1 million songs. Try it free.
> http://music.yahoo.com/unlimited/
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>