instigate bootload from remote device?

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

Am just getting up to speed on bootloading. I haven't seen how to deal with this situation in the info I've found.

I will not have physical access to the device, but will be connected via RS232. I will need to tell the device to go into bootload mode from the other side of the RS232 connection. What I've seen so far requires an input to a port pin to indicate to the device to bootload. Is there a common way to deal with what I'm trying to do?

Also wondering where to find a well documented bootloader. As I recall, Atmel has one on their site. Is there anything that may be better in some way? I'm using ICCAVR.

Thanks,
Scott Kelley

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

Any sofware method of instigating a bootloader is doomed to failure, if you want my opinion. What happens if the bootloading process is interrupted for any reason?
You might never be able to recover, since the software you're bootloading is responsible for recognizing some "unique" sequence of bytes or something.

The method I favour, is to use the DTR or RTS signal to control the reset line, this obviously requires a bit of extra hardware (diodes, transistor), and assumes that you have more than the basic 3 wire serial interface.
You could also detect a break condition with hardware, but if your device is behind a modem, for example, then I can't think of any foolproof system that wouldn't use substantial extra hardware.
What sort of RS232 interface are you talking about?

Four legs good, two legs bad, three legs stable.

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

I have had no trouble using the bootloader just as Scott wants.

I have used the RS232 connection to my PC, running Hyperterminal - without problems :-) - to communicate with my M128. I use a single letter instruction, coded into the normal code, to initiate a jump to the bootloader. Working with the bootloader, I can upload programs and eeprom from my PC to the M128 using Atmel's AVR ISP. Then entering 'E' to quit from the AVR ISP also tells the bootloader to jump to the program starting at address 0.

No problems, except for modifying a bootloader I found somewhere so that it would work with the M128.

Go for it!

admin's test signature
 

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

Why not just tell the running code to do a reset on it's own (by letting the watchdog time out).

Then when the cpu reboots, it'll boot into the bootloader - the bootloader tells the connected pc it's ready for the new program code - away you go!

Either that, or upload your new code to the cpu, the cpu saves that code into external ram (preferably flash/eeprom). Then the cpu does a reset and reprograms itself using the saved code while in the bootloader.

etc

Lexxy

admin's test signature
 

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

Well, 99% of the time it will work O.K., but you only need one failed or interrupted bootload and that's it. The application code that's supposed to kick off the boot isn't there any more. I would never trust such a system for a commercial application, but maybe I'm too cautious.

Four legs good, two legs bad, three legs stable.

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

P.S. I fail to see how "telling the running code to do a reset (by letting the watchdog time out)" adds anything to the equation. It still supposes that the application code is running correctly. Correct me if I'm being stupid here, but I assumed the whole idea was to be able to load new code into the device. I occasionally make a mistake when programming, which results in code that doesn't run the way I intended. Maybe I'm unique in this respect?

Four legs good, two legs bad, three legs stable.

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

John ..

Your right, either way is ok.

Was answering the original posters question, wasn't referring to your
suggestion, sorry about that.

However, remotely uploading new code is done all the time commercially, my cable router does it from netgears site.

Windows does it, linux does it, etc etc.

Plus of cause, the mars rovers do it too :)

If proper watchdogs are setup and used and other useful things like error checking, then any code problems should ideally reboot the cpu. The cpu should have a crc error checked copy of the last good known code that worked, stored in external eeprom/flash mem so it can reload it back in on it's own.

You can't ensure things are perfect (nasa fully agrees), but you can make things
pretty reliable with the right measures - well, with simple chips like the atmel
chips etc.

Lexxy

admin's test signature
 

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

John is being too cautious. Most motherboards leave you up the creak if you interrupt a bios upload. (Gigabyte is an exception, having a dual bios).

But the answer is trivial. This is the answer (for tyro freaks):

Put a link on a pin. Set the fuses so that a hard reset jumps straight to the bootloader. In the bootloader, first check the pin. If in, jump to the program reset (org 0). Else execute bootloader.

This way, you can normally enter the bootloader (just past the pin check) from your program to reprogram the chip, but if it fails you can close a link so that a reset puts you into the bootloader directly.

admin's test signature
 

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

Suppose follow steps:

1.) on Reset the bootloader reads some variable in eeprom to examine if an application is loaded. If variable is FALSE it waits for uploading application, otherwise it's calling application code.
If the bootloader waits for application upload then after fully receiving it setup above variable to True as last step.
2.) Application receive command to upload new code and jumps to bootloader. This bootloader function resets above variable to false and waits for upload of new application code.

Now, there no problems more.

Hagen

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

You're probably all correct, and I'm being too cautious, but most motherboard BIOSes have been extensively tested before distribution (at least I hope so). I tend to use bootloading during development, and so I'll stick to controlling the reset with DTR.

Four legs good, two legs bad, three legs stable.

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

John is being too cautious. Most motherboards leave you up the creak if you interrupt a bios upload.

Yeah - I had to build a EEPROM flasher for the 32-pin PLCC's those thing use to fix a failed bios FLASH.

-Colin

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

oops - BIOS should be caps and flash should be lower case...

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

"...I'll stick to controlling the reset with DTR. ..."

Then you have the equivalent of an ISP, don't you? Not a "bootloader".

Lee

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

"Then you have the equivalent of an ISP, don't you? Not a "bootloader"."

No, because I can load programs via the same serial comms connector that the target application uses (with a modified cable). That's much easier than opening the box to access a separate ISP connector.

Four legs good, two legs bad, three legs stable.

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

OK, but why, in your view, does RESET need to be manipulated to make it a bootloader?

Why does one have to "open the box to ..."? You are already adding hardware per your original post.

"Any sofware method of instigating a bootloader is doomed to failure, if you want my opinion. "

So everyone using Megaload and any comparable scheme is doomed to failure.

"What happens if the bootloading process is interrupted for any reason?"

The same checks that you might have in your scheme. Do you have checks in your ISP code to detect an incomplete flashing? The vector table is in low mem, after all.

Have you even >>looked>is<< the hole that would allow inclomplete bootloading? I'd be interested to have it pointed out.

Lee

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

Hi,

"Any sofware method of instigating a bootloader is doomed to failure, if you want my opinion

As I understand it MegaLoad (and most others) check the serial port at start-up if the boot application is there - if it is then it goes to the bootloader. This way even if the update failed you can still reload the code.

If so, where >>is

Bootloading of the code space or bootloader space? For the code space there is a good chance that your power will fail while you are bootloading (compliments of Murphy). If however you go to the bootloader at reset and check (like MegaLoad does) then you'll be fine, since you can still reflash.

I think the OP was talking about the only way to jump to bootloader is by a comand in the main application, and only by doing that you can enter bootloader. So if the main code gets messed up then you can't get in the bootloader...

Computer motherboards do this - to reflash the unit they load the new code into SRAM. Then they start the flash process from SRAM - but if something goes wrong of course you can no longer get into your computer.... however a lot of motherboards now are starting to have safe-gaurds (secondary bios, or an emergency bios that gets you far enough to reflash the main one).

-Colin

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

Lee,

I don't want to get embroiled in a big argument with you, especially since you seem to be the most prolific poster in this forum, answering everyone's questions.
But, I've used Megaload, I think it's brilliant, but how do you start it? That's right, you have to reset the target (O.K., you could add code to your app. to jump to the bootloader, let the watchdog timer expire or whatever). In fact I'm still using the target end of Megaload, although slightly re-written to fit in 256 words.
As for adding extra hardware, yes, one track from the reset pin to my serial comms connector. The transistor that controls the reset line is in the cable.
Have I even looked at the protection schemes addressing this issue? Yes. The reason why Megaload is so good is that it is possible to program a fuse to move the reset vector to the boot block, and it is also possible to protect the boot block from further programming. All the Atmel bootloader stuff I've looked at requires the use of another input to instigate the bootloader at reset. Have you ever used Megaload? The other great thing about it is that, having bootloaded your new software, you can open a monitor window and test your new code over the PCs serial port. And if your new code hangs somewhere, what do you do? Reset, you have to.
As I said in an earlier post, I occasionally make mistakes when writing programs (even though I've been doing it for 28 years).
Anyway, as you kindly reminded me in your last post, I did say "if you want my opinion". It seems pretty obvious to me that you, for one, do not.

Best wishes,

John Brown

Four legs good, two legs bad, three legs stable.

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

Colin,

That's right, "As I understand it MegaLoad (and most others) check the serial port at >>start-up>reset<< and check (like MegaLoad does) then you'll be fine, since you can still reflash."
"I think the OP was talking about the only way to jump to bootloader is by a comand in the main application, and only by doing that you can enter bootloader. So if the main code gets messed up then you can't get in the bootloader..."

Spot on, I've no objection to have alternative methods of instigating a bootload, but at some time, when you make a mistake, you're going wish you had remote control of that reset line.
Finally, I'm terribly sorry that I typed "sofware", I meant "software" of course. No wonder I can't write programs that work first time when I can't even spell.

Regards,

John Brown

Four legs good, two legs bad, three legs stable.

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

I'm guessing from the original post and follow on's, that his/her meaning of 'remote', possibly is not correct, ie, can be directly connectable - I don't yet know if this is the case but I suspect so.

Anyway ... if your going to 'remotely' reprogram a unit, then to make mistakes minimal, the new program code should really be tested locally on a copy of the remotely located hardware - but wired (or RF/Modem linked) up, as if the unit was remotely located - preferabley in another building (to make going and pressing the reset button a real pain in da ass).

Then, at least you will have an idea if things will most likely work in the actual remotely located unit - and at the same time, checking to see if you can still upload new code (maybe) after you have sent your new program code.

The weak link in all this, is of cause, US - we the biological entities (unless of cause your vulcan, or the likes of).

Anyway, I don't think this is relevent here, as the 'remote' unit the original poster talks about, appears not to be remotely located ... If it really isn't, then most of this thread has probably been a waste of time - to him/her anyhow.

Such is life! ........... and life (us) as such, still has a awful lot to learn :)

Lexxy.

admin's test signature
 

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

I take it all back - Your directly wired upto the cpu.

Do as John suggested :)

Just make sure the bootloader is 99.9% reliable to start with.

admin's test signature
 

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

Wow . . . didn't expect all that!

This exchange has taught me a lot about the things I need to consider. Things I wouldn't have thought of. As to the issue of what I meant by "remote" . . . I am using an RF serial link.

It kind of sounds like everyone considers MegaLoad to be pretty good (at least as a starting point), so I will check into it more. I understand that there is a PC app for doing the downloading. Is it well documented so that I will be able to easily write an equivalent app for a Palm . . . or is there a Palm app that already exists?

Thanks everyone,
Scott Kelley

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

Megaload has some documentation, but more importantly it includes the source for the bootloader. It does not come with the source for the PC end that does the downloading. In my case, I will eventually be communicating through a Portmaster that I telnet to so I had to do my own downloader, which I just embedded as part of the overall interface application. I also did the AVR bootloader end just for the experience and it wasn't that bad. The Megaload bootloader provides a very good starting point if you are going to do your own.

Dave

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

I think the previous version of Megaload included the source for the PC end. Otherwise I've no idea how it ended up on my hard disk. I couldn't do much with it, however since it was for Borland C++ Builder IIRC. If you want details I suggest you contact the author, he's a frequent contributor to these forums.

John

Four legs good, two legs bad, three legs stable.

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

I just looked at the MegaLoad web site, hoping to find source code, etc. The ZIP package seems to contain only .LIB files that appear to be precompiled.

Does anyone know if the source is available, and, if so, where?

Many thanks,
Jim

admin's test signature
 

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

Sorry, I wasn't very explicit. I'm looking for the AVR source for the AVR end of MegaLoad.

Jim

admin's test signature
 

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

The .zips that I have have a .zip for each supported chip type--e.g., ATMega8.ZIP. there are source files in that package.

Lee