> If ACLK is not settled, (don't know why that
would be true), the
> code can run off the end and start smashing the BCSCTL1 register.
> See the 'Setting the DCO...' http://lakeweb.net/MSP430/
Good point, my set_DCO() was indeed wrong as mentioned on that website.
It's right, usually this would not be a problem as the code doesn't
get
there, but as long as ACLK is not yet ready, you never know...
Nevertheless, it didn't solve my problem (maybe part of it).
while (1){
while (!(CCIFG & CCTL2)); // Wait until capture occured
CCTL2 &= ~CCIFG; // Capture occured, clear flag
Compare = CCR2; // Get current captured SMCLK
Compare = Compare - Oldcapture; // SMCLK difference
Oldcapture = CCR2; // Save current captured SMCLK
if (DELTA == Compare) break; // If equal, leave "while(1)"
else if (DELTA < Compare){ // DCO is too fast, slow it down
DCOCTL--;
if (DCOCTL == 0xFF){
if (BCSCTL1 & 0x07) // only decrease if not already at 0x00
BCSCTL1--; // Did DCO roll under?, Sel lower RSEL
}
}
else{
DCOCTL++;
if (DCOCTL == 0x00){
if (!(BCSCTL1 & 0x07 == 0x07)) // only increase if not already
// at 0x07
BCSCTL1++; // Did DCO roll over? Sel higher RSEL
}
}
}
CCTL2 = 0; // Stop CCR2
TACTL = 0; // Stop Timer_A
}
Stefan,
Sice your description points to a voltage source problem, please tell us what
your power source is. dVcc/dt might also be important.
Also, try to figure if the problem arrises on cold starts, power recycling (<1s,
~10s, >30s) and/or reseting the device.
You can also try using a much longer delay, like for about 1s. Again this
depends on your type of power supply.
Did you check the chapter "connection of unused pins"?
In my experience, when a circuit works with the JTAG dongle but has problems
without it, it's usually either because some of the JTAG/TEST/RESET signals
have not been properly terminated or because of the power supply.
Power supply problems ar too low a dV/dt (like with capacitive power suppies) or
it is incapable of supplying the peak currents needed. The latter usually hapens
on a reset/quick power recycle, because another device on the same or previous
Vcc rail is stuck consuming its peak power because the MSP was prevented from
shutting down the device. (for example an RF chip that stayed in active RX or
TX, when usually the uC turns it on for short periods).
Hope it helps.
Michael K.
--- In m..., "old_cow_yellow" wrote: >
> As a test, you could try to use a much lower DCO frequency and see if the
problem persists. Change DCO as early as you can, do it in c-startup if
possible.
>
> --- In m..., Stefan Gysel wrote:
> >
> > > Questions:
> > > What compiler are you using? What's the optimization level?
> >
> > I'm using IAR with optimization level set to 'none'.
> >
> > > Are you sure the delay routine is being executed?
> > > Have you looked at the disassembly code?
> >
> > Yes, I can see the delay on the scope. Also single stepping in debug
> > mode works as expected. There is nothing suspicious in the disassembly
> > code.
> >
> > The fact that the code works in most of the cases make me think the
> > problem lies more in hardware (power on sequence) than in software.
> > Unfortunately I cannot replicate the faulty behavior while JTAG debugger
> > is connected.
> >
> > I've checked TI's reference designs (for MSP430F123/F169/F20x)
for
> > hardware tricks. All I could see is an additional C to GND and pullup on
> > RST/NMI pin, but this didn't solve the problem.
> >
> > Stefan
>
Reply by Dan Bloomquist●November 11, 20092009-11-11
Stefan Gysel wrote: >> Questions:
>> What compiler are you using? What's the optimization level?
>>
>
> I'm using IAR with optimization level set to 'none'.
>
>
>> Are you sure the delay routine is being executed?
>> Have you looked at the disassembly code?
>>
>
> Yes, I can see the delay on the scope. Also single stepping in debug
> mode works as expected. There is nothing suspicious in the disassembly
> code.
>
> The fact that the code works in most of the cases make me think the
> problem lies more in hardware (power on sequence) than in software.
> Unfortunately I cannot replicate the faulty behavior while JTAG debugger
> is connected.
>
I'm going to take a wild guess as I've run into a problem with the TI
code. If ACLK is not settled, (don't know why that would be true), the
code can run off the end and start smashing the BCSCTL1 register.
Reply by old_cow_yellow●November 11, 20092009-11-11
As a test, you could try to use a much lower DCO frequency and see if the
problem persists. Change DCO as early as you can, do it in c-startup if
possible.
--- In m..., Stefan Gysel wrote: >
> > Questions:
> > What compiler are you using? What's the optimization level?
>
> I'm using IAR with optimization level set to 'none'.
>
> > Are you sure the delay routine is being executed?
> > Have you looked at the disassembly code?
>
> Yes, I can see the delay on the scope. Also single stepping in debug
> mode works as expected. There is nothing suspicious in the disassembly
> code.
>
> The fact that the code works in most of the cases make me think the
> problem lies more in hardware (power on sequence) than in software.
> Unfortunately I cannot replicate the faulty behavior while JTAG debugger
> is connected.
>
> I've checked TI's reference designs (for MSP430F123/F169/F20x)
for
> hardware tricks. All I could see is an additional C to GND and pullup on
> RST/NMI pin, but this didn't solve the problem.
>
> Stefan
>
Reply by Stefan Gysel●November 11, 20092009-11-11
> Questions:
> What compiler are you using? What's the optimization level?
I'm using IAR with optimization level set to 'none'.
> Are you sure the delay routine is being executed?
> Have you looked at the disassembly code?
Yes, I can see the delay on the scope. Also single stepping in debug
mode works as expected. There is nothing suspicious in the disassembly
code.
The fact that the code works in most of the cases make me think the
problem lies more in hardware (power on sequence) than in software.
Unfortunately I cannot replicate the faulty behavior while JTAG debugger
is connected.
I've checked TI's reference designs (for MSP430F123/F169/F20x) for
hardware tricks. All I could see is an additional C to GND and pullup on
RST/NMI pin, but this didn't solve the problem.
Stefan
Reply by Michael●November 11, 20092009-11-11
Questions:
What compiler are you using? What's the optimization level?
Are you sure the delay routine is being executed?
Have you looked at the disassembly code?
Michael K.
--- In m..., Stefan Gysel wrote: >
> Hi
>
> I'm using a MSP430F133 with 32kHz crystal on LFXT1. MCLK is set to DCO
> which runs at ~750kHz on startup and is synchronized to ACLK at 1.04 Mhz
> using Set_DCO() from TI example. After power on, everything works fine
> in most cases. It happens though that the cpu hangs before or after the
> delay loop (P2.4 is ON or P2.5 is ON). MCLK can be present at P5.4 or
> remains rarely at 3V3 DC. It looks like unspecified conditions during
> power on. Is there a way to avoid this or do a proper reset in such a
> case without the need of external BOR devices?
>
> Thanks,
> Stefan
> void main( void ){
> uint16 j;
>
> // Stop watchdog timer to prevent time out reset
> WDTCTL = WDTPW + WDTHOLD;
>
> P5SEL_bit.P5SEL_4 = 1; // MCLK output on pin 5.4
> P5DIR_bit.P5DIR_4 = 1;
> P5SEL_bit.P5SEL_6 = 1; // ACLK output on pin 5.6
> P5DIR_bit.P5DIR_6 = 1;
>
> P2DIR = 0xf0; // Output P2.4 - P2.7
> P2OUT_bit.P2OUT_4 = 1;
> P2OUT_bit.P2OUT_5 = 0;
> P2OUT_bit.P2OUT_6 = 0;
> P2OUT_bit.P2OUT_7 = 0;
>
> for( j = 0; j < 0xFFFF; j++){} // delay for ACLK startup
> P2OUT_bit.P2OUT_5=1;
>
> Set_DCO();
> P2OUT_bit.P2OUT_6 = 1;
> }
>
Reply by Stefan Gysel●November 10, 20092009-11-10
Hi
I'm using a MSP430F133 with 32kHz crystal on LFXT1. MCLK is set to DCO
which runs at ~750kHz on startup and is synchronized to ACLK at 1.04 Mhz
using Set_DCO() from TI example. After power on, everything works fine
in most cases. It happens though that the cpu hangs before or after the
delay loop (P2.4 is ON or P2.5 is ON). MCLK can be present at P5.4 or
remains rarely at 3V3 DC. It looks like unspecified conditions during
power on. Is there a way to avoid this or do a proper reset in such a
case without the need of external BOR devices?
Thanks,
Stefan
void main( void ){
uint16 j;
// Stop watchdog timer to prevent time out reset
WDTCTL = WDTPW + WDTHOLD;
