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

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

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

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

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.

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.

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

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

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

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

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