The problem is the absence of an interrupt. Instead the SAM7S generates an undocumented reset. If the condition resulted in an interrupt then it could be handled - as you suggest.

And did you try to mask RXRDY and have only ENDRX active? Having both bits set does not make sense at all.

As you have already acknowledged, I fixed the problem days ago.

The issue isn't whether it makes sense or not (clearly, it is at least redundant). The issue is the undocumented behavior and whether there are other interrupt combinations in other SAM7S peripherals that cause hardware-initiated reset. Such behavior is very time consuming to source, because such a reset leaves no prior state or indication of the cause. In other words, there are clearly lines into the RSTC that the hardware designers used when there was a condition they didn't want to handle. I am simply asking whether there is a place where a simple user like myself might gain insight or, at least, be warned.

I have similar problem with AT91SAM7X256. It's getting jump to reset_handler without any other interrupt. There is no any interrup error such as data abort etc... This situation is probably involved when we use Wiznet w5100 chip to communicate over ethernet. W5100 use SPI
interface to communicate with our microcontroller.

I've checked what is reset controller returning in RSTC_SR (0x00010400). This mean controller has been reset by user.
Additionally after this happens core works as well, but all peripherals are hang. After I manually reset microcontroller
by JTAG or unplugging power it's working fine. Any advice?

One thing that has happened to me in the past (though it doesn't appear to be a factor in my current situation with the USART0) was that the code failed to install an interrupt handler at some device ID in the AIC interrupt vector table. The consequence was that when that device initiated an interrupt, and if it jumped through that device's AIC vector, it went to PC=0x00000000 where Startup.s put a jump to Reset_Handler (also in Startup.s). Which of course, made it look like a Reset.

What made the behavior insidious was that if the other interrupts were running frequently enough, and if a 'general purpose' ISR was loaded for all interrupts, the AIC may never have to jump through the errant device driver's ID... until that timing window opened up enough to cause the device's interrupt to be the only one pending.

... Just in case this situation might apply.

A further suggestion would be to set a breakpoint at Startup.s:Reset_Handler, after the application gets to main() for the first time. When the apparent reset hits the break point, check the Program Status Register mode to get an idea of from where you've come. (It'll probably be one of User, IRQ, Abort, etc.) If it's IRQ, take a look at the AIC registers to see what was happening.

Another possibility is a sag in power caused by your external comm chip, in which case you might need to look at the Reset Controller's brown out detect (BOD) state.

FWIW

Sorry for late answer. Thanks for your suggestion I have read value from CPSR register at first intstruction in reset handler. After I run application from debugger CPSR value is 0x000000d3, but after a suspicious restart CPSR value is: 0x400000d2. This means that microcontroller is in IRQ mode. But how to handle what's make that crash?

Edit:

I have checked at stack pointer. I have found value in [sp - 4] which indicate that last intruction is come from aic handler.

Edit2:

After further tests it seems that irq_handler jump to 0x00000000 memory address.



R0 = 0xfffff000
R1 = 0x00000000


How to retrieve irq source?

Edit3:

Another update I have read some data register from AIC.

0xFFFFF100 - Interrupt vector register = 0x00000000
0xFFFFF104 - FIQ Interrupt vector register = 0x00000000
0xFFFFF108 - Interrupt status register = 0x00000000
0xFFFFF10C - Interrupt pending register = 0x00002005
0xFFFFF110 - Interrupt mask register = 0x000020c6

AIC_IPR (Interrupt pending register) have set 3 bits (10000000000101)
This mean that is 3 current pending irq:

AT91C_ID_FIQ (uncorrect, I don't use this irq)
AT91C_ID_PIOA (correct)
AT91C_ID_TC1 (correct)

Maybe this is the point.

Edit4:

Finally I found a solution. The problem was in spurious interrupt. Btw. why this interrupt is not handled by default(jump to 0 address is not good idea). I lost one week to resolve this problem.

One final follow up. It turns out that there is a race condition between disabling interrupts on the AIC:

AT91C_BASE_AIC->AIC_IDCR = 1 << source;

and the AIC checks for an enable source. It is possible to disable interrupts at the beginning of the AIC's interrupt processing cycle such that when it tries to read the AIC_IVR there is no enabled source to provide an IVR value. This generates what they call a "spurious interrupt" and, if you haven't provided a handler in AIC_SPU, it will jump to the default "0x00000000" and probably end up in the Startup.s:ResetHandler()

(See SAM7 'user manual', Section 23.7.6 "Spurious Interrupt", 3rd bullet)

Thanks, very much, to Bob Martin@Atmel for having pointed this out to me!

P.S. I'm hoping the move to SAM3 with it's Cortex-integrated IVR will obviate this problem.