more issues with the atmega1284P

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

I've managed to burn an Arduino style bootloader onto my atmega1284p using a Dragon in jtag mode. I set the fuses for full swing oscillator (0xf7,0x9e, 0xfd). The bootstrap disables the jtag to allow all pins to be used.

The Arduino circuit connects the DTR line of the FTDI usb/serial chip to the reset of the processor though a 100nf cap. The reset line is pulled high via a 10k resistor. This scheme allows avrdude to reset the processor to enter the bootstrap. I've had this work with atmega328's and atmega2561's (it works on the Arduino mega boards that use the atmega2560 and atmega1280 procesors). However is does NOT work on the atmega1284p. I wonder if something is screwy with the reset circuit on this processor. (Grounding the reset line manually DOES reset it, and allow the bootstrap to run. But that takes three hands!)

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

I see no reason for a mega1284 to work any differently to any other mega AVR. I would check:

1. your conditional code in any generic bootloader
2. your boot load address, BOOTSIZ fuses
3. your BOOTRST, lockbits

The Arduino boot via DTR works very well. It takes the pain out of bootloading. i.e. finger contortions.

David.

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

The RC time constant is 100nf * 10K 1ms. You have about 1/3 that time to get the MCU booted into the loader. Did you happen to use a particularly long startup time or a low clock frequency (that makes the start up cycle count longer)?

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

The boot code has NOTHING to do with the problem. The processor ISN'T reseting. I loaded an application that blinks an LED and then attempted to over write that application with another that blinks the LED more slowly. The LED never missed a beat. However, if I press the reset button before clicking upload, the application is replaced.

The time constant is set by a 100nf cap and a 100k pull up. I've had a 10K in there, no difference. I think I have the 65k clock cycle delay (l,h x fuses are F7,9E,FD for the atmega1284p). Crystal is 18.432mhz.

I can't see a reset pulse at the processor pin with my old TTL logic probe or my Tek 454 (I really need to get a new digital scope). I DO see the reset pulse at the DTR pin. (Should there be an RS-232 to TTL translater before the 100ns cap? I think it works both ways).

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

More info. I have an Max232 rs232->ttl translator chip in the circuit (using a "real" com port on the PC to drive my breadboard). One receiver on the chip is connected to the DTR line. The receiver output is normally high until avrdude starts then the line pulses high once or twice then stays high until avrdude times out. I now connect the receiver output via a 100nf cap to the base of a 2n2222 with a 10k pull down resistor. The collector goes to the reset line of the processor. If I disconnect the collector from the processor and connect it to 5v through a 10k pull up I will see a pulse on the collector when avrdude starts. If I connect the collector to the processor reset line (it is also connected to a 10k pull up and a N.O. momentary switch to ground) I do NOT see the pulse anymore. It's almost as if the processor has a low resistance internal pullup on the reset line to 5v which swamps out the transistor.

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

An extra RC filtering perhaps...

https://www.avrfreaks.net/index.p...

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

spcomputing wrote:
An extra RC filtering perhaps...
https://www.avrfreaks.net/index.p...

Nope, that problem CAUSES random reseting of the processor. My problem is that I can't drive the reset line of the processor TO RESET IT!

The answer seems to be that a simple RC network from the DTR signal can't pull the processor reset line down hard enough. Even with a 2N2222 to amplify the current it can't. I connected TWO 2N2222 transistors in a Darlington configuration. Collector(s) go to the reset pin, emitter ground, base to ground via a 10k and to the DSR signal via a 100nf cap. THIS WORKS! (Finally!) I suppose I could use a Darlington transistor, but I have tons of 2N2222/2N3904's in the junque box. (The units I used were probably 2n3904's come to think of it).

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

There is something wrong with your 100nF or the wiring.

The DTR signal from an FTDI is only a regular GPIO pin going low. This will have an o/p impedance of 100R or so.

Your m1284 will have a weak internal pull-up on the /RESET pin of say 50k. You have a perfectly normal external 10k pullup. i.e. effectively ~ 8k pullup.

100R x 100nF = 10us falltime.
8k x 100nF = 800us risetime.

If your 100nF was 100pF, the AVR would not reset.
If your 100nF had a leakage resistance, the DTR would reset and hold it in reset

Throwing Darlingtons at the problem only reduces the o/p impedance. i.e. you would get a sharper fall time.

Have you 'tested' your 100nF ?

David.

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

I've actually tried several different caps. I've tried several different 100nf caps, I even tried a .047uf, a .22uf, .33uf, and a 1uf capacitor (all mono-ceramic types). So I don't think it was a bad cap. I put a logic probe at the DTR signal, and at the reset line. I see the reset signal at the DTR output, but NOT at the reset pin when the cap was directly connected to the processor reset line. The processor IS LOADING this signal down. ONLY with the darlington amplifier does the reset get pulled low. There is *SOMETHING* going on with the atmega1284p reset input. Now I may have an early date code. (It's 1050) I've also heard that the DIP packages had issues not seen on the SMT versions.
But it's NOT a bad cap. I even raised my pullup resistor to 100K. Unless I have weak RS232-TTL level shifters or a weak FTDI232R, the problem is inside the processor. The darlington amp is a bandaid to the problem.

EDIT:
I wonder if there is a way to actually measure the input impedance of the atmega1284p reset line. Perhaps pull it LOW with a known resistance and measure the voltage across this resistor? Or pull it low through zero ohms and a milli ampmeter and measure the current?

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

Quote:
Perhaps pull it LOW with a known resistance and measure the voltage across this resistor? Or pull it low through zero ohms and a milli ampmeter and measure the current?

Seems a good idea. I guess that an internal pullup of 10k - 100k would be acceptable.

David.

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

The ebay special proto board I am using seems to have a 10uf cap on the reset line to ground. I never noticed that until now. Removing it solved the reset problem.

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

kscharf wrote:
I have an Max232 rs232->ttl translator chip in the circuit (using a "real" com port on the PC to drive my breadboard).
There is a significant difference in DTR reset circuits depending on the voltage swing of the DTR signal used. When using an FTDI chip, the DTR signal has a 5 volt (or 3.3 V) swing. However, with real serial signals, the DTR signal will swing from about -10V to +10V. This means that you must either use a level converter or add clipping diodes and a limiting resistor. Without these, the AVR will see transitions on the reset pin well below ground and well above Vcc. I've worked with a board that had these conditions and I can attest that the AVR did not react well to it.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

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

kscharf wrote:
The ebay special proto board I am using seems to have a 10uf cap on the reset line to ground. I never noticed that until now. Removing it solved the reset problem.
A cap from reset to ground is exactly how to defeat the DTR reset on an Arduino used as an ISP. The IDE even comes with an example sketch that does this. Too bad you banged your head against this so long... :)

JJ

"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."

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

 

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

Also after removing the unwanted cap and connecting the reset via a cap to the DTR pin of the RS232 connector only worked "sometimes", using the MAX232 to buffer the DTR signal works almost all the time. Note that I always used a .1uf capacitor to couple the DTR signal to the reset line. The MAX232 buffered DTR signal should have the same voltage swing as the FTDI chip, IE: a 3.3 or 5v TTL/CMOS signal (depending on VCC).