Topic : STM8S208 - library code running past address space 0x10000

Forum : ST7/STM8

Original Post
Post Information Post
August 12, 2012 - 9:15am
Guest

We've just purchased the enterprise package for the STM8 compiler.
I've left a message as a support request so I'm kind of doubling up here.

We're using the STM8S208CB. The chip has 128Kb of program flash that starts at 0x08000.

Our project requires that our apps project code resides at 0x10000 and beyond. and that a bootloader will reside between 0x08000 - 0x0FFFF.

I don't have a problem getting some simple self written code (led blink, pll setup) to compile and the hex file shows that the code etc appears at the expected addresses.

My problem is that if I add any STM8 library files to the project, I get some link errors of the following type:

***ERROR 107 : ADDRESS SPACE OVERFLOW
-SEGMENT: CSTDLIB_DIVU32(DIVU3232)

***ERROR 107 : ADDRESS SPACE OVERFLOW
-SEGMENT: CSTDLIB_PG2BC(MV4_PG2BC)

***ERROR 107 : ADDRESS SPACE OVERFLOW
-SEGMENT: ?STR?STM8S_TIM4(STM8S_TIM4)

***ERROR 107 : ADDRESS SPACE OVERFLOW
-SEGMENT: CSTDLIB_PG2SK1(MV4_PG2SK1)

I suspect this is actually an issue with the Raisonance compiler Library? I guess the code of the library API functions causes the compiler to invoke some incompatible function from the compiler library? I am running Large Model.

John Dowdell
Questek Australia
Am I doing something wrong?
This is very frustrating

Replies
Post Information Post
+1
0
-1
August 14, 2012 - 1:49pm
Raisonance Support Team

Hi,

Are you sure that your memory is not really full?

How do you proceed for placing your code at 0x10000?
The same procedure should be applied to all the code, including libraries.

Why do you want to add library files to the project? The linker should do it on its own, you don't need to do it yourself...???

Please clarify.

Best Regards,

Vincent

+1
0
-1
August 19, 2012 - 9:04am
Guest

Hi, thanks for the reply. I guess I need to add some detail and explain what I mean when I say

+1
0
-1
August 20, 2012 - 11:27am
Guest

The thread only shows one line of my reply. Is it still being moderated or did something go wrong when i submitted it?

+1
0
-1
August 20, 2012 - 1:50pm
Raisonance Support Team

Hi,

The snipping of your post is not due to moderation. Not purposefully at least.

It sems some posts are truncated but we don't know why. Probably a bug in the forum. We're working in it.
In the meantime I advise to copy your text in a file before posting it if it is long.

Best Regards,

Vincent

+1
0
-1
August 21, 2012 - 4:40am
Guest

Thats a pity. I did copy it to a text editor but I didnt save it and my computer rebooted.

I'll try again shortly , but, in brief my suggestion was that there was probably an issue with 32 bit arithmetic in the RCSTM8xx.LIB when used in an address space of 0x10000 or above. Or that the incorrect RCSTM8xx.LIB is being chosen by the compiler/linker when 32 bit arithmetic is used in an address space above 0x10000.

I don't know if the issue is confined to 32 bit arithmetic but that is what i had been able to prove.
The microcontroller is an STM8S208CB. It has 128KB of program space that begins at 0x8000. In my post that didnt appear, I was tring to show tests I had done with code that was only a few lines where:

1. 32bit arithmetic invoked in an address space above 0x10000 gave linker errors.
2. 16bit arithemtic invoked in an address space above 0x10000 was ok.
3. 32bit arithmetic invoked in an address space just below 0x10000 (e.g. 0xF100) was ok.
4. 16bit arithmetic invoked in an address space just below 0x10000 (e.g. 0xF100) was ok.

Where my test program resets to 0x10000, my CODE segment is changed to being at 0x10000. Also a small startup.asm sets the current segment to 0x10000. The startup.asm loads the reset vector with an adrress 0x11000. my entry point is absolute addressed at 0x11000. I'll try to post code shortly again to illustrate this.

John Dowdell
Questek Australia

+1
0
-1
August 21, 2012 - 4:49am
Guest

Here's an example of where 32bit arithmetic won't link above 0x10000

small startup.asm:


CSEG AT 010000H
DB 082H,001H
DW 01000H

END


volatile unsigned long  ui32BigNumber = 0;
volatile unsigned long  ui32SmallerNumber = 0;
volatile unsigned long  ui32Result = 0;

at 0x11000 void appentry(void)
{
    ui32BigNumber = 24000000;
    ui32SmallerNumber = 240000;
    ui32Result = ui32BigNumber / ui32SmallerNumber;
    while (1);
}

This causes the following linker errors:

***ERROR 107 : ADDRESS SPACE OVERFLOW
-SEGMENT: CSTDLIB_DIVU32(DIVU3232)

***ERROR 107 : ADDRESS SPACE OVERFLOW
-SEGMENT: CSTDLIB_PG2IX(MV4_PG2IX)

***ERROR 107 : ADDRESS SPACE OVERFLOW
-SEGMENT: CSTDLIB_MV4IX2SK(MV4_IX2SK)

***ERROR 107 : ADDRESS SPACE OVERFLOW
-SEGMENT: CSTDLIB_IX32(DIVUIX32)

***ERROR 107 : ADDRESS SPACE OVERFLOW
-SEGMENT: CSTDLIB_MV4BC2IX(MV4_BC2IX)

***ERROR 107 : ADDRESS SPACE OVERFLOW
-SEGMENT: CSTDLIB_INCCX(INC_CX)

IGNORED SEGMENT
CSTDLIB_DIVU32
CSTDLIB_INCCX
CSTDLIB_IX32
CSTDLIB_MV4BC2IX
CSTDLIB_MV4IX2SK
CSTDLIB_PG2IX

LINK/LOCATE RUN COMPLETE, 6 ERRORS FOUND.

+1
0
-1
August 21, 2012 - 5:07am
Guest

Sorry, that second code window in the last example was my main.c

the following is the same example but in a space below 0x10000.
The CODE segment has been changed to 0xF000
startup.asm


CSEG AT 0F000H
DB 082H,000H
DW 0F100H

END

main.c


volatile unsigned long  ui32BigNumber = 0;
volatile unsigned long  ui32SmallerNumber = 0;
volatile unsigned long  ui32Result = 0;

at 0xF100 void appentry(void)
{
    ui32BigNumber = 24000000;
    ui32SmallerNumber = 240000;
    ui32Result = ui32BigNumber / ui32SmallerNumber;
    while (1);
}

this compiles and links ok without any errors.

+1
0
-1
August 21, 2012 - 6:16am
Guest

the following code is to show that there's nothing wrong with linking other code in the space beyond 0x10000.
The CODE segment is changed back to start at 0x10000
startup.asm:


CSEG AT 010000H
DB 082H,001H
DW 01000H

END


volatile unsigned short  ui16BigNumber = 0;
volatile unsigned short  ui16SmallerNumber = 0;
volatile unsigned short  ui16Result = 0;

at 0x11000 void appentry(void)
{
    ui16BigNumber = 24000;
    ui16SmallerNumber = 2400;
    ui16Result = ui16BigNumber / ui16SmallerNumber;
    while (1);
}

this compiles and links ok

+1
0
-1
August 21, 2012 - 2:41pm
Raisonance Support Team

Hi,

Thanks for the detailed feedback.

I was able to reproduce your problem and I confirm your observations.

I checked that the linker takes the correct library. That's not the problem.

I looked at the sources of the libraries and indeed they are (some functions, but in all versions of the lib) explicitly designed for running in the x8000-x10000 region.
(they are constrained by the INSECTION0 keyword)

The problem does not appear in your 16-bits example because it is simple enough that it is not necessary to use the lib in this case.
The division is performed as part of the appentry function's code.
But the same problem is present in the 16-bits libraries. (at least some of the functions)

I imagine that it has been done this way for performance reasons.
(allowing to make Small-Model-calls for inter-lib function calls even if the application is in Large Model, and maybe other things)
But there might be other reasons that I did not see.

Of course in your particular case it does not work.
You would probably need an alternate set of libraries, with less optimal code, that can be placed after 0x10000.

Unfortunately, our STM8 expert (Stephane) is on vacation right now and for two more weeks, and this is beyond my competence.
Can you wait two weeks for a more complete answer from Stéphane?

Also, even if we do it, the alternate set of libraries would be less performant in terms of both speed and code size.
So it would be simpler, faster and more efficient if you could rearrange your code and place some of the application in the lower section of code...?

I'm sorry that I cannot help more than this. I'm not the STM8 expert here.

Best Regards,

Vincent

+1
0
-1
August 22, 2012 - 11:24am
Guest

Thanks for the reply and the confirmation.

This does put us in a difficult position. If we thought or knew this might be a problem, we would have thought twice about purchasing the licence. Yes we do have some time constraints that might lead to penalties for us if we are unable to deliver in time.

Yes, I would have expected a form of the library that performs the same function and produces the same result where the code will operate in a 24 bit addressing way.

Yes, we are aware that large model compiling and such 24 bit address sensitive compiler library calls will take longer to execute and take up more code space. This is how we need the code to run.

As far as the space below 0x10000 is concerned, this is occupied by another program. There's not really any space to play with there.

I'm a little surprised that my scenario has not been covered by some compiler/library option in the first place. I'd be further surprised if I was really the first to encounter it.

John Dowdell
Questek Australia

+1
0
-1
August 22, 2012 - 2:42pm
Raisonance Support Team

Hi,

As far as I know this is the first time this problem is mentioned, but as I said I'm usualy not in charge of STM8 support, so maybe there is already a solution that I'm not aware of.

If you cannot wait two weeks I will enquire deeper right now. I understand your need and its relevance. It's just bad luck you raise this particular problem at this particular time.

I'll come back to you later today, or tomorrow at last.

Best Regards,

Vincent

+1
0
-1
August 22, 2012 - 6:03pm
Raisonance Support Team

Hi,

After enquiring, it appears that the library functions don't really need to be in section 0, but that they only need to be all in the same section. This is good news because it means a "simple" linker reconfiguration should solve the problem. There will be no need to rewrite all the libraries. :)

We have been able to make a quick and dirty workaround in the linker that will allow you to place them all in section 1 (0x10000-0x1FFFF):
ftp://www.raisonance.com/temp/STM8/test_120822_workaround_libafter0x10000.zip

Maybe a cleaner solution can be found for the official release, but we'll see this after my colleague's vacations.
At least this workaround should allow you to get going with your urgent development.

Please let us know if there are other problems.

Best Regards,

Vincent

+1
0
-1
September 17, 2012 - 11:29am
Guest

I had been meaning to come back to say this was working out for us. Thanks for your efforts. Our code is now linking and operating as expected in the space beyond 0x10000.
The global variable initialisation code uses 16 bit addressing so 24 bit addressed stuff gets broken. We're ok to sort out initialisation of variables ourselves but I have a question about copying INRAM functions. But I will start another thread.