AVR-Chat

Hi all,

I have a problem with a project. I can see the problem externally, I
have a counter that counts from 1 to 255, ticks over to 0 and counts up
again....

Sometimes during the operation, the counter resets to 1 and starts again.

I have sent MCUCSR to port A, so that I can tell what caused the reset,
but nothing shows (unless I make it do a POR or manual reset)

I am using a Mega8535.

I am out of ideas on what to check, and would love any tips.

The AVR works fine in the STK500, but only seems to fail in the target
hardware. The hardware is only a MAX232 and a MAX485, external crystal
(14.7456MHz) a 0.1uf cap from reset to ground (nothing else on ground as
I am using the internal BOD and POR)

Regards,

Kat.

At 10:50 AM 6/5/2005, Kathy Quinlan wrote:
>Hi all,
>
>I have a problem with a project. I can see the problem externally, I
>have a counter that counts from 1 to 255, ticks over to 0 and counts up
>again....
>
>Sometimes during the operation, the counter resets to 1 and starts again.

Can you verify that this is really happening?
Maybe it's a debugging phantom.
I had "run timers while stopped" get turned on once, don't know how, 
but it looked like the timer was completely nuts.

On Jun 5, 2005, at 10:50 AM, Kathy Quinlan wrote:

> Hi all,
>
> I have a problem with a project. I can see the problem externally, I
> have a counter that counts from 1 to 255, ticks over to 0 and  
> counts up
> again....
>
> Sometimes during the operation, the counter resets to 1 and starts  
> again.

That sounds a lot like an interrupt vector is undefined by your  
application and is executing the default vector which is usually the  
startup/initialization code.

Its the kind of thing that could be hard to track down. I don't know  
of a way for a routine to extract the vector which called it. Write  
such a routine and substitute for the default. Otherwise one is stuck  
writing a unique IRQ service routine for each and every IRQ vector.  
Do something unique in each routine and you'll know which is getting  
dispatched.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

>
>Its the kind of thing that could be hard to track down. I don't know
>of a way for a routine to extract the vector which called it. Write
>such a routine and substitute for the default. Otherwise one is stuck
>writing a unique IRQ service routine for each and every IRQ vector.
>Do something unique in each routine and you'll know which is getting
>dispatched.

Put a panic loop between the vector table and the main code?

Here:
         ;bang I/O pin
         rjmp here


I use a routine called "Pong" a lot, which outputs a byte as PWM, 
where all byte values take the same time.
0s are narrow, 1's are wide.
For something like this, I'd load a unique value into TEMP, and call 
PONG on each ISR, so the output shows the int train.
You need a DSO or logic analyzer to catch it though.

Dave VanHorn wrote:
> At 10:50 AM 6/5/2005, Kathy Quinlan wrote:
> 
>>Hi all,
>>
>>I have a problem with a project. I can see the problem externally, I
>>have a counter that counts from 1 to 255, ticks over to 0 and counts up
>>again....
>>
>>Sometimes during the operation, the counter resets to 1 and starts again.
> 
> 
> Can you verify that this is really happening?
> Maybe it's a debugging phantom.
> I had "run timers while stopped" get turned on once, don't know how, 
> but it looked like the timer was completely nuts.

Sorry,

I should have said a software counter (ie frame_cnt++), not a hardware 
counter.

Regards,

Kat.

David Kelly wrote:
> On Jun 5, 2005, at 10:50 AM, Kathy Quinlan wrote:
> 
> 
>>Hi all,
>>
>>I have a problem with a project. I can see the problem externally, I
>>have a counter that counts from 1 to 255, ticks over to 0 and  
>>counts up
>>again....
>>
>>Sometimes during the operation, the counter resets to 1 and starts  
>>again.
> 
> 
> That sounds a lot like an interrupt vector is undefined by your  
> application and is executing the default vector which is usually the  
> startup/initialization code.
> 
> Its the kind of thing that could be hard to track down. I don't know  
> of a way for a routine to extract the vector which called it. Write  
> such a routine and substitute for the default. Otherwise one is stuck  
> writing a unique IRQ service routine for each and every IRQ vector.  
> Do something unique in each routine and you'll know which is getting  
> dispatched.


This is in CodeVision C, so I am sure all unused interrupts are just 
reti instructions, but I will check :)

Regards,

Kat.

At 01:50 AM 6/06/2005, you wrote:
>The AVR works fine in the STK500, but only seems to fail in the target
>hardware.

Would this not indicate a hardware problem with your
target board? If it works correctly in the STK500 then
it would not be code/firmware related. A dry joint?
How is your power supply?


Regards

John Samperi

******************************************************
                         Ampertronics Pty. Ltd.
   11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
          Tel. (02) 9674-6495       Fax (02) 9674-8745
                Email: samperi@ampertronics.com.au
                  Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

Kathy Quinlan wrote:
> David Kelly wrote:
> 
>>On Jun 5, 2005, at 10:50 AM, Kathy Quinlan wrote:
>>
>>
>>
>>>Hi all,
>>>
>>>I have a problem with a project. I can see the problem externally, I
>>>have a counter that counts from 1 to 255, ticks over to 0 and  
>>>counts up
>>>again....
>>>
>>>Sometimes during the operation, the counter resets to 1 and starts  
>>>again.
>>
>>
>>That sounds a lot like an interrupt vector is undefined by your  
>>application and is executing the default vector which is usually the  
>>startup/initialization code.
>>
>>Its the kind of thing that could be hard to track down. I don't know  
>>of a way for a routine to extract the vector which called it. Write  
>>such a routine and substitute for the default. Otherwise one is stuck  
>>writing a unique IRQ service routine for each and every IRQ vector.  
>>Do something unique in each routine and you'll know which is getting  
>>dispatched.
> 
> 
> 
> This is in CodeVision C, so I am sure all unused interrupts are just 
> reti instructions, but I will check :)
> 
> Regards,
> 
> Kat.

F*&K that is not good, I just checked the .lst file, and all UNUSED 
interrupts jump to 0x0000 ie the RESET VECTOR.

I think this is a very poor way to handle things.

now to track down the phantom interrupt :(

Regards,

Kat.

At 05:49 AM 6/06/2005, you wrote:
> > I had "run timers while stopped" get turned on once, don't know how,
> > but it looked like the timer was completely nuts.

If I well remember that was a JTAG ice problem which
Kate would not have with a Mega8535.

Regards

John Samperi

******************************************************
                         Ampertronics Pty. Ltd.
   11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
          Tel. (02) 9674-6495       Fax (02) 9674-8745
                Email: samperi@ampertronics.com.au
                  Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

>
>F*&K that is not good, I just checked the .lst file, and all UNUSED
>interrupts jump to 0x0000 ie the RESET VECTOR.
>
>I think this is a very poor way to handle things.
>now to track down the phantom interrupt :(
>Regards,

Muchly doth that suck.

Dave VanHorn wrote:
>>F*&K that is not good, I just checked the .lst file, and all UNUSED
>>interrupts jump to 0x0000 ie the RESET VECTOR.
>>
>>I think this is a very poor way to handle things.
>>now to track down the phantom interrupt :(
>>Regards,
> 
> 
> Muchly doth that suck.

Lucky the customer is a tech, as I have just shipped 9 units to Tasmania 
(some 4500 Kms from here) as it looks like I will be releasing 1.2.1.1 :(

This works fine in the STK500, but on strip board it was randomly 
locking up and restarting :( but I think this has now fixed it :)

Will leave it on test the rest of the night,

Oh well something new I have just learnt.

Regards,

Kat.

At 06:35 AM 6/06/2005, you wrote:
>Will leave it on test the rest of the night,

?? The night has been and gone. I had a look at
the time stamps for your mail and it looks as is
you have been up all night with it. ;-)

I though it was bad for me to have a 5:30 start
this cold Sydney morning |-O |-O

Regards

John Samperi

******************************************************
                         Ampertronics Pty. Ltd.
   11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
          Tel. (02) 9674-6495       Fax (02) 9674-8745
                Email: samperi@ampertronics.com.au
                  Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

John Samperi wrote:
> At 06:35 AM 6/06/2005, you wrote:
> 
>>Will leave it on test the rest of the night,
> 
> 
> ?? The night has been and gone. I had a look at
> the time stamps for your mail and it looks as is
> you have been up all night with it. ;-)
> 
> I though it was bad for me to have a 5:30 start
> this cold Sydney morning |-O |-O
> 
> Regards
> 
> John Samperi

LOL it is only 0447 here in Perth :)


Untill the sun comes up it is still night ;)

Regards,

Kat.