Serious bootloader problem

The bootloader is mapped into the addressable memory at 0xF800.
I know of no use for a non-addressable memory, do you mean flash?

Did we cross a magic border? A border which is at 0xF7FF?
easy to see in the .map file

Erik

OK, in other words: this is about the 64k flash memory, also called CODE range. I know that the bootloader is only mapped at 0xF800, not programmed there in the same memory space.

But, it is pretty obvious that when compiling code which size is >0xF7FF, the code still starts the bootloader (LCD display goes blank), but
- it does not set the BLJB anymore (which we use for a certain reason) and
- it does not initialise the UART for immediate communication and reprogramming,
so the possibility to reprogram the chip in ISP is lost atm.

The code to set BLJB and start the bootloader is still the same in all the versions.
The start code is quite cryptic for me:

*((const void(code*)(void)) 0xF800 )

@Hans-Bernhard
A very good thought! Looking at the memory model, it says that the CODE space from 0xF800 is not accessible anymore once the ENBOOT bit in AUXR is set. This bit is set by our code directly before starting the bootloader. So it may be fixed by putting the jump code definitely somewhere below 0xF800, I guess.

@Dominic:
Here it's different. The bootloader is not im ROM, it's in flash. With the 64k flash version of the 8051, it is located at address 0x10000 for programming. Means, the Atmel bootloader could be replaced by a custom one or by another Atmel bootloder, for example the CAN bootloader. Since the code cannot access the address 0x10000, setting a bit in AUXR register maps the bootloader space into code space from 0xF8000 which seems to make code between 0xF800 and 0xFFFF inaccessible.

Also, we don't use banking. The memory ranges are defined. DATA, IDATA, XDATA, PDATA and CODE.
64k flash (CODE), 2k RAM (XDATA, PDATA, DATA, IDATA) is all we use.
The thing with the inaccessible bootloader hasn't happen before, since the code always was smaller than end address 0xF7FF.

As said before, I need to find a way to put the bootloader jump code definitely into CODE space below 0xF800.

OK, I see. I cannot tell you how to rescue existing installations. But you can prevent this from happening in the future:

Just add this to your code somewhere:

const ubyte code loader_mem[0x200] _at_ 0xF800;

This will block your linker from putting anything there. I've done this to protect the data flash of the XC878 (which I can write to at runtime with some arcane timing voodoo and the spare 0xA5 op-code), so the linker doesn't put any code into it (a theoretical possibility only, my code sizes don't go much beyond 20k so far).

However it looks like you need the space. So your alternative would be to define a custom segment in a safe place for the function that calls the bootloader and only setting AUXR there. Of course that function may not call any other function outside of your safe segment.

You can define custom segments in the linker configuration, open it and just press the help button. The online help works quite well in those dialogues. I think the manual also has an example how to put a specific function into a custom segment.

Thanks for your help, but I guess you mean something different.
The API code for jumping to the bootloader switches the ENBOOT bit in AUXR to one and then only executes the jump code to start the bootloader. This fails, because the compiled code may be at an address higher than 0xF7FF or lower. If higher, the code is not accessible anymore after mapping the bootloader to 0xF800-0xFFFF.

So I actually need to place the whole function void __api_start_bootloader (void) to a certain code memory position. But I'm still on finding out how. The _at_ directive does not help here.

As I said create a custom segment and put the __api_start_bootloader() function into it.

That's problematic. The Keil documentation of compiler and linker explains WHAT you can do, but not HOW. The linker can link code to a certain address, but there is no linker file.
The compiler created .obj files and the linker links them. But these are not editable, nor can they be loaded into uVision. Here in the forum are only threads about linking variables to certain addresses.
I can create code segments in the target dialog (BL51 Locate), but that's all. I would like to assign a C file or just a function to a specific code segment, but there's no way. There are also no compiler directives for that.

Use the LX51 linker. Add the following to User Segments:

?PR?RUN?MAIN(C:0x1337)

It locates the function run() in the file main.c at code memory address 0x1337.

Took me the better part of 15 minutes to find out and test.

You need to relax a moment and actually look at all the tools you're using, and their documentation. Not just that of the linker itself.

As you've found out already, in uVision project, it's uVision that controls the linker. And of course there are changes you can make to how it does that. And guess what, the BL51 manual even tells you where in uVision you're meant to control which BL51 directive. That's what each directive's description has that "uVision" entry for.

Project/Options
Select the Target tab
Check LX51 instead of BL51
Select the LX51 Locate tab
Add the following line to User Segments:

?PR?function?module (C:0x2000)

function is the name of the function you want to place in the code space
module is the name of the C module, e.g. MAIN for main.c
Click OK
Hit F7

And afterword I suggest you learn a bit about the tool you're using. Fiddle with all the options, learn what they mean.

I didn't do this ever before and I needed 5 minutes to figure the principles out and less then 10 minutes to apply them.

You came along quite competent in your first post and I thought you just needed a nudge into the right direction. Instead I did all the work for you, just to disprove that ridiculous claim that µVision doesn't let you do this.