I have been seeing a periodic spontaneous jump to the Startup.s:ResetHandler(PC==0x00100058) when performing a lot of I/O via USART0. Recently, with completely different firmware I can reproduce it at will.

Briefly, the firmware sets up a Peripheral DMA Channel(PDC) on USART0 to receive a 8,368 byte file. The firmware is run until main() gets to a busy-wait loop looking for a USART0 interrupt handler to set a flag. I then set breakpoints at the Advanced Interrupt Controller’s(AIC) USART0 vector (interrupt handler) and at the Startup.s:ResetHandler.

The file transfer is initiated from a terminal emulator and the next thing I see is a tripping of the breakpoint at the ResetHandler. No interrupts have been scheduled and the PDC has transferred all the 8,368 bytes. Using a pair of smaller 256-byte PDC buffers, the AIC shows an interrupt pending and the USART0 PDC has completed filling both of the buffers.

So the questions I need to ask are:
1) What are the conditions on which the SAM7S will ‘reset’? Note that the chip's peripherals' state appears to be intact just after the reset occurs (i.e. at PC==0x00100058).
2) Do you have any suggestions as to where to investigate or hook up an oscilloscope?
3) Is there state I can examine on a reset to determine the cause?

Help!
-chas-

P.S. We’re using the Keil MDK µVision V4.5 and their ULINK-ME. The NRST pin is pulled high.

Hi!
1) Increase the user stack
2) Add some padding at the end of your buffer - just in case
3) Check the stability of the VDDCORE voltage
4) Check the stability of the supply voltage

Let us know about the progress

What is your clock and the number of read waiting cycles?

I'm afraid I'm going to show my ignorance here.... By 'clock' I assume you're asking about the setting of the US0_MR:USCLKS which is set to MCK (48MHz). (US0_MR == 0x000008C2) I don't understand "read waiting cycles" in the context of USART0.

Do you use Keil?

... if so, you can check the attached file. Check your settings against mine.

Could you paste your code as well ?

Thanks, for your valuable time, Przemyslaw.

I did the 1st two suggestions:
1) Increase the user stack
UND_Stack_Size EQU 0x00000000
SVC_Stack_Size EQU 0x00000008
ABT_Stack_Size EQU 0x00000000
FIQ_Stack_Size EQU 0x00000000
IRQ_Stack_Size EQU 0x00000200
USR_Stack_Size EQU 0x00000F00
ISR_Stack_Size EQU (UND_Stack_Size + SVC_Stack_Size + ABT_Stack_Size + \
FIQ_Stack_Size + IRQ_Stack_Size)
Heap_Size EQU 0x00000100
2) Add some padding at the end of your buffer - just in case
I added an additional buffer's worth of space. The linker *.map suggests there should be plenty of buffer space.

... but no change in behavior.

I checked the flash read/write wait states - they are the same as depicted in the jpeg you attached. The WDT is disabled.
I also disabled the RSTC's URSTEN. AT91C_BASE_RSTC->RSTC_RMR = 0xA5000400; And AT91C_BASE_RSTC->RSTC_CR == 0x0

The µVision Perihperal->RSTC->RSTTYP shows as "Software RST" which is curious because I don't see any opportunity for the processor to execute at the time the USART0 PDC is active; main() is in a busy-wait and no interrupt vector, that I know of, has been executed except the spontaneous jump to ResetHandler. (See screen shot of RSTC state at the point of the spontaneous reset; i.e. @ResetHandler )

As to the code, I'll see if I can clean it up a little. Do you want (or not want..) the whole Keil project. It also outputs over USART0, w/o use of the PDC. At the time of the reset no USART0 Tx is being processed. FWIW.

Attached (I hope) are:
startup.s - the prerequisite assembler
us0.c - USART0 driver
System_int.c - unified interrupt setup

Hope the code is comprehendable...

Hm. Don't see any evidence that the files have been uploaded... Maybe a Firefox vs Explorer limitation. Neither was I able to find the code your earlier message suggested you attached.

Hi!
You need to rar or zip the files and then upload, because the forum disallows to attach other files

Did you try not to set up the interrupt for USART? I mean, leave the AIC registers intact

Interesting suggestion, Przemyslaw. It hadn't occurred to me. It turns out that without the interrupt set up of the AIC and US0, things run without resetting. Hm.

So, what's the next step? I suppose I better get the code to you (thanks for the tip on the .rar or .zip requirement). But in the meantime, can you tell me under what conditions the SAM7S will reset when the AIC is 'mis-configured' - or more to the point, how does one know where to look? (Particularly, when the PIT interrupt is running just fine in the same 'universal' interrupt handler.)

You are indeed ingenious, Przemek! Turns out that the AIC/USART0 don't like having both ENDRX & RXRDY set in the US0_IMR.

Given the amount of time it has taken us to figure this out, I'd like to learn where I might have found this information.

Could Atmel advise us where we might have found some verbiage to the effect "CAUTION: When using the USART PDC, setting US_IMR:RXRDY in addition to US_IMR:US_ENDRX can result in Software Reset!"? Or even "Some combinations of interrupt mask bits can cause the SAM7 to perform a software reset."

Hi!
Sorry, I was away for a few days. It's good you arrived at the solution. Did you check the errata for any traces of this strange behavior?

Hi!
I think the answer is in the so-called spurious interrupt which needs to be handled.