View previous topic :: View next topic |
Author |
Message |
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Wed Sep 18, 2019 12:59 am Post subject: Bootloader |
|
|
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:
Here is the code that I'm using to upload it to the processor. (Its called LoadBL.bas ) Code: | '*******************************************************************************
$regfile = "m1284pdef.dat" 'my processor
$crystal = 9830400 'system crystal
$framesize = 800 ' Located at top of 16k of SRAM
$hwstack = 550 '
$swstack = 550 '
$frameprotect = 1
Disable Jtag
disable interrupts
config watchdog = 2048 '2 sec
stop watchdog
'------------------------------------------------------------
'Open a software UART TRANSMIT channel for debug on software ser port
Open "comc.3:38400,8,n,1" For Output As #1 '
'---------------------------------------------------------------------------------
$LOADER = $F000
$inc , nosize , "j:\Dropbox\projects\testboot.bin"
End
'************************************************** |
When I compile the testboot.bas the compiler generates this:
And here is what the ROM code looks like after I run LoadBL.bas:
As you can see, the insert starts at 1E000 which is correct, but the .bin file is inserted just after 1E090, but there is a whole lot of "stuff" in front of it.
The .bin file ends at 1E0D0 , foloowed by more 'stuff' that I dont know from where it came.
The remainder of the rom from 00000 to 001C0 has the code from LoadBL.bas in it as expected and the bootloader section from 001D0 to 1FFF0 is empty as I expected.
(BASCOM-AVR version : 2.0.7.9 , Latest : 2.0.8.2 ) _________________ Neil |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Wed Sep 18, 2019 7:32 am Post subject: Re: Bootloader |
|
|
njepsen wrote: | The .bin file ends at 1E0D0 , foloowed by more 'stuff' that I dont know from where it came. |
Help tells you about $loader:
Quote: | Instruct the compiler to create a boot loader at the specified address. |
That's what it does.
Code from loadBL.bas is converted into a bootloader, along wit required helper routines, the inc-code is attached after.
Only because this approach may have worked a few years ago in an earlier Bascom-version - see your other post - it is not guaranteed it will still work, because it is not a guaranteed feature of $loader. |
|
Back to top |
|
|
jenalcom
Joined: 10 Apr 2004 Posts: 365 Location: Perth, Western Australia
|
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. |
|
Back to top |
|
|
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Wed Sep 18, 2019 8:15 am Post subject: |
|
|
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. _________________ Neil |
|
Back to top |
|
|
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Wed Sep 18, 2019 8:44 am Post subject: |
|
|
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? _________________ Neil |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Wed Sep 18, 2019 7:03 pm Post subject: |
|
|
njepsen wrote: | 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? |
You missed an exclamation mark, yellow triangle and The $ROMSTART directive is an inheritance from BASCOM-8051. In the AVR it does not have any meaning. altogether.
AFAICS there is no clean way to make this work without modified compiler.
As well as I did actually manage to place the bootloader at &hF000 via !.org, the compiler adds core code after, which obviously will give problems with real and extensive code. |
|
Back to top |
|
|
EDC
Joined: 26 Mar 2014 Posts: 971
|
Posted: Wed Sep 18, 2019 8:09 pm Post subject: |
|
|
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
Code: | $regfile = "m2560def.dat" '8K SRAM | 4K EEPROM
$crystal = 16000000
$hwstack = 128
$swstack = 128
$framesize = 256
$baud = 115200
Debug On
Do
Loop
End '<<<<<<<<<<<<<<<< END OF MAIN CODE
Menu_glowne:
Data " " , "Blokowanie" , "Ustaw kuranty" , "Przegl{007}daj kuranty" , "Ustaw pogrzeb" , "Ustaw pilot"
Data "Ustaw czas i dat{002}" , "Wybijanie godzin" , "Volume" , "Wyjd{004}"
Dni_tygodnia:
Data "Pn" , "Wt" , "Sr" , "Cz" , "Pt" , "So" , "Nd"
Miesiace:
Data " " , "Sty" , "Lut" , "Mar" , "Kwi" , "Maj" , "Cze" , "Lip" , "Sie" , "Wrz" , "Paz" , "Lis" , "Gru"
Getdatetime:
'...
Return
Setdate:
'...
Return
Settime:
'...
Return
'Bootloader
$boot = &H1FC00
$inc Bootloader , Nosize , "bl.bin" |
|
|
Back to top |
|
|
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Thu Sep 19, 2019 4:47 am Post subject: |
|
|
Hi MWS,
No I didnt miss the Yellow triangle etc, but I interpreted Quote: | In the AVR it does not have any meaning. | to mean "is not useful any more", not that it wouldnt work at all. Anyway - it obviously does something but I dont know what.
.
All that aside - I have spent another several more hours trying to get the bootloader installed automatically with my code installation, and I'm afraid i have not succeeded. I have a bootloader that works perfectly, but when i try to install it with $loader, it says [quote Program will overwrite flash memory(or bootloader)[8944 too long), in file ....[/quote]
EDC -
I've tried the $loader and $inc commands inside the code, before the code and after the end instruction, with .bin and .bas, with 2.0.7.9 and with 2.0.8.2 and no success.
Thanks for the help guys. _________________ Neil |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Thu Sep 19, 2019 5:21 pm Post subject: |
|
|
njepsen wrote: | to mean "is not useful any more", not that it wouldnt work at all. |
Your interpretation hangs very much to the side where you want to have it
The 'wouldn't work' results out of its purpose:
Quote: | Instruct the compiler to generate a hex/bin file that starts at the specified address. |
In an AVR it wouldn't help if your hexfile starts at a flash address different to the start address.
Additionally this command very much sounds like it has global impact, means as soon it's in the code, it will affect the complete code, it will not only affect the hexfile's address beginning from the line where it is located.
This approach seem to have worked in 2015, as in https://www.mcselec.com/index2.php?option=com_forum&Itemid=59&page=viewtopic&t=12372
But since then the compiler had a few steps in version, and as it wasn't a guaranteed functionality by then, it may have vanished somehow by now.
It may however be useful for producing series, where virgin controllers can be outfitted with code and bootloader in one flash.
I would suggest a special command/compiler directive for this purpose, which places any code following this command to the specified address.
Bascom core code needs to be in front of this specified address.
Edit:
Got it to work, with some complications however.
The trick is to replace $LOADER &hxxxx within the bootloader code by $NOINIT, then compile, in this example as loader.bas.
After adding:
Code: | $boot = &hF000
$Inc L1 , nosize , "loader.bin" |
at end of main code, the bootloader is included at the proper place in flash, Bascom's core code is also placed where it belongs.
The command END has no immediate effect on proper placement, however it is better placed before $INC, as END creates the sequence:
Code: | cli
Label_end:
rjmp Label_end |
which stops and holds the controller in a save condition. |
|
Back to top |
|
|
Netzman
Joined: 25 Nov 2005 Posts: 127 Location: Graz
|
|
Back to top |
|
|
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Fri Sep 20, 2019 12:23 am Post subject: |
|
|
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:
Code: |
'*******************************************************************************
$regfile = "m1284pdef.dat" 'my processor
$crystal = 9830400 'system crystal
$framesize = 800 ' Located at top of 16k of SRAM
$hwstack = 550 '
$swstack = 550 '
Disable Jtag
$noinit
disable interrupts
config watchdog = 2048 '2 sec
stop watchdog
dim n as byte
'------------------------------------------------------------
'Open a software UART TRANSMIT channel for debug on software ser port
Open "comc.3:38400,8,n,1" For Output As #1 '
print #1 , "MY BL " ; n
goto _reset 'start main program |
and in the loader I used this code:
Code: | '*******************************************************************************
$regfile = "m1284pdef.dat" 'my processor
$crystal = 9830400 'system crystal
$framesize = 800 ' Located at top of 16k of SRAM
$hwstack = 550 '
$swstack = 550 '
'$frameprotect = 1
Disable Jtag
$prog &HFF,&HC7,&HD0,&HFD
disable interrupts
config watchdog = 2048 '2 sec
stop watchdog
dim n as byte
'------------------------------------------------------------
'Open a software UART TRANSMIT channel for debug on software ser port
Open "comc.3:38400,8,n,1" For Output As #1 '
do
incr n
print #1 , "LOADER" ; n
wait 1
loop
end
$boot=&hF000
' $inc BL , nosize , "j:\Dropbox\projects\DOS_Bootloader\testboot2.bin"
$inc BL , nosize , "j:\Dropbox\projects\empty.bin"
'--------------------------------------------------------------------------------- |
The fuse bits are set to BootRST and Bootflashsize=4096 addr = $F000
On examining the contents of memory, the BL appeared to be correct at 1E000 and the main at 0000 but neither the BL or the main would run.
[/code] _________________ Neil |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Fri Sep 20, 2019 10:02 am Post subject: |
|
|
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. |
|
Back to top |
|
|
AdrianJ
Joined: 16 Jan 2006 Posts: 2483 Location: Queensland
|
Posted: Sun Sep 22, 2019 5:15 am Post subject: |
|
|
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. _________________ Adrian Jansen
Computer language is a framework for creativity |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Sun Sep 22, 2019 3:06 pm Post subject: |
|
|
AdrianJ wrote: | 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. |
Wrong policy if you have to flash dozens of identical boards.
Using $PROG and including the bootloader within the bin makes a tedious job easier. |
|
Back to top |
|
|
AdrianJ
Joined: 16 Jan 2006 Posts: 2483 Location: Queensland
|
Posted: Mon Sep 23, 2019 12:09 am Post subject: |
|
|
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. _________________ Adrian Jansen
Computer language is a framework for creativity |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
|
|