Forums

"Random" resets - Olimex P2138 dev board - RSIR Indicates brown out?

Started by Darcy Williams January 30, 2007
Hi, I'm using the Olimex P2138 development board with a 500mA
regulated power pack. I have an EEROM (Microchip 24LC256) also using
the dev boards power supply - but this shouldn't be causing this problem.

Anyway, the reset seems to be happening all over the show... Upon
code being downloaded and within milliseconds of being executed,
through to running for minutes on end then resetting.

I'm using Rowley CrossStudio - if that makes any difference. I find I
end up in the reset_wait section of startup.s. Not a problem at the
moment since it's a good place to look at the registers from.

Upon finding the PC there, RSIR/RSID = 0x00001011
>From the documentation - this value should not be possible upon reset
(i.e. EXTR and BODR shouldn't be set at the same time - this would
indicate an external reset AND a brown out detect)

I've just had a look, and PCON is set to 0x00 - by the looks BOD isn't
enabled in this state.

The watchdog is not running.

I'm not writing/erasing any on-chip flash - anywhere.

I switched to a different plug pack with the same specs (different
brand/model) and I still have the problem.

Has anyone bumped in to this issue before? I find it really hard to
believe that I'm actually suffering from a BOD here - and suspect
something else is happening that I just can't see.

Any help would be appreciated!

Cheers
Darcy

An Engineer's Guide to the LPC2100 Series

> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of Darcy Williams
> Sent: Tuesday, January 30, 2007 5:45 PM
> To: l...
> Subject: [lpc2000] "Random" resets - Olimex P2138 dev board - RSIR
> Indicates brown out?
> Hi, I'm using the Olimex P2138 development board with a 500mA
> regulated power pack. I have an EEROM (Microchip 24LC256) also using
> the dev boards power supply - but this shouldn't be causing
> this problem.
>
> Anyway, the reset seems to be happening all over the show... Upon
> code being downloaded and within milliseconds of being executed,
> through to running for minutes on end then resetting.
>
> I'm using Rowley CrossStudio - if that makes any difference. I find I
> end up in the reset_wait section of startup.s. Not a problem at the
> moment since it's a good place to look at the registers from.
>
> Upon finding the PC there, RSIR/RSID = 0x00001011
> From the documentation - this value should not be possible upon reset
> (i.e. EXTR and BODR shouldn't be set at the same time - this would
> indicate an external reset AND a brown out detect)
>
> I've just had a look, and PCON is set to 0x00 - by the looks BOD isn't
> enabled in this state.
>
> The watchdog is not running.
>
> I'm not writing/erasing any on-chip flash - anywhere.
>
> I switched to a different plug pack with the same specs (different
> brand/model) and I still have the problem.
>
> Has anyone bumped in to this issue before? I find it really hard to
> believe that I'm actually suffering from a BOD here - and suspect
> something else is happening that I just can't see.
>
> Any help would be appreciated!
>
> Cheers
> Darcy
>

Any chance of a data abort taking you back to reset? How do you have
all of your exception vectors set up?

Mike
--- In l..., "Michael Anton" wrote:
>
> Any chance of a data abort taking you back to reset? How do you have
> all of your exception vectors set up?
>
> Mike

Hi Mike, good suggestion for most cases... CrossWorks has a nice
setup whereby data aborts have a separate catch vector. I've ended up
there on a few occasions after calling badly initialised function
pointers.

Optimisation is off
ARM instructions only (No Thumb interworking)
All unconfigured interrupt vectors jump off to a catch vector
Interrupts cannot be interrupted

At the time of the reset, the only interrupts that should be occurring
are UART, Timer 0, maybe I2C

I'm disabling the UART interrupt when loading bytes into the UART
transmit register but I wouldn't have thought this should be a problem.

Could this be a problem with the whole pipelined instruction vs
interrupt issue? I was attempting to avoid that with the disable
macro below.
#define VIC_BIT(chan) (1 << (chan))

#define VIC_INT_DISABLE( chan ) do{ VICIntEnClr = VIC_BIT( chan );
\ __asm("NOP"); \ __asm("NOP"); \
__asm("NOP"); \
}while(0)