Trying to debug a weird reset issue on MSP430F2274

[stube40 0]

I'm trying to debug a weird issue by where my firmware resets itself - that is, it returns to the first line of assembler code labelled 'cstart_begin' in the disassembly.

 

If I put a breakpoint on the line of assembler code previous to cstart_begin, it never fires - hence it must be jumping to here.

 

To shed a bit more light on this, I have my own custom hardware PCB with a few chips hanging off the I2C bus. These I2C chips have a power rail which can be switched on/off via a MOSFET controlled by a single bit on PORT3 of the CPU. It's when I'm switching the I2C rail ON that the resets happen. Not every single time, just sometimes.

 

It's weird and I suspected a power surge issue, but I've tried various different PSUs and hence I'm pretty confident there is enough power. Although, I haven't yet scoped it to see if there is a spike.

 

However, the firmware behaviour seems weird. Why does it jump to cstart_begin? What makes it jump? Can anyone shed more light on this?

 

Thanks,

Stuart.

[oPossum 1,083]

Bypass caps would be my #1 suspect. They must be close to the chip, proper value and type.

 

Unhandled interrupts can also cause this behavior.

 

Post your schematic and PCB picture if you can.

[SugarAddict 227]

What pullup resistor do you have on the reset? (pin 7 DA, 5 RHA)... Is your Vcc to that resistor fluctuating during the transition?

[stube40 0]

@oPossum - this forum wont let me post off-site URLs yet as I'm a new user (spam protection). I tried to add my circuit diagram and PCB but it wouldn't let me post the links to the pictures on photobucket, hence I will describe it for now (ban should be lifted soon). C20 and C21 are right next to the chip. They are 100nFs. This is all I have. Is this sufficient, or does it need additional caps?

 

I will look into unhandled interrupt vectors and report back.

 

@Sugar Addict - I use pin 5 as TDIO which plugs straight into the 6-pin connector on the USB debugger of the evaluation kit (the pin-out of my 6-pin CONN2 is a one-to-one with the evaluation kit). I have a 47k with 100nF de-coupling cap to ground on this. Is this completely wrong? Should I be using a pull-up instead?

[SugarAddict 227]

47k pullup, no decoupling cap.

 

See SLAA276A page 29 for an example.

[stube40 0]

OK, I modded the board to that the reset-line (pin 5) is now pulled up via 47k. Unfortunately this didn't help the problem I'm currently having.

 

I put a scope on Vcc and found that it is dropping to 2.5V when I switch the I2C rail on (ie when the reset problem happens). I haven't found the part in the data sheet which tells you how low Vcc can go, but I'm thinking it must be at least 2.2V. Hence, could this be a brown-out issue?

 

Also, I declared traps for all unhandled interrupt vectors in case it was something to do with this, but I had issues compiling the reset vector. When I compiled the following in IAR I got the linker error:

 

#pragma vector = RESET_VECTOR

__interrupt void RESET_ISR(void)

{

while(1);

}

 

Error[e16]: Segment RESET (size: 0x2 align: 0x1) is too long for segment definition. At least 0x2 more bytes needed. The problem occurred while processing the segment placement command "-Z(CODE)RESET=FFFE-FFFF", where at the moment of placement the available memory ranges were "-none-"

Reserved ranges relevant to this placement:

ffe0-ffff INTVEC

 

I don't get it - it needs two bytes and it's got them, so why can't it compile?

[SugarAddict 227]

http://old.nabble.com/Reg:MSP430-RESET_ ... 82052.html

 

Can't handle that interrupt in C code, but you can switch to an assembly project and be able to.

 

I would think you could put a cap on your Vcc coming in to handle that voltage drop... My skills end there with the basics

[nobody 47]

I put a scope on Vcc and found that it is dropping to 2.5V when I switch the I2C rail on (ie when the reset problem happens). I haven't found the part in the data sheet which tells you how low Vcc can go, but I'm thinking it must be at least 2.2V. Hence, could this be a brown-out issue?

BOR (Brownout Reset) specification is at page 33 in slas504f.pdf. Specially look at part of sentence (2) - minimum voltage depends on the frequency. This dependence can be found on page 26.

 

Your first task should be to improve the power supply to eliminate voltage drops. (First, add more capacitors. If it does not work to divide the power into two separate parts. Separate stabilizer for CPU and one for peripherals. Use stabilizer with shutdown input (something like LP2951-33D) and you do not need use a switching transistor in the power bus).

 

Also: Remove the large capacitors in the switched part of the power bus. Their charge in turn causes a drop in supply voltage. It helps to add a small resistor (eg 10 to 100 Ohm) in series with the switching transistor.

[bluehash 1,581]

@oPossum - this forum wont let me post off-site URLs yet as I'm a new user (spam protection).

Hi stube40, just make 2 dummy posts... and you should be good. Welcome to the forums.

[stube40 0]

@nobody - I hadn't spotted the voltage/frequency dependence you pointed out on page 26. Thanks for that!! If I am reading it correctly though, it suggests that I can't drop much below 3.3V at my configured speed of 16MHz. Is that really true, or am I mis-understanding it?

 

I loved your suggestion about removing caps on the switched part of the power bus - surprise, surprise, I have a 10uF right next to the switching FET (on the switched side of the I2C bus). I might temporarily remove this and see what difference it makes.