We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi everyone. So far I've only done some rather small 8051 projects, mostly with variants that had less than or equal to 64k memory. Now I have a project which includes fairly large amounts of code-data running on SiLabs' C8051F12x, which has 128k. Since inherently only 64k are accessible, I need to use code banking. However, once - as noted in the application notes - I include STARTUP.A51 and the L51_BANK.A51, my application throws an Module Name Not Unique Warning for C_STARTUP. In the KEIL Knowledge Base, I found the suggestion to rename C_STARTUP to C_STARTUP_MAIN to resolve the issue. I did so, but then I got a code overlap warning at 0000H to 0002H. I never had to deal with an overlap I didn't actually cause myself (manually) before, so I'm not sure how to resolve it. In the M51, I found ... C:0000H PUBLIC ?C_STARTUP_MAIN (and, further down) C:0000H LINE# 85.
I assume those are the overlapping segments, no? I'm not sure how to progress in resolving the warning, could anybody shed some light on this for me? Thanks alot! Steven
"Also, I was under the impression that the idea of putting stuff as XDATA involved making them far constants, yet you sound as if this wasn't necessary at all."
You don't need to use any 'far' modifiers just to get your constants from CODE to XDATA as I described. You also don't need XBANKING.
As I said, "banking" is a misnomer here!
Hold on a second, is that to mean I'm thinking way too complicated here and just need to change any variable declaration from code to xdata and it'll be located in the upper 64k without further ado?
"just need to change any variable declaration from code to xdata and it'll be located in the upper 64k without further ado?"
No.
If you do that, it will take runtime code to load the values into XDATA - the initialisation values will still be stored in CODE space, thus defeating the object of the exercise!
The purpose of this XCONST stuff is to stop the tools from putting constants into CODE space in the first place. It means that you end up with a HEX file that loads code into CODE-space ROM, and constants into XDATA-space ROM.
The LX51 linker has support for this built-in; I guess you could mimic it manually yourself with BL51 and, probably, some assembler and/or a tool like SRECORD...?
I see ... I think. ;p
I'll first try to look into switching to the extended linker. As I have this particular project set up in the SiLabs IDE so far (I took a past project for another F8041x variant as starting point and expanded from there), it's not so simple as ticking a button, but I'll try to migrate the project to uVision and go on there. Not sure whether I'll manage to get there today, since I have some other issues I need to spend time on - otherwise it'll have to wait til monday. Would there be anything else to be considered in order to enable the built in support you mentioned?
Anyway, thank you for your input. If anyone else can shed some light on how to relocate the startup function so it doesn't cause overlaps, this would still be appreciated, since I have a feeling I might run into this again at some time. :/
"The purpose of this XCONST stuff is to stop the tools from putting constants into CODE space in the first place."
Consider the basic 'C' program:
void main( void ) { printf( "Hello, world\n" ); }
The string literal "Hello, world\n" will be placed in CODE space - consuming 14 bytes.
The code is effectively equivalent to:
void main( void ) { code hello_string[] = "Hello, world\n"; printf( hello_string ); }
If you were to write
void main( void ) { xdata hello_string[] = "Hello, world\n"; printf( hello_string ); }
The 'C' startup code would have to initialise the xdata variable - so the text of the string would still have to be stored in the code space!