stevech 
Anyone know of a PC-side program for bootloading an AVR using the protocol that Atmel's AVRprog uses, but having a graphical user interface?
I searched the projects files, didn't find one.
(I am talking about serial port bootloading, not the ISP, and where the AVR chip is on a PCB, not in a development system).
I'm using mega8 with asm language bootloader that is compatible with AVRprog.
mikehg1 What operating system? Windows, Linux ....
I re-wrote Atmels command line OSP to a GUI that I call OSP II. It still needs a little attention though. I had stopped working on it when I got tied up with a project at work. The hard part is finished, just the fun stuff left to do now,( Bells and whistles) :) This is written to run under Windows, let me know if you would like a copy?
Mike H.
RetroDan 
This is a snippet from another post.
I have NOT checked it out myself yet, but you might find it useful.
If you do, please report back, as I'm interested also. Thanks.
ATMEL also suggested the open source version of ARRProg. ARVOSP see
http://www.atmel.com/dyn/resources/prod_documents/doc2568.pdf
I'd like a copy!
What's it written in?
Rgds, Martin
stevech What operating system? Windows, Linux ....I re-wrote Atmels command line OSP to a GUI that I call OSP II. It still needs a little attention though. I had stopped working on it when I got tied up with a project at work. The hard part is finished, just the fun stuff left to do now,( Bells and whistles) :) This is written to run under Windows, let me know if you would like a copy?
Mike H.
If you wouldn't mind sending or posting, thanks. Win XP is where I do AVR development.
I looked at Atmel's open source (C++) GUI.
I'm not learned in C++, just C and VB6 and asm of all sorts.
mikehg1 Disclaimer on :)
I have not done extensive testing, any use is at the users own risk!
Disclaimer off
I have successfully erased, programmed and verified and read back using an AvrProg comp. bootloader. The ISP functions have not yet been tested at all, if anyone is feeling adventurous then give it a go :)
The program is written in BCX, The Basic to C translator by Kevin Diggins. I've included the full source along with the C source which should compile with any C or C++ compiler.
The Auto button and ranges are the only options not yet enabled, the code is there already, just haven't had time to do anything else with this.
There are some things I haven't decided on how I would like to setup, such as using a Tab UI or Popup dialogs, anyone have a preference?
Suggestions and bug reports would probably motivate me to polish things up! :o)
http://esnips.com/web/AtmelAVR
EDIT: BTW, the included executable (Compiled with PellesC) is a whopping 83K, not too bad considering the original is over 1 Meg!
Mike H.
mikehg1 Update to AvrOspII: Version .002
http://esnips.com/web/AtmelAVR
New/Changed:
More bounds checking and a few buggers fixed!
Changed to Tabbed interface
Auto Device detection
Memory range enabled
Clear button for log view
Fuse/Lockbit settings
Communication settings
OscCal value read/write
Maybe this should be added to the academy projects?
Mike H.
stevech I downloaded the first version. I spent maybe 20 minutes reading, fooling.
I was intimidated by how much work it seemed I'd need to do - as a noob, to get the LCC running and learn how the Basic code generator mates up. I'm sure it seems simple to Mike et al who've worked with it. I'm spoiled by the packages like the WinAVR and AtmanECL that load and go with an IDE in a few minutes.
Maybe I'll get the gumption to tackle it.
dharper If you can hold off for about another week or so, I'm in the process of writing an article that shows how to quickly and easily generate a GUI based program on the PC end that can be used to control AVR hardware (and for free!). I use this approach for a variety of projects, including a downloader to the bootloader on my devices.
Dave
mikehg1
I was intimidated by how much work it seemed I'd need to do - as a noob, to get the LCC running...
Maybe I'll get the gumption to tackle it.
It is much easier than it looks, the routine is normally:
Write your program using your favorite text editor.
Run : bc myprogram.bas
mycompiler myprogram.c
done!
*mycompiler* can be LCC, PellesC, Borland C++, MS Visual C++, MinGW C++, OpenWatcom C++, Digital Mars C++
There are readily available batch files already written that will automate the above process that can be called from most editing programs.
If you need any help, feel free to ask.
Of course if you have no need or desire to make your own modifications then there isn't any need to do anything other than run the supplied executable.
Mike H.
stevech OK so I dived into this.
First thing I tried was merely running the EXE as-is.
For some reason it cannot talk to my Atmel ISP on COM1.
AvrStudio and AVRProg can.
I double checked the usual - no other program competing for COM1, etc.
Ideas?
mikehg1 Is the baud rate set to 19,200 ?
What message are you getting when you try to connect?
Thanks,
Mike H.
stevech baud rate is 19.2
I tried COM1 on which the Atmel ISP is connected and works OK with other programs.
I tried COM3 which is connected to AVR's serial port to talk to bootloader code (though maybe I need to code a certain programmer ID, but that bootloader works with AVRProg.exe.
"timeout during COM-port read operation" for COM1 which is a generic motherboard chip serial port.
Windows XP Pro.
mikehg1 Atmel specifies "AVR ISP" for ISP programmers and "AVRBOOT" for bootloaders. What ID are you returning in your bootloader? Hmmm....I don't recall if the specs call for the ID to be case sensitive. I'll upload a version of the executable with the case sensitivity removed, let me know if that makes any difference?
Thanks,
Mike H.
mikehg1 I uploaded AvrOspII_Test.zip to : http://esnips.com/web/AtmelAVR
mikehg1 Update to AvrOspII
http://esnips.com/web/AtmelAVR
New/Changed: Version .250
Made programmer id$ case insensitive
Fixed a bug when using blockmode programming
(It works now!) :)
Added a progress bar for reading and writing Flash
(Bootloader mode only at the moment!)
Things to do/add:
Remember last settings
Test ISP mode
( I currently don't have an original Atmel ISP, I suppose I could just construct one)
Auto serial numbering
Auto Erase/Flash count
Add xml parser for Fuse/Lockbits settings to enable user friendly settings much like that in AvrStudio
Finish syncronizing commandline parameters with the GUI
Add a true silent mode to allow invoking from the command line without the GUI
These are some of my goals. If anyone has anything to add or interest in the priority of any of the above then feel free to comment.
Mike H.
stevech I tried the newer AvrOspII with my mega8 serial port bootloader.
OSPII says: Supported Programmer Type Not Found
AVRProg from Atmel works OK.
here's the ID string coded in my asm for the "S" command
Soft_Id: .DB "AVR-M8B", 0
But this code looks for another ID (noting that AVRProg accepts the string, above). Maybe AVRProg accepts anything since the "S" command was answered, it must be a bootloader!
if(openChannel(port,baud))
{
strcpy(programmerID,ucase(readProgrammerID(serialHandle)));
if(str_cmp(programmerID,"AVRBOOT")==0)
{
prog=&Bootloadprog;
}
else if(str_cmp(programmerID,"AVR ISP")==0)
{
prog=&ISPprog;
}
else
{
LogMsg(join(2,"Supported programmer not found on Com Port",str(port)));
closeChannel();
continue;
}
mikehg1
But this code looks for another ID (noting that AVRProg accepts the string, above). Maybe AVRProg accepts anything since the "S" command was answered, it must be a bootloader!
Why must it be a bootloader? ISP programmers respond to the "S" command also. Maybe any response other than "AVR ISP" should just default to Bootloader mode.
You said you also tried with an Atmel ISP programmer. What ID does AVRProg show when connected to this? I constructed an ISP programmer to the AVR910 specs and it worked like a charm here :)
Thanks,
Mike H.
stevech I confused myself, I guess.
I was asking if the code, as shown above, rejects the ID "AVR-M8B"; it appears to do just that, whereas AVRprog accepts the ID.
As to the ATmel ISP, I didn't intend to use that with open OSP-II.
mikehg1 I'll change it to default to Bootloader mode for any 7 character ID other than "AVR ISP". I'm finishing up a few other changes right now, I'll let you know when the update is available.
Thanks,
Mike H.
mikehg1 New/Changed: Version .300
Rearranged the GUI a little
Bootloader mode is now the default for any ID$ other than "AVR ISP"
Changed the COM timeout back to 5 seconds to rid false timeout warnings
when writing large EEPROMS. I'll make this dynamic in the next version.
Added full support for reading/writing all available Osc. Cal. values.
(Value can be written to EEPROM or Flash)
Added Read Signature.
Added Avr Studio style Fuse and Lockbit settings.
This allows 3 ways to set fuse and lock bits
1. EZ Avr Studio style
2. Entering a Hex value
3. Binary representation
Changing by means of any of the above will automatically update the other to reflect the change. (Makes a handy interpreter!)
Mike H.
stevech A little forward progress.. but...
Downloaded new version.
Ran it.
First I change config: COM1 at 38400 baud (that's what my mega8 bootloader uses) [it would be nice if OSP-II remembered this]
Clicked DETECT without using the device selection list. Result was
Unrecognized ID on com1- defaulting to bootloader mode
Found !9 250 // I don't know what that means
Entering Programming mode
Signature = 0x32 0x20 0x39
Leaving Programming mode // apparently an E command was sent causing my bootloader to quit
-------------
// next I chose the mega8 from the GUI's pull-down list. It showed a signature. Not like that above.
then I did DETECT again. Now I got different problems - signatures don't match.
Looks like the signature bytes are CR/LF and Spaces.
The asm code for the 3 signature bytes are these in response to the "s" command:
.equ SB1 = 0x07 ; Signature byte 1
.equ SB2 = 0x93 ; Signature byte 2
.equ SB3 = 0x1e ; Signature byte 3
Sorry - this bootloader does work with AVRProg.
Also - at one point I had to click on the window close red-X because the program was stuck forever in a loop sending the A command and getting the wrong response. When I closed the GUI window, the process remained, and had COM1 still open. I used the task manager to kill the process - though the GUI window did close.
[/img]
mikehg1
Found !9 250 // I don't know what that means
This is what your bootloader responded with? Can you send me a copy of your bootloader code?
mikehg_67 at yahoo dot com
Entering Programming mode
Signature = 0x32 0x20 0x39
Leaving Programming mode // apparently an E command was sent causing my bootloader to quit
What signature do you have in your bootloader?
If you select your device from the list, you should be able to perform functions normally.
The one main difference between AvrProg and OspII is that AvrProg uses a separate device code to identify the device, while OspII uses the device signature.
"Leaving Programming mode" means OspII has finished the last command.
'E' exit is not sent here.
I'll fix the handling of the incorrect response, it isn't in an endless loop, but I'm sure it seemed like it :)
I was trying to wait until I had all the main options in place before adding a remember settings, but I suppose I could go ahead and implement it now.
Thanks for the feedback,
Mike H.
mikehg1 Hi George,
Thanks for the kind words and the feedback!
There is no need to send the address at every FLASH/EEPROM block access. Just ask the programmer if it supports Address Autoincrement ('a'). and if the latter does it will reply with the character 'Y': Set the starting address, and leave the rest of the addressing job to the hardware/firmware.
This is currently implemented for non-block access. I'm not sure why it wasn't for block mode as ported from the original OSP from Atmel. - I'll add this to my list.
I think that there is no need to program the totally empty FLASH pages (containing only "0xFFFF"). It takes its time and wears out the FLASH additionally, though it has already been done during the erase cycle.
I agree. Although Flash wear isn't really a concern since address 0 to xxx is certain to fail berfore or at the same time in which case it's probably time for new chip anyway :)
This is already on the list, in addition I plan to add the option to exclude empty pages from the file when reading as well.
Taking a step further, the empty part of a partially full page can also be skipped from filling the page buffer: Instead of sending all the remaining 0xFF bytes, the programmer can request a smaller page fraction to be programmed, and send the new address afterwards.
Partial pages are programmed in byte mode. I believe block mode requires a full pagesize.
There is also no need to go beyond the EOF address during programming or verifying. If anybody needs to do this, there is the option of using the manual range programming. It is annoying to see block-access failure reports at the log window, though the programming has successfully been done.
I'll add the copy to clipboard (good idea btw!) ,the saving of settings and Exit functions in the next update. (Sometime today ...)
PPS. You may spam my mailbox if I am asking for too much
Nahhh...wouldn't do that :) It's good to get some feedback really, feel free to comment or suggest all you want.
Thanks,
Mike H.
mikehg1 New/Changed: Version .350
Added a Copy to clipboard button for the Logbox
Added "Send Exit" button
Enabled the "Auto" button
This will program both Flash and EEPROM as well as the auto options
that are checked.
If either file name is not specified then then the operation will be skipped
for that part of the programming. If both file names are nissing the
entire operation will abort without doing anything.
Added a checkbox to the Auto setting for Send Exit after programming
Operations should abort faster now after receiving a bad response.
Communication setting are now saved on exit.
What other settings would you like to have saved?
Mike H.
mikehg1
About the block access failure reports, the program attempted to write to the boot section, something my bootloader restricted, not acknowledging the write command, replying '?'.
AvrOspII ignored the write refusal and continued trying to write a few more blocks, way beyond the EOF address. The last address attempted to write to was 0x0F60, while the test file ended at address 0x0826.
Hi George,
I've been unable to duplicate this.
For instance, I read the application from a butterfly and specify the read range as
0x00 to 0x37FF and save to a file. If I then uncheck manual range and verify, it only trys to verify to 0x37FF. If I then program the same file it only programs to address 0x37FF.
Would it be possible to send me the file you are programming?
Thanks,
Mike H.
stevech here's the source and hex for the mega8 bootloader I've used successfully with AVRProg. It's compiled for a 10MHz crystal and 38.4Kbaud
It's a 256 word (512Byte) boot section.
mikehg1
here's the source and hex for the mega8 bootloader I've used successfully with AVRProg. It's compiled for a 10MHz crystal and 38.4Kbaud
Hi Steve,
The code you uploaded is configured for 19,200 baud.
You loading UBBR with the constant 0x20 (32), It should be 0x0F for 38,400 baud.
Can you try OspII set at 19,200 and see?
Thanks,
Mike H.
mikehg1 Thanks for the update George.
No apology needed. I'm just glad everything is working :)
Take care,
Mike H.
kkontak Mike, it looks like a very nice job.
Actually there is some functionality that would be usefull:
Loading from a file and programming fuse/lock bits. I know that ATMEL's AVRStudio doesn't generate any data file with these info related to project(like Microchip does) and it has been discussed several times in AVRFreaks, but we can generate manually this file and have it attached in the project's folder, for use with your programmer.
Personally I'm using Ponyprog to program AVR's by ISP and it has scripting support. This way I'm creating a script file and I don't have to check boxes every time I program a new device with this code.
Here is an example to get an idea:
#ponyprog2000.exe v2.06f_BETA script.e2s
#------ START --------
#Programming sequence
PAUSE "This is a burning script for [BatCharger4x1.2V_BTLAVRProg] with ATmega16. Continue?"
SELECTDEVICE ATMEGA16
CLEARBUFFER
LOAD-PROG batcharger4x1_2v_BTLAVRProg.hex
#LOAD-PROG E:\AVRasms2\batcharger4x1_2V\batcharger4x1_2v.hex
#LOAD-PROG
LOAD-DATA batcharger4x1_2v_BTLAVRProg.eep
#LOAD-PROG E:\AVRasms2\batcharger4x1_2V\batcharger4x1_2v.eep
#LOAD-DATA
#PAUSE "Is the Interface setup: [Parallel], [Avr ISP I/O], [LPT1] ?"
PAUSE "Is the Interface setup: [Serial], [SI Prog API], [COM1] ?"
#CALL ponyprog2000.exe
#PAUSE "Connect and power-up the [BatCharger4x1.2V] PCB. Are you ready?"
PAUSE "Connect and power-up the PonyProgrammer PCB. Put an ATmega16 in socket U3. Are you ready?"
RESET
#READ-CALIBRATION 0x3ff
ERASE-ALL
WRITE&VERIFY-ALL
#READ-FUSE
#READ-LOCK
#EDIT-SECURITY
#DELAY 5000
#Pay attention to NOT disable SPIEN! Leave SPIEN=1.
#(note that a 1 means programmed)
#FuseH: "OCDEN ","JTAGEN ","SPIEN ","CKOPT ","EESAVE ","BOOTSZ1 ","BOOTSZ0 ","BOOTRST "
# 0 0 1 0 0 0 1 1
#WRITE-FUSE 0x23
#FuseL: "BODLEVEL ","BODEN ","SUT1 ","SUT0 ","CKSEL3 ","CKSEL2 ","CKSEL1 ","CKSEL0 "
# 1 1 1 1 0 0 0 0
#WRITE-FUSE 0xF0
#Does the below command work ? YES!!!!
WRITE-FUSE 0x23F0
##############################
#Defaults FuseLock bits are:(???, not sure!)
#FuseH: "OCDEN ","JTAGEN ","SPIEN ","CKOPT ","EESAVE ","BOOTSZ1 ","BOOTSZ0 ","BOOTRST "
# 0 1 1 0 0 1 1 0
#FuseL: "BODLEVEL ","BODEN ","SUT1 ","SUT0 ","CKSEL3 ","CKSEL2 ","CKSEL1 ","CKSEL0 "
# 0 0 0 1 1 1 1 0
#WRITE-FUSE 0x661E
#Lock: {X,X,"BootLock12 ","BootLock11 ","BootLock02 ","BootLock01 ","Lock2 ","Lock1 "}
# 0 0 0 0 0 0 0 0
##############################
#Lock: {X,X,"BootLock12 ","BootLock11 ","BootLock02 ","BootLock01 ","Lock2 ","Lock1 "}
# 0 0 0 0 0 0 1 1
WRITE-LOCK 0x03
PAUSE "Read Fuse-Lock bits to check if they are the same as in the image. Continue?"
EDIT-SECURITY
RESET
#------- END ---------
You don't need to do scripting, a small data file with the fuses handwritten in it and a filename associated to FLASH's hex filename would be fine for me.
[Joke]Send me the bill![/Joke]
Kyriakos
mikehg1
You don't need to do scripting, a small data file with the fuses handwritten in it and a filename associated to FLASH's hex filename would be fine for me.
I was already thinking of something like this. Allow all of the current settings to be saved to a project file that can be loaded on demand. In addition there could be an option to load the last project on startup or a specific project. This would allow you to save a template with your preferred startup settings.
Would something like that work okay for you?
Thanks,
Mike H.
P.S. You can make the check out to Mike's early retirement fund :)
stevech Quote:
here's the source and hex for the mega8 bootloader I've used successfully with AVRProg. It's compiled for a 10MHz crystal and 38.4Kbaud
Hi Steve,
The code you uploaded is configured for 19,200 baud.
You loading UBBR with the constant 0x20 (32), It should be 0x0F for 38,400 baud.
Can you try OspII set at 19,200 and see?
Thanks,
Mike H.
stevech Quote:
here's the source and hex for the mega8 bootloader I've used successfully with AVRProg. It's compiled for a 10MHz crystal and 38.4Kbaud
Hi Steve,
The code you uploaded is configured for 19,200 baud.
You loading UBBR with the constant 0x20 (32), It should be 0x0F for 38,400 baud.
Can you try OspII set at 19,200 and see?
Thanks,
Mike H.
Mike,
Nice work!
I did accidently uncover a minor bug: if DeviceList.dat is not in the directory that AvrOspII.exe is started, I get the attached application error.
Don
mikehg1 Nice work!
I did accidently uncover a minor bug: if DeviceList.dat is not in the directory that AvrOspII.exe is started, I get the attached application error.
Thanks Don,
This is the result of working on a program from two computers, sometimes the changes don't get merged :( I made the fixes. The intended behavior is if the Devicelist.dat file doesn't exist it would rebuild a new file (if AvrStudio is installed). I'll be uploading an update here shortly.
I'll post to the original OSPII thread so as to not hijack Steve's thread anymore than i already have :)
Mike H.
stevech what bootloader code (mega8 or other) is known to work with OSP II?
I cannot get my code to work - it tries to startup, but falters in the exchanges.
----
Where's the latest OSP II code uploaded?
mikehg1 Hi Steve,
The current verison is .360 and can be dowloaded from:
http://esnips.com/web/AtmelAVR
Did you ever try changing the baud rate to 19200 ?
I've used at least 5 different bootloaders without any problems. Other than the baud rate issue, it looked like your code should work fine.
Let me know if there is anything I can help with,
Mike H.
what bootloader code (mega8 or other) is known to work with OSP II?
Note that at startup, it waits 5 seconds for an Esc character. If not received, it jumps to the application. This allows you to leave the BOOTRST fuse set.
Don
mikehg1 Something I have noticed in Steve's bootloader and the one that Don posted is the Id is being sent from the start before being asked for. AFAIK, nothing should ever be sent from the bootloader that has not been requested. The host will just have to discard this data anyway in an attempt to stay in sync.
Mike H.
stevech Hi Steve,The current verison is .360 and can be dowloaded from:
http://esnips.com/web/AtmelAVRDid you ever try changing the baud rate to 19200 ?
I've used at least 5 different bootloaders without any problems. Other than the baud rate issue, it looked like your code should work fine.
Let me know if there is anything I can help with,
Mike H.
mikehg1 Steve,
Why are just quotes showing? Are you adding replys to these?
Mike H.
stevech Yes, but apparently I dozed off and someone deleted my erudite comments while I napped. Then hit SUBMIT. I must be on Ambien.
mikehg1
Yes, but apparently I dozed off and someone deleted my erudite comments while I napped. Then hit SUBMIT. I must be on Ambien.
Why would your comments have been rude?
I would like to help here, but it's difficult without some kind of feedback.
Take care,
Mike H.
Something I have noticed in Steve's bootloader and the one that Don posted is the Id is being sent from the start before being asked for. AFAIK, nothing should ever be sent from the bootloader that has not been requested. The host will just have to discard this data anyway in an attempt to stay in sync.
Don
mikehg1 Hi Don,
I understand now, I didn't realize the intended operation was to be started by a separate terminal program first. This was more of an observation. The problem Steve is having seems to be a mistaken baud rate. The software he is using has constants and calculations setup to automatically calculate the UBBR value, but the constant is never used, instead UBBR is hardcoded with the value 0x20.
Thanks,
Mike H.
stevech I think I uploaded older source - I will check but I doubt I'd really make that mistake. I never make mistakes, but I may be wrong
I'm going to renew working on this bootloader. I took an adventure in to Megaload - what a mess. Works only for the simple case of UART at 19.2 direct on a serial port. Hard coded things in the bootloader, delay loop that works only at 19.2, very crashy PC side software in C# for .NET.
I'm trying to do bootloading at higher speeds and via a LAN and sockets and an Edgeport 8 port USB-Serial. So the bootloader to PC handshakes/protocol should be tolerant of delays.
stevech And now...
I fixed two stupid mistakes in the bootloader - CPU crystal missing a zero and the UART speed constant.
It now works fine with COM1 on the PC at 19.2K and 56K.
There is a problem with entering the boot from my application - I do turn off the UART and interrupts then wait for a full watchdog timer reset before the boot runs, but none the less, OSP II gets left-over characters from my applicaiton. Maybe Windows doesn't purge the receive port buffer when OSP opens it. Anyway, if I just hit DETECT again, it usually is correct.
But the problem I'm stumped on goes like this:
I want to download across my network from a development PC to the run-time PC into which the AVR serial port is connected. These are some distance apart. I have several ways to access the remote PC's serial port from the development machine. The easiest is an WiFi device that has a serial port. (Moxa NPort).
I haven't gotten OSP II to work with the NPort connected to the AVR serial port.
The basic comm is fine - I can use a terminal program and keyboard to the bootloader just fine. Press
(I don't have BCX setup here)
If I do the same thing using my keyboard and a terminal program - it works, via the NPort. But I'm not sending the 10
mikehg1 Hi Steve,
Glad to here things are starting to look up.
I'll add a purge after opening the Com port in the next update. That should take care of any spurious data that might be hanging around.
Are you saying that you can successfully auto detect the device with OSP II via NPort but can not verify or program? If this is the case could you use a monitor program, such as the one George mentioned to see what activity is happening?
The extra escapes sent are mainly to help with syncronization and calibrating when using the UART for calibration. These should not be causing any problems though.
Thanks,
Mike H.
stevech Hi Steve,Glad to here things are starting to look up.
I'll add a purge after opening the Com port in the next update. That should take care of any spurious data that might be hanging around.
Are you saying that you can successfully auto detect the device with OSP II via NPort but can not verify or program? If this is the case could you use a monitor program, such as the one George mentioned to see what activity is happening?
The extra escapes sent are mainly to help with syncronization and calibrating when using the UART for calibration. These should not be causing any problems though.
Thanks,
Mike H.
Yes - Via the NPort auto-detect works. But when I hit PROGRAM, It fails on the get programmer type cmd - this is what's sent immediately after the 10 escape chars. Looking at the AVR side, it should receive and discard / ignore all the escapes and send no response to them. This is what it does using my keyboard connected via the NPort to the AVR. But for some reason, the timing using OSP doesn't work. Something to do with the blast of escapes is all I can guess. The way I read the AVR code, it should ignore the escapes then respond to the S. But it doesn't. Maybe I can write a VB script to do the same thing. And I have a serial monitor program too.
stevech Mike
I've done a lot more testing with the across-wireless-LAN situation, uising a serial port monitor.
I think what's happening is that there needs to be a delay in OSP II
1. Aftter opening the com port and before sending the first byte
2. Just before closing the com port.
The delay should be like 200 miliseconds or maybe 1 second to be safe.
My tests indicate that all is perfect using my terminal program which has the port already open prior to sending. I think there's some ethernet housekeeping upon open/close that somehow is affecting things. Once in a while it works.
The other items is the need to make sure the serial receiver buffer on the PC is purged after sending the ten escape chars - because the escape chars (in my case) cause the running program to shut down and turn on the watchdog to force a reboot of the AVR after a second or two. You might also need to change the "TIMEOUT" constant in OSP II from 5 to maybe 10 due to the application not seeing the escape quickly. These are important where the bootloader is invoked remotely - nobody there to push the RESET switch.
mikehg1 Hi Steve,
I'll try to upload an update later this evening.
A couple of things though. Shouldn't there be a WD reset within your "while escape loop"?
Also, if you are not initiating contact through a terminal program first, it would be best to not send the programmer string before it's asked for.
I'll add some adjustable parameters to the ini file that will let you experiment with delays if needed.
Mike H.
