Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

Bootloader
Goto page 1, 2  Next
 
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR
View previous topic :: View next topic  
Author Message
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 392

newzealand.gif
PostPosted: Wed Sep 18, 2019 12:59 am    Post subject: Bootloader Reply with quote

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


END  


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
View user's profile
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1722

blank.gif
PostPosted: Wed Sep 18, 2019 7:32 am    Post subject: Re: Bootloader Reply with quote

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
View user's profile
jenalcom

Bascom Member



Joined: 10 Apr 2004
Posts: 357
Location: Perth, Western Australia

australia.gif
PostPosted: Wed Sep 18, 2019 7:56 am    Post subject: Reply with quote

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
View user's profile
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 392

newzealand.gif
PostPosted: Wed Sep 18, 2019 8:15 am    Post subject: Reply with quote

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
View user's profile
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 392

newzealand.gif
PostPosted: Wed Sep 18, 2019 8:44 am    Post subject: Reply with quote

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
View user's profile
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1722

blank.gif
PostPosted: Wed Sep 18, 2019 7:03 pm    Post subject: Reply with quote

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
View user's profile
EDC

Bascom Expert



Joined: 26 Mar 2014
Posts: 607

poland.gif
PostPosted: Wed Sep 18, 2019 8:09 pm    Post subject: Reply with quote

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

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
View user's profile Visit poster's website
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 392

newzealand.gif
PostPosted: Thu Sep 19, 2019 4:47 am    Post subject: Reply with quote

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
View user's profile
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1722

blank.gif
PostPosted: Thu Sep 19, 2019 5:21 pm    Post subject: Reply with quote

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 Very Happy

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
View user's profile
Netzman

Bascom Expert



Joined: 25 Nov 2005
Posts: 105
Location: Graz

austria.gif
PostPosted: Thu Sep 19, 2019 11:05 pm    Post subject: Reply with quote

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.

_________________
LCD Menu | Proportional Fonts
Back to top
View user's profile Visit poster's website
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 392

newzealand.gif
PostPosted: Fri Sep 20, 2019 12:23 am    Post subject: Reply with quote

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
View user's profile
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1722

blank.gif
PostPosted: Fri Sep 20, 2019 10:02 am    Post subject: Reply with quote

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
View user's profile
AdrianJ

Bascom Expert



Joined: 16 Jan 2006
Posts: 2458
Location: Queensland

australia.gif
PostPosted: Sun Sep 22, 2019 5:15 am    Post subject: Reply with quote

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
View user's profile Visit poster's website
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1722

blank.gif
PostPosted: Sun Sep 22, 2019 3:06 pm    Post subject: Reply with quote

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
View user's profile
AdrianJ

Bascom Expert



Joined: 16 Jan 2006
Posts: 2458
Location: Queensland

australia.gif
PostPosted: Mon Sep 23, 2019 12:09 am    Post subject: Reply with quote

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
View user's profile Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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