Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Thread

Re: Mega644-20P

Re: Mega644-20P

2009-03-29 by s.holder123@btinternet.com

I notice that just before the crash you are setting the device pinb5 to an output pin, is the pull up enabled when set as an input ?

Might be an idea to insert an intermediate state, might possibly be getting a vcc to 0v power short, (see section 12.2.3 int the datasheet) this could be giving you the glitch, what is the PORT REG value before you switch to an output ? Is an intermediate state required ?

Regards

--- In AVR-Chat@yahoogroups.com, David VanHorn <microbrix@...> wrote:
Show quoted textHide quoted text
>
> On Sun, Mar 29, 2009 at 5:48 PM, Jim Wagner <wagnerj@...> wrote:
> > Hmmm. ...
> >
> > Can you set a "variable watch" that triggers on a memory value that
> > should not change but IS getting changed? I don't remember if Studio
> > has that.
> 
> I have that in code, no triggers.
> 
> > Another possibility is that you are getting a corrupted stack (ie,
> > unmatched push/pops or something that writes into area used by stack)
> > and you are returning to a place in ROM that is the middle of a two-
> > word instruction so that everything subsequent is really messed up.
> > Been there, done that!
> 
> Yup, I have a stack guardian, it's not hitting that either, and when I
> look at ram, it looks ok.
> >16 bytes free between the bottom of the stack and the guardian.
> 
> 
> > Jim
> >
> > On Mar 29, 2009, at 2:23 PM, David VanHorn wrote:
> >
> >> I added a full vector table, and every entry for the unused ints sets
> >> "sanity_flag" to some unique value.
> >> There's a task that checks sanity flag for any non-zero value, and
> >> it's never triggering.
> >>
> >>
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> 
> 
> 
> -- 
> There is no computer problem which cannot be solved by proper
> application of a sufficiently large hammer.
>

Re: [AVR-Chat] Mega644-20P

2009-03-29 by John Samperi

At 07:43 AM 30/03/2009, you wrote:
>I'm having lots of odd problems at the moment,

You should really thing about moving your workshop
from under the ladder factory.... :-)


Regards

John Samperi

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

Re: [AVR-Chat] Mega644-20P

2009-03-29 by David VanHorn

On Sun, Mar 29, 2009 at 5:04 PM, John Samperi
<samperi@ampertronics.com.au> wrote:
> At 07:43 AM 30/03/2009, you wrote:
>>I'm having lots of odd problems at the moment,
>
> You should really thing about moving your workshop
> from under the ladder factory.... :-)

We're next-door to the broken mirror plant too.



-- 
There is no computer problem which cannot be solved by proper
application of a sufficiently large hammer.

Re: [AVR-Chat] Mega644-20P

2009-03-29 by David VanHorn

I added a full vector table, and every entry for the unused ints sets
"sanity_flag" to some unique value.
There's a task that checks sanity flag for any non-zero value, and
it's never triggering.

Re: [AVR-Chat] Mega644-20P

2009-03-29 by Jim Wagner

Hmmm. ...

Can you set a "variable watch" that triggers on a memory value that  
should not change but IS getting changed? I don't remember if Studio  
has that.

Another possibility is that you are getting a corrupted stack (ie,  
unmatched push/pops or something that writes into area used by stack)  
and you are returning to a place in ROM that is the middle of a two- 
word instruction so that everything subsequent is really messed up.  
Been there, done that!

Jim

On Mar 29, 2009, at 2:23 PM, David VanHorn wrote:

> I added a full vector table, and every entry for the unused ints sets
> "sanity_flag" to some unique value.
> There's a task that checks sanity flag for any non-zero value, and
> it's never triggering.
>
> 



[Non-text portions of this message have been removed]

Re: [AVR-Chat] Mega644-20P

2009-03-29 by David VanHorn

On Sun, Mar 29, 2009 at 5:48 PM, Jim Wagner <wagnerj@proaxis.com> wrote:
> Hmmm. ...
>
> Can you set a "variable watch" that triggers on a memory value that
> should not change but IS getting changed? I don't remember if Studio
> has that.

I have that in code, no triggers.

> Another possibility is that you are getting a corrupted stack (ie,
> unmatched push/pops or something that writes into area used by stack)
> and you are returning to a place in ROM that is the middle of a two-
> word instruction so that everything subsequent is really messed up.
> Been there, done that!

Yup, I have a stack guardian, it's not hitting that either, and when I
look at ram, it looks ok.
>16 bytes free between the bottom of the stack and the guardian.


> Jim
>
> On Mar 29, 2009, at 2:23 PM, David VanHorn wrote:
>
>> I added a full vector table, and every entry for the unused ints sets
>> "sanity_flag" to some unique value.
>> There's a task that checks sanity flag for any non-zero value, and
>> it's never triggering.
>>
>>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>



-- 
There is no computer problem which cannot be solved by proper
application of a sufficiently large hammer.

Re: [AVR-Chat] Re: Mega644-20P

2009-03-30 by David VanHorn

On Sun, Mar 29, 2009 at 6:07 PM, s.holder123@btinternet.com
<s.holder123@btinternet.com> wrote:
> I notice that just before the crash you are setting the device pinb5 to an output pin, is the pull up enabled when set as an input ?
>
> Might be an idea to insert an intermediate state, might possibly be getting a vcc to 0v power short, (see section 12.2.3 int the datasheet) this could be giving you the glitch, what is the PORT REG value before you switch to an output ? Is an intermediate state required ?

No, it really was that crazy.
Powering down the target and the Jtag seems to have cured it, at least
temporarily.
Looks like the Jtag is getting lost and out of sync with the target sometimes.



-- 
There is no computer problem which cannot be solved by proper
application of a sufficiently large hammer.

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.