Yahoo Groups archive

AVR-Chat

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

Thread

initial flash programming run versus subsequent runs

initial flash programming run versus subsequent runs

2013-12-13 by Steven Hodge

I have something weird going on, where a small part of the code only works
when the code is first uploaded to flash memory, and does not work when
subsequently the power to the uC is cycled on/off.

The code is assembly, for a Mega644P.  Programming is done using a JTAG
interface and AVR Dragon. 

Briefly, the code monitors a set of switches and whenever a switch changes
state it sends a single byte message out a serial port.  The code is
interrupt-driven and uses the port pin change interrupts.  The USART actions
are also interrupt-driven, using code that has supposedly stood the
proverbial test of time.

At the end of the initialization code, after all the port interrupts and
pins have been set up, there are 3 steps:

-- initialize the USART
-- enable global interrupts with "sei" (necessary for the next step)
-- send a single, unique byte (0x7F) out the serial port.  This is intended
as a "wake-up/I'm alive" message to the receiving end.

The code then enters a sleep loop, waiting for switch changes.

When I initially upload the program to flash memory, all the above works
perfectly, just as I want it to.  I get the wake-up byte and whenever a
switch changes state I get a byte, one for turning on, one for turning off.
However, if I then cycle the power off/on, I do NOT get the wake-up byte but
the board still faithfully and reliably sends out switch change bytes from
the main sleep loop.  So the "meat" of the program works fine, always.  It's
just the wake-up byte that doesn't.  This is the same result whether or not
I have the JTAG programming connection plugged in or not.  I have also tried
a JTAGICE3 programmer (still using JTAG) and the result is the same.

And, of course, the Catch-22 is that I can't use the debugger part of the
JTAG connection to debug this because every time I enter debugging mode it
uploads the program once again to flash memory and thus, as expected, it
works perfectly and transmits the wake-up byte just fine.  

The serial-to-USB adapter that I use has led's on the TX/RX lines and, sure
enough, I see nothing when the wake-up byte should be, but isn't,
transmitted.  So I know the issue is not with the receiving end.  It's
something to do with the uC end.

I'd be happy to upload the code, but first I'm asking if anyone has had
similar things happen and/or know what might be a difference between initial
code upload and subsequent re-starts.  

Thanks in advance,

Steve

PS.  I'm also going to post this on AVR-Freaks, so you can ignore it if you
see it there.

RE: initial flash programming run versus subsequent runs

2013-12-13 by n1ist@comcast.net

Are you certain that you are powering off the processor? I had a board that happily ran without power as long as the rx line was connected to the PC; it was powering the processor through the ESD protection diodes on the chip...

/mike

RE: [AVR-Chat] RE: initial flash programming run versus subsequent runs

2013-12-14 by Steven Hodge

Thanks for reminding me of that. I once had that happen to me too. However, I just ran some tests and it’s not the case here. I disconnected the programmer and turned off the board power. I then removed the serial lines (leaving the GND connected to the adapter) and re-connected them. No bytes came out and it did not respond to switch changes, so I assume the processor was (correctly) not powered on. Turn on the board power and it does respond to switch changes but, as before, no wake-up byte.

Steve

From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf Of n1ist@comcast.net
Sent: Friday, December 13, 2013 3:59 PM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] RE: initial flash programming run versus subsequent runs

Are you certain that you are powering off the processor? I had a board that happily ran without power as long as the rx line was connected to the PC; it was powering the processor through the ESD protection diodes on the chip...

/mike

RE: [AVR-Chat] RE: initial flash programming run versus subsequent runs

2013-12-14 by Dave McLaughlin

Hi Steve,

What happens if you put in a delay at the start before you send the byte?

What fuse settings do you have for startup? I've never used the fast options, always slow start and this has proven reliable.

On a system I did years ago, I had a similar issue with the serial port. I had to put in a 1 second delay before I started to send any data. This I think was way back with an AT90S8515

The other issue could be with your RS232 drivers. What are you using here? I've seen an issue in the past where the startup power timing for the POS and NEG supplies was slow although modern devices should be fast these days. This was with the older IC's using 1uF caps. Worth checking here though.

Dave…

---

Very funny Scotty, now beam down my clothes…

---

From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf Of Steven Hodge
Sent: 14 December 2013 08:34
To: AVR-Chat@yahoogroups.com
Subject: RE: [AVR-Chat] RE: initial flash programming run versus subsequent runs

Thanks for reminding me of that. I once had that happen to me too. However, I just ran some tests and it’s not the case here. I disconnected the programmer and turned off the board power. I then removed the serial lines (leaving the GND connected to the adapter) and re-connected them. No bytes came out and it did not respond to switch changes, so I assume the processor was (correctly) not powered on. Turn on the board power and it does respond to switch changes but, as before, no wake-up byte.

Steve

RE: [AVR-Chat] RE: initial flash programming run versus subsequent runs

2013-12-14 by Steven Hodge

Dave (and Mike), I tried all sorts of delays but none worked.  In the process of doing this I discovered that my tests to determine if the board was still powered by the RX/TX lines were faulty, and as it turns out that *is* the source of the problem.  The board is not actually turning off.  

 

Ideas on how to fix this?   Series resistors in the RX/TX lines?

 

Thanks, Steve
Show quoted textHide quoted text
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf Of Dave McLaughlin
Sent: Friday, December 13, 2013 6:31 PM
To: AVR-Chat@yahoogroups.com
Subject: RE: [AVR-Chat] RE: initial flash programming run versus subsequent runs

 

  

Hi Steve,

 

What happens if you put in a delay at the start before you send the byte?

 

What fuse settings do you have for startup? I've never used the fast options, always slow start and this has proven reliable.

 

On a system I did years ago, I had a similar issue with the serial port. I had to put in a 1 second delay before I started to send any data. This I think was way back with an AT90S8515

 

The other issue could be with your RS232 drivers. What are you using here? I've seen an issue in the past where the startup power timing for the POS and NEG supplies was slow although modern devices should be fast these days. This was with the older IC's using 1uF caps. Worth checking here though.

 

Dave…

---

Very funny Scotty, now beam down my clothes…

---

 

From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf Of Steven Hodge
Sent: 14 December 2013 08:34
To: AVR-Chat@yahoogroups.com
Subject: RE: [AVR-Chat] RE: initial flash programming run versus subsequent runs

 

  

Thanks for reminding me of that.  I once had that happen to me too.  However, I just ran some tests and it’s not the case here.  I disconnected the programmer and turned off the board power.  I  then removed the serial lines (leaving the GND connected to the adapter) and re-connected them.  No bytes came out and it did not respond to switch changes, so I assume the processor was (correctly) not powered on.   Turn on the board power and it does respond to switch changes but, as before, no wake-up byte.

 

Steve

 





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

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.