Lpc2000

Charles Manning wrote:

>On Wednesday 09 November 2005 11:13, Guillermo Prandi wrote:
>  
>
>>Just an idea: perhaps interrupt routines are not saving/restoring all
>>the registers correctly?
>>    
>>
>
>That would be my first though too.
>
>Either that or a stack corruption causing the register to be nuked, but that 
>would probably be less likely.
>
>Is 40000241H within the RAM address space? If not, what does it correspond to?
>
>If you can figure out how R1 got to have this value you're well on your way to 
>solving the problem.
>
>
>
>  
>

I had that, I grapped some project source of an example program and used 
that as the foundation for my project. I got bit by an "__attribute__ 
((naked))" definition of an ISR handler.

TomW

>  
>
>>Guille
>>
>>--- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...> wrote:
>>    
>>
>>>--- In lpc2000@yahoogroups.com, Charles Manning <manningc2@a...>
>>>      
>>>
>>wrote:
>>    
>>
>>>>On Tuesday 08 November 2005 14:40, Tom Walsh wrote:
>>>>        
>>>>
>>>>>ee_gary wrote:
>>>>>          
>>>>>
>>>>>>Hello,
>>>>>>
>>>>>>I'm having a problem where my code goes into the bushes after
>>>>>>            
>>>>>>
>>~10
>>
>>    
>>
>>>>>>seconds.  Running it in the simulator results in a "Non-aligned
>>>>>>Access" error, ARM Instruction at 00000200H, Memory Access at
>>>>>>40000241H.  Any idea what that means?  Simple code, just an
>>>>>>            
>>>>>>
>>interrupt
>>
>>    
>>
>>>>>>driven timer and interrupt driven SPI\ufffd
>>>>>>            
>>>>>>
>>>>What instruction was this accessing?
>>>>        
>>>>
>>>The instruction at 200H was:
>>>LDR R3,[R1]
>>>
>>>It was part of this function:
>>>void wait (void)  {
>>>  unsigned long i;
>>>
>>>  i = timeval;
>>>  while ((i + 10) != timeval);
>>>}
>>>
>>>where 'timeval' is incremented by an ISR.
>>>
>>>      
>>>
>>>>The following things can give you non-aligned accesses:
>>>>
>>>>1) Trying to read a U32 on a non-4-byte boundary or a U16 on a
>>>>        
>>>>
>>>non-2byte
>>>
>>>      
>>>
>>>>boundary. This might raise a data abort.
>>>>
>>>>2) Trying to execute an ARM instruction at a non-4-byte location
>>>>        
>>>>
>>or
>>
>>    
>>
>>>a thumb
>>>
>>>      
>>>
>>>>instruction at a non-2-byte location. This might raise a prefetch
>>>>        
>>>>
>>abort.
>>
>>    
>>
>>>>>You can run into this when mixing Thumb with ARM code. When
>>>>>          
>>>>>
>>interrupt
>>
>>    
>>
>>>>>routines are entered, the processor is in ARM mode, either
>>>>>          
>>>>>
>>write your
>>
>>    
>>
>>>>>handlers in ARM or switch to THUMB mode, process the interrupt,
>>>>>          
>>>>>
>>then
>>
>>    
>>
>>>>>exit THUMB mode and return from interrupt.
>>>>>          
>>>>>
>>>>Yes, this is possible since thumb addresses are marked by setting
>>>>        
>>>>
>>>the least
>>>
>>>      
>>>
>>>>significant bit.  If you try executing the address by using a
>>>>        
>>>>
>>>regular branch
>>>
>>>      
>>>
>>>>or bl then this will break. You need to use a bx.
>>>>
>>>>        
>>>>
>>>>>FWIW, Thumb, and thumb-internetworking, is too much trouble to
>>>>>          
>>>>>
>>deal
>>
>>    
>>
>>>>>with, I run strictly ARM mode.
>>>>>          
>>>>>
>>>>To each their own, but I strongly disagree. I use thumb and
>>>>        
>>>>
>>>interworking a
>>>
>>>      
>>>
>>>>lot. gcc support for this is great.
>>>>
>>>>I always write all my assembly with interworking (ie using bx)
>>>>        
>>>>
>>>regardless.
>>>
>>>I'm using all ARM code, with the interworking option enabled in the
>>>compiler/linker.
>>>
>>>      
>>>
>>>>For an example you might look at the example stuff I posted on the
>>>>        
>>>>
>>>AT91SAM7
>>>
>>>      
>>>
>>>>group.
>>>>        
>>>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>    
>>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------