Sk­etch-upl­oad via RS232 work­s only for one time

[GoogleCodeExporter]

Hello,

i am trying to upload sketches on a AVR-NetIo with Atmega32 via RS232 
direct-connection to the PC with a DB9-cable (a straight RS232-cable on the PCs 
RS232-Interface (=/dev/ttyS0), nothing with FTDI232-Breakout-Board), and have 
the following strange effect:

The upload works perfectly well, if i do it the first time immediately after i 
have burned the bootloader fresh onto the board. (Which i do with an 
stk200-compatible parallel-port-programmer.)

Afterwards i am not able to do any futher sketch-upload; instead i am getting 
an error which suggests, that the avrdude receives no response from the Netio 
on the serial line.

If i am burning again a fresh bootloader the i am beeing able again to do a 
sketch upload for just one time.

For demonstration of the effect i logged the avrdude-call from the Arduino-IDE 
and do it here manually from the shell (i am on linux), so we can see better 
the output and error-messages plus we can exclude that the IDE may be part of 
the problem.

Her the demosntration session, where you can see at first the call for the 
bootloader-burning on parallel port, which works fine, then the first 
sketch-upload which also works fine and then the same sketch-upload again, 
which gives the error.

=============================

densai:/usr/local/src/arduino-1.0.1_avr-netino/hardware/tools# ./avrdude 
-C./avrdude.conf -p atmega32 -P /dev/parport0 -c stk200 -U 
flash:w:../avrnetio/bootloaders/optiboot/optiboot_anio32.hex -u -U 
lfuse:w:0xff:m -U hfuse:w:0xcf:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9502
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file 
"../avrnetio/bootloaders/optiboot/optiboot_anio32.hex"
avrdude: input file ../avrnetio/bootloaders/optiboot/optiboot_anio32.hex auto 
detected as Intel Hex
avrdude: writing flash (32754 bytes):

Writing | ################################################## | 100% 10.21s

avrdude: 32754 bytes of flash written
avrdude: verifying flash memory against 
../avrnetio/bootloaders/optiboot/optiboot_anio32.hex:
avrdude: load data flash data from input file 
../avrnetio/bootloaders/optiboot/optiboot_anio32.hex:
avrdude: input file ../avrnetio/bootloaders/optiboot/optiboot_anio32.hex auto 
detected as Intel Hex
avrdude: input file ../avrnetio/bootloaders/optiboot/optiboot_anio32.hex 
contains 32754 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 8.99s

avrdude: verifying ...
avrdude: 32754 bytes of flash verified
avrdude: reading input file "0xff"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xff:
avrdude: load data lfuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xcf"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xcf:
avrdude: load data hfuse data from input file 0xcf:
avrdude: input file 0xcf contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified

avrdude done.  Thank you.

densai:/usr/local/src/arduino-1.0.1_avr-netino/hardware/tools# ./avrdude 
-C./avrdude.conf -q -q -patmega32 -carduino -P/dev/ttyS0 -b115200 -D 
-Uflash:w:./myprogram.cpp.hex:i -v

avrdude: Version 5.11, compiled on Sep  7 2011 at 19:34:16
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "./avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyS0
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
         AVR Part                      : ATMEGA32
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom         4    10    64    0 no       1024    4      0  9000  9000 0xff 0xff
           flash         33     6    64    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  2000  2000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  2000  2000 0x00 0x00
           lock           0     0     0    0 no          1    0      0  2000  2000 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           calibration    0     0     0    0 no          4    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 3
         Firmware Version: 4.4
         Vtarget         : 0.3 V
         Varef           : 0.3 V
         Oscillator      : 28.800 kHz
         SCK period      : 3.3 us
avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0

densai:/usr/local/src/arduino-1.0.1_avr-netino/hardware/tools# ./avrdude 
-C./avrdude.conf -q -q -patmega32 -carduino -P/dev/ttyS0 -b115200 -D 
-Uflash:w:./myprogram.cpp.hex:i -vvvv

avrdude: Version 5.11, compiled on Sep  7 2011 at 19:34:16
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "./avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyS0
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

densai:/usr/local/src/arduino-1.0.1_avr-netino/hardware/tools# 

===================================

What version of the product are you using? On what operating system?

I am using the 19Jan2012-version ov avr-netino, on linux.  The avrdude-version 
ist 5.11 and part of the IDE, it already knows the -c arduino option.

Please provide any additional information below.

To confirm that the effect is real and not a problem of my individual board i 
tested it on two different NetIo-boards, its the same on both.

I furthermore did of course the hardware-modifcation for the auto-reset feature 
and i tried it in all three possible ways:

1. via DTR, with 100n-cap between pin4 of the db9-connector and pin 9 reset-pin 
of the atmega plus the diode.

2. via RTS, with the 100n-cap between pin 9 of the Max232 and pin 9 of the 
atmega

3. via DTR with 100n-cap between pin 9 of the Max232 and with pin 4 of the 
DB9-connector going to pin 8 of the Max232 (and have before the connection 
between pin7 of the DB9 and pin 8 of the Max232 cutted through).

Since the one-time-sketch-upload-effect happened on all three versions i assume 
that each of them works and the effect has nothing to do with an auto-reset 
problem.

I'm wondering since the first sketch-upload works, what might become changed by 
that what prevents any further sketch-uploads and if this may have something to 
do with the fuses. I am no expert on fuses ;)  so i have no idea, but however 
thats why i posted the whole demonstration with the calls where the fuses 
parameters can be seen.

Hope you may have an idea.

Best regards,
Oliver

P.S.: Apart from my problem the whole avr-netino port is a great work, Kudos 
for that!

Original issue reported on code.google.com by cas...@web.de on 7 Oct 2012 at 7:50

[GoogleCodeExporter]

Hi Oliver,
I'm relatively sure that your problem is caused by auto-reset:
If you burn the bootloader it will infinitively wait for an upload, after you 
have loaded a sketch, the bootloader will start the sketch after a short time.

So if you are sure that you have build the auto-reset hardware correctly, you 
should check your RS232 cable if the handshake lines (DTR/RTS) are really 
connected. Then you should check if your RS232 port works.

On the other side you can try a different avrdude version. I had similar 
problems with avrdude from arduino-1.0 so I chanced the programmer type from 
stk500 to arduino. May be stk500 works for you.

You also can try to make the reset by hand in the moment you start avrdude, but 
I think you a time window for about 0.5 seconds only.

Its is not a generally problem with linux, I use it myself.

Original comment by mic.maas...@gmail.com on 8 Oct 2012 at 7:16

• Changed title: Check if reset puls is really comming
• Changed state: Accepted

[GoogleCodeExporter]

.

Original comment by mic.maas...@gmail.com on 8 Oct 2012 at 7:18

• Changed title: Sk­etch-upl­oad via RS232 work­s only for one time

[GoogleCodeExporter]

Hello Mic,

thanks for your immediate reply.

I agree with you that the one-time-upload-effect must not have anything to do 
with what the first sketch-upload may change (like fuses; in fact it doesnt set 
any fuses), but merely with that what happens before. Meaning, with the 
circumstance, that after the fresh bootloader upload the system is in a kind of 
virgin state that is similar or comparable to the reset-situation.

But the problem doesnt seem to be, that no reset happens, nor that the 
rs232-port isnt connected properly.

But let me report successively:

What i just tried was finding out whether the auto-reset impulse happens. 
Therefore i connected my volt-meter between GND and Pin 9 of the Max232 
(whereas the input-pin 8 was connected to pin7 of the db9 = RTS,but i think it 
doesnt make a difference from which line it comes from).

So, in the original state the voltmeter shows 4.93V.

If i try to upload a sketch i goes for approximately 5 seconds to 0V. Thats of 
course far longer than it usually should be, the normal duration is about 22ms 
if i am right. However i think this is due to the fact, that it doesnt get a 
response and therefore runs in a timeout situation.

To confirm that, i connected a led to arduino pin 13 and took as upload-sketch 
the blink-example, which i changed in a way, that it doesnt blink, but shines 
permanently. I wanted to see, how long it stays of during the reset phase.

The i loaded a fresh bootloader via parallel port. Then i loadet the sketch 
with the led-programm. Now the volt-meter shows the 0V for a short fraction of 
a second and then wents back to 4.93V. Then the programm was started and the 
led shines permanently.

Now i have an interesting situation: If i try to load the sketch a second time, 
the led stops shining for a fraction of a second and then continues shining 
(meaning  starting again the programm), but the volt-meter stays at 0V for 
about 5 seconds, before returning to 4.93V.

I find it interesting that the Atmega is able to restart the bootloader and/or 
the program again while its reset-line is down but maybe only the impuls itself 
counts and not its duration, i dont know.

However, the rough picture seems to me to be at the moment, that during the 
second sketch upload the avrdude seems to expect an answer from the bootloader 
which doesnt happens.

For taking a closer look at the exact moment when this occurs i attached a file 
which contains the output of the first (and functioning) sketch-upolad with 
verbose mode beeing -vvvv.

The interesting part ath the beginning looks like this:

===============================

densai:/usr/local/src/arduino-1.0.1_avr-netino/hardware/tools# ./avrdude 
-C./avrdude.conf -q -q -patmega32 -carduino -P/dev/ttyS0 -b115200 -D 
-Uflash:w:./myprogram.cpp.hex:i -vvvv

avrdude: Version 5.11, compiled on Sep  7 2011 at 19:34:16
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "./avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyS0
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
         AVR Part                      : ATMEGA32
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53

====================================

Here we can see perfectly well the communication:  The avrdude sends three time 
the character-sequence  

0 [30]   [20]

and then the bootloaders answers with

avrdude: Recv: . [14]
avrdude: Recv: . [10]

this happens immediately after setting the baud-rate and then seems to continue 
with checking the CPU-Type.

During the second sketch-upload the avrdude sends its usual "0 [30]   
[20]"-sequence, but then nothing seems to come back, which results into making 
the avrdude wait for about 5 seconds o an answer, and then throwing the 
error-message

avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

This would normally lead me to the question whether there may be something 
wrong with the TXD-Line, but that cannot be, because in the first sketch-upload 
 the TXD-Line works well and sends back the characters 14 and 10.

I have no clue.

Could this be perhaps some kind of timing problem with the avrdude ?

I took a look at savannah.gnu.org, but the version 5.11 semms to be the newest 
version of avrdude.

I also followed your advice and tried the stk500 as -c parameter, but it shows 
exactly the same picture, with the exception, that it runs in a loop and try 
the request over and over again, then it gets a timeout and then continues with 
that loop again (until i break the loop with ctrl-c).  Meaning, this also seems 
to wait for an answer of the bootloader.

What really would interest me, is the question whether it works for you or 
someone else with exactly the same setup. Meaning, does it really works for you 
with using the configuration with a simple DB9-cable at the rs232-port (=ttyS0) 
? Or do you use a ftdi232-usb"ttl-converter ?

Thanks for your attention and have a nice day,

regards, Oliver

Original comment by cas...@web.de on 8 Oct 2012 at 11:52

Attachments:

• dum2

[GoogleCodeExporter]

Hi Oliver,

at first let me answer your last question:
I only have a laptop with usb and no real rs232 port, so I only can confirm 
using an usb-rs232 cable. 
But I think that some of the other users can confirm that a RS232 port works as 
well, can't you???

I don't know what your problem is exactly but I can write down my thoughts:
a) you can measure the reset signal behind the max232, so your port, cable and 
max232 should be correct. The only thing here is the capacitor between the 
max232 and the reset pin of the Mega32. The capacitor make from the long pulse 
(while port is opened) a short reset pulse. Thats why your sketch runs while 
you measure 0V at the max232. Can you check if you have the right capacitance 
and really connected to the reset pin? -> you write that your led sketch will 
restart, so the hardware seems to be ok!

b) Serial communication seems to be ok, otherwise the first upload would also 
fail. 
c) Let me shortly explain what the boot loader dose:
- It starts on a reset and first checks if the reset was caused by the reset 
line, if not, it starts the sketch
- it waits a short time (~0.5 s) for a byte on the serial line, if none comes, 
it starts the sketch
- if there is no sketch (virgin boot loader) it will wail infinitely for a byte 
on the serial line

d) what could cause your effects:
- the bootloader is not started at reset: -> the BOOTRST fuse is not set, or 
the BOOTSZ fuses are wrong
- the bootloader can't verify the external reset: -> the bootloader hex-file 
doesn't match the mega32 = wrong bootloader

How do you burn the bootloader? By a call of avrdude or with the arduino ide?
Which file/board do you select? Are the fuses set correctly?

Hopefully this will help you to figure out what's wrong. I don't think its a 
point of the serial port.
-  

Original comment by mic.maas...@gmail.com on 9 Oct 2012 at 7:22

[GoogleCodeExporter]

Hi Mic,

problem is solved !!! ;)

The point d) of your last answer was leading to the solution.

I have used the wrong fuses, when burning the bootloader before:

-U lfuse:w:0xff:m -U hfuse:w:0xcf:m

This fuse-setting doesnt contain the BOOTRST.  Instead of this i have to use

-U lfuse:w:0xbf:m -U hfuse:w:0xde:m

I discovered this when i again checked the IDE-Output while bootloader-burning. 
 I remember darkly that i did that already in the early beginning, but since 
there were also settings of lockbits and other fuses then i was used to use, 
this seemed to me suspicious ;) and i was afraid to use it. Instead i used my 
usual avrdude-call from within the unix-shell to burn the bootloader and 
superficially it seems to work, so far.

However, this lesson gives me now a better understanding of how the bootloader 
works and what the fuses and lockbits are doing.

Many thanks for your fast responses and great support.

Whetherall it turned out now, that the reason for the problem was a quite small 
thing, which lays in a total different corner than i originally assumed (what 
happens often in programming ;)), i hope that our debugging-process may be 
helpful or useful for others as a small guideline for checking on he 
hardware-side the serial connection and the autoreset-feature systematically.

Thanks for your help and have a nice day !

With best regards,
Oliver

Original comment by cas...@web.de on 9 Oct 2012 at 10:26

[GoogleCodeExporter]

Hi Oliver,

I'm happy to hear about your success.

Best Regards,
Mic

Original comment by mic.maas...@gmail.com on 10 Oct 2012 at 6:54

• Changed state: Done