Bootloader

njepsen · Joined: 13 Aug 2007 Posts: 469

I have been trying unsuccessfully to incorporate a bootloader at the time of programming the chip, using $LOADER and $INC.
From tests so far, it seems to me that $LOADER in combination with $INC puts the BL into ROM at about the right place, but also copies some junk ahead of it and after it.

Here is my bootloader code, which is in a file called "testboot.bas". It has only one instruction:

MWS · Joined: 22 Aug 2009 Posts: 2262

jenalcom · Posted: Wed Sep 18, 2019 7:56 am Post subject:

As a work around why not load your bootloader into a blank chip and then use the bootloader to load your programme. Once you have done that you can then save the flash contents (programme and bootloader) and use that to programme further blanks.

njepsen · Joined: 13 Aug 2007 Posts: 469

Thanks Guys.
I have been using a bootloader for several yrs now, but thought it would be nice to be able to load it when I program the chips, rather than do it separately.

I've just read the help for $loader in ver 2.0.8.2, and now i'm totally confused, but it looks like you can use $loader to load your own BL. I just haven't figured out how.
It would be nice if $ROMSTART worked with my processor,- because I should be able to use that to load my BL at the right place - but it appears not to work. I'll do dome more testing shortly. The help for $romstart says "there is no practical useage" but its not clear if it works or not.

njepsen · Joined: 13 Aug 2007 Posts: 469

Just did some testing and I cant get $ROMSTART to do anything with ver 2.0.8.2 and the atmega1284p.
So I'm either doing something stupid, or it doesnt work with my chip/compiler?

MWS · Joined: 22 Aug 2009 Posts: 2262

EDC · Joined: 26 Mar 2014 Posts: 971

I think problem here is that you attach bootloader BEFORE "END" command so compiler will consider it like some code of main application and then AFTER END it will put rest of declared subs or core procedures for clearing SRAM etc...

I attach bootloader in the way you can look and then compare generated bin files. Everything looks perfectly fine. Bootloader is attached without any overhead. It starts and ends with exactly same values at the correct address 1FC00/2=F800

So move your attachment AFTER END command and then try Very Happy

njepsen · Joined: 13 Aug 2007 Posts: 469

Hi MWS,
No I didnt miss the Yellow triangle etc, but I interpreted

MWS · Joined: 22 Aug 2009 Posts: 2262

Netzman · Joined: 25 Nov 2005 Posts: 131 Location: Graz

What about combining the hex files of the loader and the app as a post compilation step with a tool like https://github.com/gicking/hexfile_merger or http://www.hexworkshop.com/ ?
Could be done in a batch file to generate the production hex file, using bascomp to compile the loader/app and then running the combination step.

njepsen · Joined: 13 Aug 2007 Posts: 469

Hi MWS,
Thanks for the time you have obviously spent here.Initially, I tried to upload my normal bootloader (which is a modified version of the Vögel Franz Josef code, and which works fine ), with $loader replaced with $init as you suggested but the BL didnt start, so then i tried this simple test:

MWS · Joined: 22 Aug 2009 Posts: 2262

Ok, checked the results from your code, the reason for failure is that the compiler creates non-relocatable assembler code from the Bascom source.

Assembler code making use of RCALL, RJMP, relative branches a.s.o. is relocatable, you could shift it in address and it will still work.
Alas Bascom commands from the bootloader are translated partly into absolute asm-nemonics like CALL and JMP.

Creating the bootloader at &h0000 (done with $NOINIT) and shifting it is necessary, because otherwise you end up with the message: Flash used 187%.

Attaching all the empty flash via $INC at &hF000 will overrun the flash's border.
The reason is: the bin-file contains also all the empty space, it is simply a binary representation of the flash, it does not feature any address-directive.

As you use a special loader from SD-card https://www.mcselec.com/index2.php?option=com_forum&Itemid=59&page=viewtopic&t=12372 and this loader uses Bascom-commands, which again translate into non-relocatable code, the fun stops here for you.

The method would however work, if the bootloader is written in assembler-code containing only relative branches/jumps/calls.

One approach would take maximum a half hour, as it is not a big deal to write a small program with language, GUI and OS of your choice, which merges n-bytes of main-bin into the empty space of loader-bin, outputting a combined bin.

Another idea would be - in case the bootloader itelf is seldom altered - to create your loader regularly, then cut out manually &F000 * 2 bytes = 122880 bytes from start of the bin and save it as your loader.bin
By including this modified bin with the help of $BOOT and $INC at &hF000 you will get a working solution.
Using a hex-editor this is done in less than a minute.

AdrianJ · Joined: 16 Jan 2006 Posts: 2483 Location: Queensland

I never used the Bascom bootloader.

But my policy with bootloaders has always been to just set the fuses, then program only a bootloader. Then use the bootloader to program main code as a separate step. And of course check that the unit works.

That way you are absolutely sure that the bootloader and its interface works. When you program both together, you never find out whether the bootloader works until you get a service call from a customer saying he cant upgrade a program in the field.

MWS · Joined: 22 Aug 2009 Posts: 2262

AdrianJ · Joined: 16 Jan 2006 Posts: 2483 Location: Queensland

Maybe your type of product is different from mine.

We have to do a complex series of tests to ensure all parts of the system works, its nowhere near good enough to just power up and check that it functions. Compared to that, programming via the bootloader is a minor part of the job. And we have done hundreds of units.