Bootloader - PC side- Compatible with Atmel AVRprog

Go To Last Post
53 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

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

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.

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

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

Last Edited: Mon. Apr 3, 2006 - 09:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd like a copy!

What's it written in?

Rgds, Martin

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

mikehg1 wrote:
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.

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

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.

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

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.

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

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.

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

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

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

Quote:

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.

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

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?

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

Is the baud rate set to 19,200 ?

What message are you getting when you try to connect?

Thanks,
Mike H.

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

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.

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

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.

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

I uploaded AvrOspII_Test.zip to : http://esnips.com/web/AtmelAVR

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

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.

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

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;
            }
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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.

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

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.

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

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.

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

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.

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

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]

Attachment(s): 

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

Quote:

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

Quote:

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.

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

Hi George,

Thanks for the kind words and the feedback!

Quote:

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.

Quote:

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.

Quote:

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.

Quote:

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.

Hmmm...It should not be trying to program past the EOF address. There's an option to fill unused memory with a specified character, but I have not enabled that yet. I'll output the starting and ending addresses to the Log view so you can verify where it's stopping.
Do you recall what the "block-access failure reports" said ?

I'll add the copy to clipboard (good idea btw!) ,the saving of settings and Exit functions in the next update. (Sometime today ...)

Quote:

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.

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

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.

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

Quote:

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.

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

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.

Attachment(s): 

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

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.

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

Thanks for the update George.
No apology needed. I'm just glad everything is working :)

Take care,
Mike H.

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

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

Practice Safe hex.

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

Quote:

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 :)

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

mikehg1 wrote:
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.

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

mikehg1 wrote:
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.

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

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

Attachment(s): 

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

Quote:

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.

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

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?

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

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.

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

stevech wrote:
what bootloader code (mega8 or other) is known to work with OSP II?

I posted the one I use in this thread. See my post of 17 Oct 2005. I've used this bootloader on the ATMega8, 16 and 32.

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

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

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.

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

mikehg1 wrote:
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.

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

Steve,

Why are just quotes showing? Are you adding replys to these?

Mike H.

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

Yes, but apparently I dozed off and someone deleted my erudite comments while I napped. Then hit SUBMIT. I must be on Ambien.

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

Quote:

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.

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

mikehg1 wrote:
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, I don't see this in the code (I didn't write it so maybe I'm mistaken). To use the bootloader I use, you have to first connect it to a terminal program and enter Esc within 5 seconds of power on. The bootloader then sends an acknowledgment (uart_msg) to the terminal that it is entering bootloader mode (as opposed to jumping to the application). After that, you disconnect the terminal program and attach a PC side compatible AVRprog utility. The bootloader then does nothing until it receives a character (other than Esc).

Don

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

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.

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

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.

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

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 and p and S and so on and all is fine. The DETECT in OSP II works. But VERIFY or PROGRAM fails. Error is "checking programmer type...". I see in the OSP code that it blasts out 10 characters then an 'S'. What happens next is the 5 second timeout on inputting a byte This is in FUNCTION readProgrammerID$.

(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 as fast with the keyboard. I wonder really if those 10 escapes do any good. Anyway, this is where I'm stumped at the moment.

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

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.

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

mikehg1 wrote:
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.

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

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.

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

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.

Pages