I am writing a bootloader using uvision2 for c8051F120. The purpose is to update my application code(hex.) through hyper terminal.
I had referred to some guides, AN112 and AN201. Currently, I had modular my application codes -> 5 files.
I intend to place the bootloader and the hexfile receiver codes in one of my file(UART communication) so that I do not need to redefine some of the communication functions.

My objective is to
Erase the application codes in the hyper terminal and then load the new application codes (hex file)

However, my doubt is,
1)How should I separate the bootloader codes and the application codes in the memory bank?

2) Is there a way that I can select the address to place the codes (different memory bank)?

I had referred to some guides, AN112 and AN201.
Good starting point.

I intend to place the bootloader and the hexfile receiver codes in one of my file(UART communication) so that I do not need to redefine some of the communication functions.
Okay, but think of changes you make to the UART part will affect both the bootloader and the application.
In my opinion a bootloader should always be independant from the application, they even shouldn't know anything from each other.

My objective is to Erase the application codes in the hyper terminal and then load the new application codes (hex file)
I think the above application notes give anything needed for this

How should I separate the bootloader codes and the application codes in the memory bank?
First, think of what you want to have and what is possible with the F120 device. Since the F120 always starts at location 0x0000 in memory bank 0 I think this should also be the place for the bootloader.

Also, placing the bootloader in a dedicated bank or even memory location isn't enough.
All applications you write for the F120 are affected because you've to configure them properly regarding start address (must not overwrite the bootloader ), the interrupt vectors, etc.

Use the forum search here, there are quite some threads regarding bootloaders in general and especially for the F120.
Here're some of them:
http://www.cygnal.org/ubb/Forum1/HTML/000402.html
http://www.cygnal.org/ubb/Forum1/HTML/001151.html
http://www.cygnal.org/ubb/Forum1/HTML/001668.html
http://www.cygnal.org/ubb/Forum1/HTML/001878.html
http://www.cygnal.org/ubb/Forum1/HTML/002257.html
http://www.cygnal.org/ubb/Forum1/HTML/002361.html
http://www.cygnal.org/ubb/Forum3/HTML/000344.html

I think a good bootloader should at least implement a failsafe mechanism, meaning if anything goes wrong while downloading/programming (received errorneous bytes or power-fail, etc.) the bootloader should restart. Therefore, the bootloader must be able to check if there are any communication errors. And, if possible, the bootloader should also be able to check the integrity of the current flash content (which isn't easy to check if flash memory is used for data storage).

Regards,

My apology for the late reply. Thank you for the advice!

*Okay, but think of changes you make to the UART part will affect both the bootloader and the application.
In my opinion a bootloader should always be independant from the application, they even shouldn't know anything from each other.*

I had separated the bootloader code from my application. Also, I had tested the bootloader.
As for my application, I referred to the Step by Step Instructions on Configuring a Code Banked Project Using ́Vision2 (AN130).
I intend to place the bootloader code in the common area(Memory Bank) and the application code in Memory Bank 2.

Regarding the flow of the program,
the erase function must be in the application code. Once, the application code is erase, the program will set the software reset bit (RSTSRC) in order to run the bootloader code at 0000H which will prompt me to download the hex code. Therefore, the memory address pointer must be set at memory bank 2.
Please correct me if I am wrong.

Appreciate your inputs!
Thank you!

I intend to place the bootloader code in the common area(Memory Bank) and the application code in Memory Bank 2.
Okay, but don't forget the interrupts. From a quick thought I'd prefer to have the BL in the common area. But as I wrote above, check the forum for the different approaches etc.

Regarding the flow of the program, the erase function must be in the application code.
Why? In my opinion this conflicts with "BL and application have to be independant from each other"

Therefore, the memory address pointer must be set at memory bank 2.
If you mean the data pointer register, they cannot point to a memory bank, if I'm correct. However, you must select which bank should be placed in the upper address space.

Regards,

Regarding the flow of the program, the erase function must be in the application code.
Why? In my opinion this conflicts with "BL and application have to be independant from each other"
Bascially, the bootloader code will erase and load new codes. This clarify my doubts whether to place the erase codes in the application or the BL code.

Therefore, the memory address pointer must be set at memory bank 2.
If you mean the data pointer register, they cannot point to a memory bank, if I'm correct. However, you must select which bank should be placed in the upper address space.
My apology, I meant the memory bank selection.

Thank you! I will work on it. I hope to seek for your inputs if there are any problems.

Bascially, the bootloader code will erase and load new codes. This clarify my doubts whether to place the erase codes in the application or the BL code.
Yes, the BL will deal with erasing, programming, and LBNL checking if the download was correct. Writing a fail-save bootloader should be the goal.
The application may also need to erase/write the flash (e.g. for data storage) but then the bootloader need to know about it (e.g. if the BL checks the application integrity via checksum, which would be modified when data has changed).

I will work on it.
Okay. And take a look into the other bootloader forum threads, there are some regarding fail-safe, F12x banking, etc.

Regards,

the application code in Memory Bank 2.
WHY, if the app fit in a bank you do not need banking.

Do you meant I should place my application in the common memory bank (same as the Bootloader code)?
I had consider the increase of the memory space of my application codes in future. So I thought of using the banking approach.
Do you have a better suggestion? I am open for other alternatives.

Thank you!

I had consider the increase of the memory space of my application codes in future.
...
Do you have a better suggestion?
Yes, because your approach wastes one full memory bank, which conflicts with the possible bigger application code

I am open for other alternatives.
You don't need a alternative, just a optimization for your approach
You can write the application for memory bank 0 with only few things to keep in mind:
- the code space allowed for the application must be changed according to the space left by bootloader -> if you use Keil C51, there are a few knowledgebase articles regarding F120 code banked applications and how to locate functions to dedicated code space areas/memory locations.
- if the BL uses interrupts the ISR vectors must be moved depending on wether bootloader or application is active. Again, Keil knowledgebase is a good starting point as well as this forum.
- maybe you must ensure that ISRs of the application are explicit located in memory bank 0 (I'm not sure if the ISRs are generally placed before main function), otherwise if they're located in any other bank the may not work or the application may crash.

There are still other things which have to be taken into account, again, the forum search should be used.

One thing regarding the behaviour of the BL:
As suggested above the BL should always be started on power up to check integrity of the flash memory. Other BL types are only started due to a external "switch" (e.g. pulling a dedicated pin to low on power up, etc.).
However, before coding you should clarify the following things:
- how to inform the BL of a software update if the flash memory integrity is well? There are different possible approaches, e.g. waiting for a receive event on a interface like UART, the above mentioned switch/port pin signaling, a bit variable shared between BL and application, ...
- possibility to start the BL or use some of it's functions in the application (e.g. the above mentioned shared bit variable)

Especially the informing mechanism and the possibility to call BL functions from application need special considerations regarding variable handling etc.

Regards,

One thing regarding the behaviour of the BL:
As suggested above the BL should always be started on power up to check integrity of the flash memory. Other BL types are only started due to a external "switch" (e.g. pulling a dedicated pin to low on power up, etc.).
However, before coding you should clarify the following things:
- how to inform the BL of a software update if the flash memory integrity is well? There are different possible approaches, e.g. waiting for a receive event on a interface like UART, the above mentioned switch/port pin signaling, a bit variable shared between BL and application, ...
- possibility to start the BL or use some of it's functions in the application (e.g. the above mentioned shared bit variable)

Thanks for the guide on BL "triggering".
I found a bootloader program(below)from this forum very close to what I am working on.

// boot_main.c// SDCC bootloader snippet//
#include < c8051f340.h >
//--------------------------------------------------------// entry of bootloader//--------------------------------------------------------
#define APPLICATION_ENTRY   0x200       // application entry
#define HARD_CMD_PORT       P1_2        // hardware command port
void command_handler( void );
void boot_main( void )
{    
   if ( HARD_CMD_PORT == 0 )// check 'hardware command' (option)
  {
   command_handler();
  }    
 if ( (RSTSRC & 0x02) == 0 ) //   PORSF: it isn't power-on reset 
 {        
   if ( (RSTSRC & 0x10) != 0 ) //   SWRSF: request from application
    {    
      command_handler(); 
    }                                 
 }
((void (code *)(void))APPLICATION_ENTRY)();
}
void command_handler( void )
{
PCA0MD   &= ~0x40;
PCA0CPL4  = 0xFF; 
PCA0MD   |=  0x40; 
PCA0CPH4 = 0x00; 
RSTSRC = 0x04; 
OSCICN = 0;
}                     

The flow of my program should be,
1) The user will select an option from the UART from the application code. This will set a software reset pin high and trigger the bootloader code.

2)In the BL code, it will check for the logic for the software reset pin. If it is active , it will prompt the user, erase the application codes, download the hex files and jump back to the application program, else it will just jump back to the main flow of the application code(at address 8000H) .

However, I had tested out my program. The program does not seem to be running as there is no output.
If there anything I did not take into account for?

Thank you!

MGear

My apology for the BL format,
I found it from

http://www.cygnal.org/ubb/Forum10/HTML/000022.html

I had use RSTSRC as a software reset to trigger the bootloader from my application code.
Okay, but be aware of that you must first check the power-on reset flag. If it's set all other flags in RSTSRC are invalid.

As sugguested from you, I placed all my codes in bank 0 - BL(common memory 0x0000-7FFF) and application(Bank 0 0x8000-0xFFFF) to optimize my approach.
Erm... memory space from 0x8000-0xFFFF could be any memory bank, so I assume it's a typo and you mean "bank 1 0x8000-0xFFFF"?

The user will select an option from the UART from the application code. This will set a software reset pin high and trigger the bootloader code.
Not sure if I understood you correctly: You mean you use a port pin to enable the bootloader, but MCU software controls the pin?
Hm... Two things: first, how will this approach work when no application is programmed, meaning there's only the bootloader as it would be on the first programming?
Second, why is the application responsible for starting the BL? Keep in mind, when the application has a bug (as it always would be in the early development state), how do you start the BL?
In my opinion it's the wrong approach: the bootloader should always be started first, checking flash integrity and then starts the application. If a update should be done, the application can inform the BL of the update with software reset flag. If the application needs to reset itself (e.g. like Windows when changing some system parameters) it could be done with watchdog timeout to differentiate it, but better approach would be to use a additional flag (this ensures that the watchdog could be used for it's intended purpose: inform the developer that something went wrong).
Additionally the BL could be started via external signals, e.g. a free port pin tied to LOW on start-up or a 1s timeout where a special character must be received on any interface (e.g. '*' on UART, etc.) to start update mode.

In the BL code, it will check for the logic for the software reset pin. If it is active , it will prompt the user, erase the application codes, download the hex files and jump back to the application program, else it will just jump back to the main flow of the application code(at address 8000H) .
Okay, but in my opinion the ways to start the bootloader should be separated: one way is external signal, and the other is a flag.
Combining both of them might have the result that when your application accidently set the pin and you don't recognise it you might have some... interesting results
However, this also has to be discussed with experienced bootloader forum members. If I'm right Erik Malund has written some bootloader and also many other members. I'm sure they will give additional hints.

However, I had tested out my program. The program does not seem to be running as there is no output.
If there anything I did not take into account for?
My apology for the BL format...
Do not apologize, do EDIT

The code you used is for a F34x device, which is different to F120. If you only copied the code and expected it will run smoothly... sorry, no way

I suggest you do a EDIT on your post above, put your current code into it and then we will see...
- Don't retype the code, use copy&paste
- replace all tabs with spaces
- place the code between < pre > and < /pre > (without spaces)

This should give a readable output for the code.

Regards,

Thank you for your reply!

Erm... memory space from 0x8000-0xFFFF could be any memory bank, so I assume it's a typo and you mean "bank 1 0x8000-0xFFFF

I am referring to Bank 0 from 0x8000-0xFFFF.

Not sure if I understood you correctly: You mean you use a port pin to enable the bootloader, but MCU software controls the pin?
My mistake.It should be software reset flag, not pin.
In my opinion it's the wrong approach: the bootloader should always be started first, checking flash integrity and then starts the application. If a update should be done, the application can inform the BL of the update with software reset flag.
I agree with you. I should have the bootloader start up first. I was focus on how to work on the code update. Therefore, my earlier approach was to start the application first which inform the BL with a software reset flag. Thanks for the correction!

However, this also has to be discussed with experienced bootloader forum members. If I'm right Erik Malund has written some bootloader and also many other members. I'm sure they will give additional hints.

Thanks! Appreciate all your inputs!

The code you used is for a F34x device, which is different to F120. If you only copied the code and expected it will run smoothly... sorry, no way
I did some modification of the codes.

boot.c

#define APPLICATION_ENTRY   0x8000       
void command_handler( void );

void main(void)  //boot_main( void )
{    
 if ( (RSTSRC & 0x02) == 0 ) //   PORSF: it isn't power-on reset        
  {
    if ( (RSTSRC & 0x10) != 0 ) //   SWRSF: request from application            
   {
       command_handler();
   }
 }	    
((void (code *)(void))APPLICATION_ENTRY)();// jump to application entry
}
void command_handler( void )
{                                    
// set WDT to the longest interval    
 PCA0MD   &= ~0x40;     //   disable WDT    
 PCA0CPL4  =  0xFF;  //   set WDT offset    
 PCA0MD   |=  0x40;     //   enable WDT    
 PCA0CPH4  =  0x00;     //   update WDT    
				
 WDTCN = 0xDE;	 // initialize peripherals
 WDTCN = 0xAD;
 SYSCLK_Init();
 PORT_Init ();								    
 UART1_Init();	// establish communication port    				
   if(NewData_InFlg2!=0) //if there is COM Port input
    {
        UM2=1;
        NewData_InFlg2--;
        RxRDPTR_Inc_2();
        BootStrap(); // Erase and load hex file			
        RSTSRC &=0xFE;// software Reset 
		
    }				   
	
      RSTSRC = 0x04;
      OSCICN = 0;                     
 }

Thanks for your help!

Rdgs,
MGear

Then you are overwriting your bootloader!

Scotty wrote: - place the code between < pre > and < /pre > (without spaces)

MGear wrote: < pre >#define APPLICATION_ENTRY 0x8000

Now what do you think "without spaces" means? And how come your code looks so awful? Ok, I'll spell it out: Put the code between <pre> and </pre> to keep the formatting. That is no space after < and no space before >.

And while you're at it, also replace ALL tabs in the code with spaces. Open your code in your favourite editor and choose convert all tabs to spaces from the menu. Then copy and paste the code in the forum.

I am referring to Bank 0 from 0x8000-0xFFFF.
Then you are overwriting your bootloader!

What do you mean by overwriting? I had placed my BL code in 0x0000-0x7FFF and the application code in 0x8000-0xFFFF.

Now what do you think "without spaces" means? And how come your code looks so awful? Ok, I'll spell it out: Put the code between

 and 

May I know what is the difference using

 and 

Thanks for the guide!

What do you mean by overwriting? I had placed my BL code in 0x0000-0x7FFF and the application code in 0x8000-0xFFFF.
Read the datasheet:
You have four 32kB memory banks. Bank 0 is always active from 0x0000-0x7FFF.
In the range from 0x8000 to 0xFFFF you can have bank 0, 1, 2 and 3.

You wrote:
I placed all my codes in bank 0 - BL(common memory 0x0000-7FFF) and application(Bank 0 0x8000-0xFFFF) to optimize my approach.
For us this means you enable bank 0 to be also in the upper half of memory space, and therefore you will overwrite the BL.
Clear now?

May I know what is the difference using...
May I suggest to always check the submitted post? You'll see that your last post might not be what you wanted to write...

Regards,

I am referring to Bank 0 from 0x8000-0xFFFF.
Then you are overwriting your bootloader!

What do you mean by overwriting? I had placed my BL code in 0x0000-0x7FFF and the application code in 0x8000-0xFFFF.

Now what do you think "without spaces" means? And how come your code looks so awful? Ok, I'll spell it out: Put the code between

 and 

May I know what is the difference using

 and 

Thanks for the guide!

But if you write < pre > (that is with extra spaces) then the forum software does not treat it as an HTML tag and shows it unmodified and does not keep formatting in the following text.

Erik

I placed all my codes in bank 0 - BL(common memory 0x0000-7FFF) and application(Bank 0 0x8000-0xFFFF) to optimize my approach.
For us this means you enable bank 0 to be also in the upper half of memory space, and therefore you will overwrite the BL.
Clear now?

Bascially, I can only enable either Bank 0 (0x0000-7FFF) or Bank 0(0x8000-0xFFFF) but not both. Actually, I had referred to AN130 on Configuring a Code Banked Project
Using ́Vision2. My idea is to separate the bootloader and application code. From AN130, I know it is possible configure using Code Banked. However, I do not know whether is this a good method for my code or if I had misunderstood certain memory bank declaration. Thanks for correcting me!

Actually, it is impossible to disable bank 0 at 0x0000-0x7FFF. It is always enabled. At 0x8000-0xFFFF you can enable only one of bank 0, 1, 2 or 3. But I get the feeling you don't have a clue what we are saying or what you are doing.

Actually, it is impossible to disable bank 0 at 0x0000-0x7FFF. It is always enabled. At 0x8000-0xFFFF you can enable only one of bank 0, 1, 2 or 3. But I get the feeling you don't have a clue what we are saying or what you are doing.

Yes, I am a little confuse with the enabling of the which bank 0 to 3 for my application code. Since, I can enable one bank from 0 to 3 at (0x8000-0xFFFF). I should be able to use the memory space from bank 0(0x0000 to 0xFFFF) for my all program codes.
So I was wondering how would this affect my BL?
Or may be is it possible that you can suggest a proper way that I should place my codes?

Forget about the banks and leave them as they come out of reset. I bet you do not need them. Think of the mcu as having just 64k of flash. Then find out how you can link your app at another starting address.

Yes. I agree. I believe that should be my starting point.

I had edited my current codes format from my previous posting.

Thank you for your time!

I said: There is a SIMPLE linker command that will start linking your app (of course 'noiv' will be required) starting at any address above your bootloader.

You seem to have a fixation about banks. I know dozens of seasoned '51 developers that have NEVER used banking ('banks'). The banking is, for all practical purposes, an obsolete technique many have said, and I agree, "if you need banking, you have chosen the wrong processor".

FORGET THAT THERE IS SOMETHING CALLED BANKS and get going with your development.

Since you agreed to forget about the banks I will not elaborate more one them because it will only clutter your view.

I suggest to divide the memory into two pieces: the lower piece for the bootloader and the higher piece for the app. E.g. BL:0x0000-0x3FFF APP:0x4000-0xFFFF

When linking the bootloader restrict the code memory size (0x4000) so it will not accidentally overflow into application space. Assuming you use Keil I cannot help you here because I'm unfamiliar with that.

When linking the app make sure it starts at the offset (0x4000) and is also restricted in memory size (0xC000). Erik says you should use "noiv" but I'm sure you'll need more. Look in the manual for your compiler/linker.

'noiv' keeps the compiler from linking interrupt vectors, which would overwrite the bootloader. also you need the standard ISR switch in the bootloader