Mystery: MEGA328P reset pin autonomous oscillation

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
It's about the MEGA328P reset circuit. I try to get the Makeblock plotter V2.0 Me-Orion control board (12V external powersupply) working with Atmel Studio 7 through ISP. On the board is a Mega328P. Flashing the program, there is no problem. Setting de Debug Wire fuse, no problem. Donwloading a small led blinking program in debug mode after a few times makes the Mega328P inaccessible. On the reset pin of the atmel there's an oscillating signal of app. 1KHz (0V-3V) even if all wires are removed and only the powersupply is connected to the board. Pressing and releasing the reset button restarts this oscillation. I tried everything: pullup 10K/4K7, Capacitor to GND, rectifier to VCC, to no avail. The uC VCC is stable at 5V. I discovered that shorting the 12V powersupply capacitor (during poweroff) makes the reset circuit stable again and I can only once download a new program. I'v seen this problem on another different kind of board with an MEGA328PB.
What I today discoverd is this:
(1) keep the reset button pressed and poweron the board: my blinking led program runs!!! (reset signal monitored by scoop)
(2) release reset button: the blinking program still runs
(3) press the reset button: the blinking program stops
(4) release the reset button: reset pin oscillates and the blinking program does not start

It seems as if the reset circuit of the atmel likes to see a low-going edge to activate the internal reset circuit.

Can someone explain this point (1) to (4) behaviour?

I use the Atmel Dragon programmer/debugger.

Thanks
Henk

Last Edited: Mon. Mar 12, 2018 - 08:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

afhvw wrote:
Donwloading a small led blinking program in debug mode

 

Debug/wire uses the reset line as a half duplex comm port!  I would expect to see this pin wiggling during a debug session. 

Disable Dwire mode and see if this behavior disappears....

 

 

Jim

 

 

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@afhvw wrote:

On the board is a Mega328P.

 

According to the schematic, it is an ATmega328, not an ATmega328P.  Lower left corner of schematic::

 

 

 

If I understand correctly, you have an ISP cable plugged into ICSP1 for programming.  Is this correct?

 

When you say "even if all wires are removed and only the powersupply is connected to the board," do you mean you unsoldered all the pins on the ATmega328 except for the power pins?

 

What does "rectifier to Vcc" mean?

 

EDIT: strike-through

 

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Last Edited: Mon. Mar 12, 2018 - 09:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm........

 

According to the webpage for the product, it has an ATmega238 in it:

 

 

EDIT: added link to product page.

 

 

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Last Edited: Mon. Mar 12, 2018 - 09:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
I think I understand what is going on:
- if a program is downloaded with debugwire fuse set and the program contains some breakpoints then if no debugger is attached:
  - the program will start on powerup regardless of the reset pin state and will ignore breakpoints
  - the program will hang on the first inserted breakpoint wait-code instruction after a reset pin is released and oscillation on the reset pins starts probably because the uC wants to communicatie with the debugger
Other points:
  - the schematics indeed shows a ATmega328 but on the board an 'MEGA328P' type is mounted
  - a rectifier connected to VCC means kathode to VCC to protect agains too high voltage spikes on the reset pin
  - if sometimes the debug-mode entering succeeds I can see a clear 0V/3V digital data signal on the reset pin (why not 5V?)
  - I tried a short 15cm ISP cable but that has no effect
  - I borrowed the dragon debugger but are now going to order me a atmel SAM ICE
  - I will try to replace the processer on the board with a new one and test again

Last Edited: Tue. Mar 13, 2018 - 06:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

afhvw wrote:
I will try to replace the processer on the board with a new one and test again

 

Why not just enter debug session and then exit with disable debugWire mode? 

 

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Because of the oscillation I do not get access to the loaded program or cannot start a program in debug mode to end the debugWire mode. On the other hand I just want to have a stable system and be sure it's not a damaged uC.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is your 1kHz 3V signal a square wave, or does it have some sine like properities?

Did you measure this with a proper oscilloscope?

What is your experience level with such tools?

 

I would not be surprised if this is caused by a bad GND connection. Either somewhere on the PCB or in a cable or your scope gnd lead.

Have you checked your voltage regulator? Are you sure your 5V is ok?

 

Can the dragon do DebugWire? (I almost bought one years ago, but decided against it because they tended to destroy themself)

It might be a good idea to practice a bit in gettin chips into and out of DebugWire mode on a breadboard before you start soldering.

 

Could it be that you have a short circuit on your PCB and a weird signal is injected into your reset pin?

What happens if you touch the reset pin during measurement?

If your "weird" signal is low impedance you won't see a significant change. If it is a high impedance signal it will probably get significantly worse.

 

Could it be that your scope is picking up EMI?

If you touch your scope probe does that signal resemble the measurement on your reset pin?

I have some flueresent lights above my desk which are buzzing constanly (electrically) at a few kHz.

 

Posting a screen capture or photograph of your scope screen can help a lot in determining the cause of your disturbance.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've over a 40 years experience with electronics and scoops...;-)
Attached is a picture of the scope. This picture was taken using my fresh delivered Atmel SAM ICE programmer/debugger (so same problem). Yes you can debug with Atmel Dragon. I've done this a lot of times. Tomorrow I will have the uC replaced. I wonder if the DebugWire interface can cope with an Atmel running at 5V. Maybe when running at 3V3 there is no problem... Touching the scope probe has no effect, it's a strong signal. I have seen this oscillating signal a few times on a complete other kind of board with an Atmega328PB on it. Maybe it's an 328 problem.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Still looks like debugwire is attempting to start, but the line capacitance is too high.

 

I don't know where the 0V offset is.  Is it the little tick mark on the left?  If so, Looks like it's bouncing from 0V to about 1V, with a bit of ringing going negative.  1.85 ms to reach 1V when the pull-up is to 5V (i.e. 20%) implies a TC of 1.85/(-ln(1 - 0.2)) = 8.3 ms.  With a /RESET pullup value of between 30K and 60K, that implies a capacitance of between 138nF and 276nF  That's too high for debugWire.  There should be >>no<< capacitor on /RESET.

 

  - the program will start on powerup regardless of the reset pin state and will ignore breakpoints

There are four possibilities:

1) reset button is flaky

2) reset circuit is >>not<< as Greg posted in #3

3) debugWire is enabled

4) RSTDISBL is programmed

 

 

the program will hang on the first inserted breakpoint wait-code instruction after a reset pin is released and oscillation on the reset pins starts probably because the uC wants to communicatie with the debugger

Which seems to confirm #3 above, as everyone else has been saying.

 

You can't perform an external reset via /RESET pin when debugWire is enabled.  Period.

 

None of this is surprising.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
You can't perform an external reset via /RESET pin when debugWire is enabled. Period. None of this is surprising.

 

Again, disable DebugWire mode by starting a debug session, then stop and exit DWire properly!

None of this is surprising!

 

Jim

 

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PTL! Mystery solved.

 

I did not manage to change the uC but last night awake I was thinking about joeymorin's reply about no capacitor on Reset.  If I look at the schematic there's a 1uF C14 capacitor to the USB driver chip CH340 DTR output. I removed the capacitor and lo and behold the debugger runs flawlesly!!! (&^%*&^%$*&^)

Thank you guys for all your advises.

 

Back to programming...

 

Henk