LPC2364 Reseting Randomly

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC2364 Reseting Randomly

448 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ABR15 on Wed Jul 01 10:48:01 MST 2015
Hi all. I have a case where the LPC2364 is reseting, but there isn't a visual reason for this, like an input event or communication event, and the time between the resets is about 3 or 4 days... so it's complicated to see this failure.

So I've found in the user manual the RSIR register, that shows 4 reasons for the microcontroller reset (Powerup, WatchDog, Brownout and ExternalReset) and I've implemented a flash write for this register for me to see the reason and works fine.

Is there another way for to investigate the reason? I've tried to get the PC value for write in the flash too but I couldn't..
Labels (1)
0 Kudos
4 Replies

356 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ABR15 on Thu Jul 16 03:54:49 MST 2015

Quote: dunno..


Sounds like you dont clear the source of the interrupt, so it gets fired right again after you ack it in the vic.

some ints have to be cleared accessing some register in the peripheral.. i dont know your controller, though, so check the datasheet about how to reset interrupts in the uart...



Thank you for answer. You are right, but I already read the register that clear the interrupt. The fact is that this problem occurs rarely, so I think that there isn't a firmware problem.
0 Kudos

356 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by dunno.. on Wed Jul 15 04:54:02 MST 2015

Quote: ABR15

But, why does the firmware remain at this interrupt for ever, even clear the VICADDRESS ? I found an application note AN10414 about supirous interrupt and report about RDA UART interrupt, but is for UART0/1.



Sounds like you dont clear the source of the interrupt, so it gets fired right again after you ack it in the vic.

some ints have to be cleared accessing some register in the peripheral.. i dont know your controller, though, so check the datasheet about how to reset interrupts in the uart...
0 Kudos

356 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ABR15 on Wed Jul 15 04:02:06 MST 2015
Thanks for answer dunno!

Yes, I'm using about 7 types of interrupts. My interrupts remains enabled after the start up.

I could find the problem! I'm working with LIN communication and there is a break method where you change the baud rate to simulate a end of message. When I write U2DLL register, to change the baud rate, immediately occurs RX interrupt in the uart2 (LIN) and remains here forever. In the end of this interruption I clean the VICADDRESS for acknowledge, but the next step is the same interruption again, so the watchdog resets.

The solution was disable the RX interrupt when I change the baud rate.

But, why does the firmware remain at this interrupt for ever, even clear the VICADDRESS ? I found an application note AN10414 about supirous interrupt and report about RDA UART interrupt, but is for UART0/1.


0 Kudos

356 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by dunno.. on Wed Jul 15 02:16:56 MST 2015
are you using interrupts?
do you disable interrupts on the run, or even change isr handlers in the vic on the fly?

->
i had the same problem as you, it looked like a restart, but in fact, it was only a spurious interrupt with jump to the default handler, which is simply starting to execute at line0..

read the datasheet, search for spurious interrupts, make sure VICDefVectAddr is provided with an actual handler that acks the int and returns..

also make sure to guard your changes to the vic on the fly by disabling global interrupts, these accesses are not interruptsave, either.

to track this one down, do some debug prints or breakpoint in the VICDefVectAddr handler.
0 Kudos