recommended bootloading software?

[Admin]

I'm trying to find some better bootloading software to upload .hex to my various ATmegas.

Ive been usisng MegaLoad, but its kind of buggy . . .

recommendations?

And I remember a long time ago I used hyperterminal as a bootloader, but can't remember how I did it . . .

Oh and I prefer GUI over command line . . .

[rgcustodio]

Hello Admin,

I think there's a discrepancy on how everyone defines and uses the term bootloader. I think we are confusing bootloader and a downloader/uploader.

A downloader/uploader is a program that runs on the host PC and downloads your software from the host PC to the embedded system/robot. Most probably you will still be connected to the machine via ISP or seial. Some require that you have an actual bootloader on the system/robot already burned. The software that came with our ISP programmer is a downloader/uploader, as well as avrdude.

A bootloader, on the other hard resides on flash (or ROM) and assists the developer to painlessly write the firmware to the embedded system/robot. The bootloader reads data from an input port (this is the serial most of the time for small MCUs) and writes the data to the flash itself! You won't need the specialized ISP in this case, so you can do on-site programming w/o special HW or SW. You will most probably just use a serial terminal connected to the system/robot and host PC and download away.


When you used Hyperterminal, it suggests that you have a bootloader on your system/robot. MegaLoad is actually just an uploader which comes with code for the bootloader. Using MegaLoad without a bootloader installed on your ATmega will probably fail. (BTW, I haven't used MegaLoad firsthand so the previous statements might be totally iincorrect.)

With a bootloader on your ATmega that requires a serial connection, you can use any serial terminal software GUI, CUI etc do download your program to the system/robot.

If you truly want bootloaders there are tons here.
http://hubbard.engr.scu.edu/embedded/avr/bootloader/index.html
http://www.chip45.com/chip45boot
http://www.chip45.com/index.pl?page=ATmegaBOOT&lang=en
http://www.avrfreaks.net/index.php?module=Freaks%20Tools&func=viewItem&item_id=328
Or you can build your own to suite your specific needs.

Regards,
Rommel

[Admin]

I've spent the last 8 hours today working on this, so I know a bit more now . . .

I've been using the term 'bootloader' for everything, oops . . . thanks for the clarification!

The problem I am having is that I'm using the ATmega2560 which like no one uses . . . so I can't find any source for it anywhere . . . I've been forced to do a lot of monkey business (coding) . . . What complicates this is that the ATmega2560 has four different UART ports, and I want to specify which port the bootloader uses . . .

Ok so lets clarify what I have by using the new terminology . . .

MegaLoad (link at the top) comes with files that must be compiled with ICC (yea, annoying, I couldn't get it to compile in AVR Studio). This creates a .hex bootloader which then I upload using AVR Studio.

Using the very buggy MegaLoad I am then able to upload my normal program to that bootloader, verifying that it works.

What I want to do is not use MegaLoad, but any other uploader. Unfortunately all the others I've tried (BLIPS, hyperterminal, teraterm, AVR Studio) fail to work. So I suspect that the bootloader is somehow configured to only work with MegaLoad (not STK500 V1 compatible?) . . . but I'm not sure how . . .

Anyway, looking at the chip45 code . . . I saw this before, and gave up because it doesnt have defines (sig2, sig3, page_size) for the ATmega2560 - and I'm too noobish to understand that (spent an hour trying to figure it out) . . . ideas?
Scrolling down I see this line:
uint8_t bootuart = 0;
does that define which UART I can use?

reading around some more I realize what I need is called a "bootloader thats STK500 V1 compatible"

[rgcustodio]

Here's a quickie response (i'll be going out of the office in a bit)

I for one haven't worked on the ATmega2560!


1) MegaLoad seems to have "special" processing in the bootloader.

Code: [Select]

:
RxChar();
TxChar('>');
if (RxChar() == '<')
{
TxChar(PageSize);
TxChar(DeviceID);
  TxChar(FlashSize);
  TxChar(BootSize);
  TxChar(EEpromSize);

  RxChar();
  TxChar('!');

while (1)
{
WDR();
GetPageNumber();

if (RealPageAddress == 0xffff) break;

if (WriteFlashPage()) TxChar('!');
else TxChar('@');
}
:

based on the website, i assume that this is the "handshake" while the others are used for error detection and correction. So if the software you are using to transfer the data to the robot doesn't understand this "codes" from the boot loader your transfer won't succeed.

2) The bootloader from chip45 has two versions, one is ATmegaBOOT and the other is chip45boot. The code you pointed out is for the ATmegaBOOT. And I do think it is used for selecting the UART device. The code checks PINF or PIND (depending on the selected device) if its low and assigns the correct value to "bootuart". I think the chip45boot bootloader is newer and maybe more friendly to the user.

I tried to use chip45boot on my Butterfly's (Atmel ATmega169/ATmega169P)  but I just can't make it work

3) Here's another bootloader, it is not STK500 compliant, but it requires the downloading application to support the Xmodem interface. I don't know if it fits the bootblock of your ATmega but it's worth a try.
http://www.embedded.dk/projects/Embedded/AVR_Projects_Bootloader.htm

HTH!

Regards,

[Admin]

Question . . . I want in my code to restart the bootloader upon receiving a command by UART . . . so upon receiving this command I *think* I need to disable UART then jump to the bootloader start address, right?

So probing around I *think* 0x1fe00 is that start address for the ATmega2560 . . . so how do I jump there? I need to do some kind of pointer, no? Whats the syntax to do that jump?

i assume that this is the "handshake" while the others are used for error detection and correction

yea thats what I assumed too . . . I asked the MegaLoad programmer, but he just said:
"The bootloader is compatible with any define MCU STK500 is only a hardware platform" and "the problem is not on my side,..."


I am still looking into your #2 and #3 . . . xmodem is fine since both hyperterminal and teraterm both use that . . . and my bootblock is 4k

[benji]

get ponyprog

[rgcustodio]

Question . . . I want in my code to restart the bootloader upon receiving a command by UART . . . so upon receiving this command I *think* I need to disable UART then jump to the bootloader start address, right?

actually the main.c of MegaLoad's bootloader could provide you with some information at the bottom of the main() function, the bootloader executes an assembly code that jumps to a specific memory location:

Code: [Select]

  asm("jmp 0x0000");                // Run application code

so to do the leap or jump you use the code above or something like:

Code: [Select]

void (*app_start)(void) = 0x0000;

int main(int argc, char *argv[]) {
:
:
    app_start();

return;
}


According to the specifications, page 332, 0x1FE00 is the the start of the bootloader section if you configured the BOOTSZ1 and BOOTSZ0 fuse bits to 1. So the size and start of the bootloader section depends on these fuse bit settings. Then on the next page, states the valid addresses. The RWW part is where your actual application gets written to. So your application should start at 0x0000. (This memory model is actually easier than some of the other's that i've come across.) Page 20, actually shows a graphical representation of the ATmega's memory map.

Goodluck Admin!

Regards

[Admin]

Ok I think I have a different problem . . .

I managed to get a second bootloader to work (horray!):
http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=1008&item_type=project
It has an autobaud feature which is nice, but absolutely zero documentation . . .

Anyway, its giving me similar bugs that MegaLoad was giving . . .

The main one being this:
It works using my USB->UART connection
It does not work using my EasyRadio wireless connection

both at 38400bps . . . all things the same except pin numbers . . . wireless works otherwise in hyperterminal, etc.

thinking about it now, I remember an old problem I had with the EasyRadio that I never solved:
http://www.societyofrobots.com/robotforum/index.php?topic=2250.0
basically if I sent data too fast to it, it was if some buffer overflowed then all data got corrupted to 252525252525

Do you think maybe this is the cause of my pain?

[Admin]

I just spoke with the guy who wrote that bootloader on this problem:

EasyRadio has a buffer of only 180 byte, but the bootloader sent packets of 7680 byte.
So the synchronization was lost (timeout) after the first packet (7680 = 0x1E00).

The buffer size can be reduced, but not below the page size (256 byte on the ATmega2560).

Ideas?

[rgcustodio]

I have comments regarding the ER its in the other thread: http://www.societyofrobots.com/robotforum/index.php?topic=2250.0

but i have no clue on what the developer just sent you, sorry.

[rgcustodio]

I just spoke with the guy who wrote that bootloader on this problem:

EasyRadio has a buffer of only 180 byte, but the bootloader sent packets of 7680 byte.
So the synchronization was lost (timeout) after the first packet (7680 = 0x1E00).

The buffer size can be reduced, but not below the page size (256 byte on the ATmega2560).

Ideas?

i guess i understood what he was trying to say after all

synchronization between the transfer application on the host PC and the bootloader on the MCU must be achieved and must be continuous throughout the download process. if the synchronization is lost, the transfer will be incomplete. this assumption is based on the first comment.

the downloader sends 7680-bytes and the bootloader expects 7680-bytes per packet. since 7680-bytes won't fit in the ER's buffer you can't achieve correct synchronization b/n the downloader and the bootloader.

the developer further mentions that the packet size can be changed for both downloader and bootloader, so that they can be kept in sync. in fact it can be changed to 256-bytes. this 256-bytes is a must, because based on the ATmega2560 data sheet this is the page size (its actually 128-words == 256-bytes, on page 340 of the data sheet). i mentioned earlier that this is a must, its not my fault AVR-109: Self Programming (doc1644.pdf) application note requires that Flash programming or writing to flash must be done in blocks of page size only.

but still 256-bytes is beyond the ER's buffer size so you'll still have sync issues. you might need to change the bootloader to allot for these issues. i'm not really sure how easy that will be.

Regards,

[dunk]

i'm presuming the CTS on the ER module changes state when it is transmitting data.
to minimise the amount you need to change the bootloader you could connect the CTS pin to an interrupt so you can pause the bootloader program while the ER buffer is reloading.

dunk.

[rgcustodio]

yep, according to the specs CTS goes high when the ER is sending or receiving data.

most bootloaders are very simple, because they have to fit within the bootblock! some bootblocks are just 1Kb. adding an ISR breaks the 1Kb barrier most of the time. the ATmega5260 that Admin is using can have a max 4Kb bootloader but to the expense of making the flash area for the actual application smaller.

it is very possible to add an ISR to the bootloader but care should be taken, so that it will still fit within the bootblock.