Vectored IRQ problems in RAM_MODE with LPC2378

 Vectored IRQ problems in RAM_MODE with LPC2378

Using the MCB2300 board, I am working with the UART1 interrupt mode.
Using a sample program in flash, everything works correctly, but when trying to run the same program at RAM_MODE, I had the following problems:
First LPC2300.S changed so called correctly from RAM Vic Vector Address:

                LDR     PC, IRQ_Addr
;               LDR     PC, [PC, #-0x0120]     ; Vector from VicVectAddr
                LDR     PC, FIQ_Addr

Reset_Addr      DCD     Reset_Handler
Undef_Addr      DCD     Undef_Handler
SWI_Addr        DCD     SWI_Handler
PAbt_Addr       DCD     PAbt_Handler
DAbt_Addr       DCD     DAbt_Handler
                DCD     0                      ; Reserved Address
IRQ_Addr        DCD     IRQ_Handler
FIQ_Addr        DCD     FIQ_Handler
VIC_Addr        DCD     0xFFFFFF00

Undef_Handler   B       Undef_Handler
SWI_Handler     B       SWI_Handler
PAbt_Handler    B       PAbt_Handler
DAbt_Handler    B       DAbt_Handler
IRQ_Handler     LDR     R5,VIC_Addr
                LDR     PC,[R5]
FIQ_Handler     B       FIQ_Handler

Despite this, and although called correctly IRQ routine, the return is not working properly, to the point of interruption once.
In the program in flash, everything works correctly, but RAM_MODE not load the return address in R14 (LR).

Has anyone had a similar problem or know because this happens?

 RE: Vectored IRQ problems in RAM_MODE with LPC2378

(I don't know much about this.)

I guess the below is your IRQ_Handler.

IRQ_Handler     LDR     R5,VIC_Addr
                LDR     PC,[R5]

As per
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0210c/CIHBJIIF.html

2.8.5. Interrupt request

The Interrupt Request (IRQ) exception is a normal interrupt caused by a LOW level on the nIRQ input. IRQ has a lower priority than FIQ, and is masked on entry to an FIQ sequence. As with the nFIQ input, nIRQ passes into the core through a synchronizer.

Irrespective of whether exception entry is from ARM state or Thumb state, an IRQ handler returns from the interrupt by executing:

SUBS PC,R14_irq,#4

 RE: Vectored IRQ problems in RAM_MODE with LPC2378

After some checks and tests, now I know that KEIL already does these for programmers.

Sorry for my mistake.

 RE: Vectored IRQ problems in RAM_MODE with LPC2378

Sorry but I do not understand the commentary.

 RE: Vectored IRQ problems in RAM_MODE with LPC2378

Thank you for your help,

but the problem is that when the program run in flash, the return from de interruption rutine is OK because R14 have the return address OK. In RAM_MODE R14 have a value like 0x000015C when the program jump to the interruption rutine.

 RE: Vectored IRQ problems in RAM_MODE with LPC2378

(I don't know much about this.)

Since you were doing "Debug in RAM", I guess you did a Memory re-mapping.

And though what you use is a MCB2300, not a ATMEL MCU, but maybe, you encounter some Debugger problems.

"When the remapping is done before ULINK can stop the device, you will see swapped memory areas in the debugger and the CPU may not behave correctly."

Please take a look for the below URL:
http://www.keil.com/support/docs/2963.htm

 RE: Vectored IRQ problems in RAM_MODE with LPC2378

When testing programs in RAM (by modifing the PC), the device may still execute existing code in the on-chip Flash ROM. Therefore it is important that you erase the Flash or program an endless loop into the on-chip Flash ROM.

http://www.keil.com/support/docs/2767.htm

 RE: Vectored IRQ problems in RAM_MODE with LPC2378

I've done what you say, but I'm the problem, even now with remap and RAM_MODE or jump to interrupt routine, which by the way I use the UART1.
On the other hand, do I have to execute the change on the next LPC2300.s line when work in RAM_MODE?

LDR     PC, [PC, #-0x0120]     ; Vector from VicVectAddr

For what reason don't work the IRQ in RAM_MODE?

 RE: Vectored IRQ problems in RAM_MODE with LPC2378

After various tests, I checked what the error. The variables REMAP and RAM_MODE were in tab C/C++ and not in the ASSEMBLER. I thought that by implementing the program in C was where the variables should be for remapping.

Thank you very much for you help.