#2421 STM8 code in RAM

[gicking]

hello,

STM8 flash w/e block operations have to be executed from RAM. However, when compiling any source file with option --codeseg MYSEG I get this message:

sdcc -mstm8 --std-sdcc99 -DSTM8S207 --codeseg MYSEG -c RAM_routines.c -o RAM_routines.rel
RAM_routines.asm:96: Error: <u> undefined symbol encountered during assembly
removing RAM_routines.rel
make: *** [RAM_routines.rel] Error 1

The respective error line in file RAM_routines.asm reads
.area MYSEG (CODE)

Attached please find an example which toggles GPIO from RAM (just type "make"). Execution from flash works.

The error occurs under MacOSX and Win7, and sdcc -v yields

SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 3.5.0 #9253 (Jun 20 2015) (Mac OS X i386)
published under GNU General Public License (GPL)

---

initial response by Maarten:

It seems it outputs an extra (CODE) piece that should only be used on Harvard architectures (e.g. mcs51).

[Wolle K.]

To execute code from RAM, you'll have to copy the code from Flash to RAM after RESET. I don't see any support for this by sdcc. Just telling compiler to place code at a RAM address won't work.

[Ben Shi]

Fixed in reversion [r9331].

[Maarten Brock]

Although certainly fixed for the command line option, I reopen this to also tackle the corresponding pragmas.

[gicking]

hi Maarten,

great to hear that the bug is already fixed :-) I'll try it as soon as r9331 binary for OSX is available for download.

One stupid question, though: what do you mean with "corresponding pragmas"? Thanks in advance!

[Ben Shi]

Corresponding pragmas are added in reversion 9332.

To Gicking,

you can specify codeseg via either "--codeseg" in the command line option or "#pragma codeseg" in the source files.

[gicking]

hi Ben,

thanks a lot for the information! This seems similar to Cosmic compiler #pragma section (NAME).

Sorry but two more questions on this topic:
1) can I now also mark only parts of a sourcefile as RAM code? Before it was only per file.
2) do I have to copy code to RAM manually e.g. via memcpy()? If yes, is there a function or variables available with starting address and length? Or do I have to extract them from the mapfile?

For your support thanks a lot in advance!
Georg

[gicking]

hi again,

ok, code compiles now :-) However, the hexfile contains the respective code literally at the specified address (in RAM) -> it will only exist after upload, but won't survive a reset...? So I guess the way to go for me is to link the code to a fixed address in flash, then copy it manually to RAM after each reset, then LCALL to that address when needed. Is my understanding correct?

Regarding above post:
ad 1) tested it and the #pragma apparently is per file - which is ok for me

ad 2) assuming my understanding is correct, I guess I can pass the start address from Makefile to linker (via -bRAM_CODE=addr) and to compiler (via -DRAM_CODE=addr). But how about length of the routine? Mapfile?

Again thanks for your great work and the support!

Georg

[gicking]

attached please find fixed example for SDCC and Cosmic Thanks again! :-)

[Maarten Brock]

You have to link at the ram address else all jumps and calls to it will jump to flash. You'll have to post-process the generated hex-file to move the section to an address in flash. And you'll have to use memcpy to copy it from flash to ram. You can use srecord for the post-processing.

The linker does create symbols with the start address and length but they are accessable from assembly only. Some small pieces of inline assembly should be able to fetch them for you.

int get_length(void)
{
    volatile int length;
    __asm
        ldw x, #l_RAM_CODE
        ldw (0x01, sp), x
    __endasm;
    return length;
}