STM8 Standard Library and Cosmic produces huge code?

[Willunen]

I'm using ST Visual develop and Cosmic to program a STM8S003K3 and I'm thought it would be nice to use the STM8 Standard Library (downloaded from ST.COM).

Within a very short time I got errors telling me that I tried to put more code in the MCU than possible (8K). I hadn't even finished the initialization of all the peripherals I intend to use.

So I took a look at the compiler settings and changed the optimizations from None to Minimize Code Size.

That did help.

For a few minutes.

A look at the map file shows this: (not the entire file)

                              --------
                               Segments
                               --------
 
start 00008080 end 00008103 length   131 segment .const
start 00008106 end 00009bab length  6821 segment .text
start 00004000 end 00004000 length     0 segment .eeprom
start 00000000 end 00000000 length     0 segment .bsct
start 00000000 end 0000000a length    10 segment .ubsct
start 0000000a end 0000000a length     0 segment .bit
start 0000000a end 0000000a length     0 segment .share
start 00000100 end 00000100 length     0 segment .data
start 00000100 end 00000100 length     0 segment .bss
start 00000000 end 00000584 length  1412 segment .info.
start 00008000 end 00008080 length   128 segment .const
start 00008103 end 00008106 length     3 segment .init
 
 
                               -------
                               Modules
                               -------
 
C:\Program Files (x86)\COSMIC\FSE_Compilers\CXSTM8\Lib\crtsi0.sm8:
start 00008106 end 00008156 length    80 section .text
start 00000100 end 00000100 length     0 section .bss
start 00000000 end 00000000 length     0 section .ubsct
start 00000000 end 00000034 length    52 section .info.
 
Release\main.o:
start 00008156 end 000081da length   132 section .text
start 00000034 end 000000c0 length   140 section .info.
 
Release\stm8s_it.o:
start 000081da end 000081ef length    21 section .text
start 000000c0 end 00000150 length   144 section .info.
 
Release\stm8s_clk.o:
start 000081ef end 000087a3 length  1460 section .text
start 00000150 end 000001e1 length   145 section .info.
start 00008080 end 000080b3 length    51 section .const
 
Release\stm8s_gpio.o:
start 000087a3 end 000088a1 length   254 section .text
start 000001e1 end 00000273 length   146 section .info.
start 000080b3 end 000080db length    40 section .const
 
Release\stm8s_tim1.o:
start 000088a1 end 00009a60 length  4543 section .text
start 00000273 end 00000305 length   146 section .info.
start 000080db end 00008103 length    40 section .const

The timer1 initialization takes 4k ?

This is worth 4k ?

static void TIM1_Config(void)
{
  TIM1_DeInit();																		
  TIM1_TimeBaseInit(15999, TIM1_COUNTERMODE_UP, 999, 0);
  TIM1_ITConfig(TIM1_IT_UPDATE, ENABLE);
  TIM1_ARRPreloadConfig(ENABLE);
  TIM1_Cmd(ENABLE);
}

Do I have to go back to "bare-metal" register setting?

Now I'm only just starting with STM8, so it is more than likely that I'm doing something very wrong, am I?

Wilko

[pacman]

Works like a charm! All repositories pulled and rebuilt.

-No problem with the libraries; I'll likely be building my own anyway, since I have them stored in a different location. ;)

I now also use your configure_stm8 in sdcc-gas (I didn't notice it earlier); this makes my build-script use all your provided scripts and thus it's now quite short. =)

BTW: chmod +x configure_stm8

I wonder if the "--function-sections" and "--data-sections" could be named "-ffunction-sections" and "-fdata-sections" like gcc, so that it would be easier to have common Makefiles / migrate Makefiles ?

(if the -f is already taken, I accept).

Another thing I was thinking about, was to make symlinks in the binaries-folder like ...

stm8-cc -> sdcc

stm8-c++ --> /usr/bin/false

( cd $bin; ln -s sdcc cc; ln -s $(which false) c++ )

... that would make switching compilers very consistent with the gcc-toolchains.

I definitely think both sdcc-gas and stm8-binutils-gdb are valuable.

This was just what sdcc needed in my opinion. :)

[Xavi92]

"-ffunction-sections" and "-fdata-sections" were my intention originally, but SDCC only parses command line arguments starting with two dashes. That could be modified too, but I did not want to spend time on minor features and focused on getting dead code elimination as well as other important features implemented instead. Similarly, "configure_stm8" was just a quick hack that got uploaded to the repository somehow :)

Anyway, if you own a GitHub account, feel free to contribute to both repositories. Since I have already implemented what I needed, it's now up to the SDCC development team to merge these changes so everyone can benefit.

Thanks a lot for your help!

[pacman]

Well, I have a Github account, but I need a new OpenID before I can access it.

This OpenID thing has been on my todo-list for a while, but unfortunately there are more pressing matters (actually lots of those).

My hints were small compared to the work you've done. I very much appreciate your modifications and especially that you've made them publicly accessible. :)

You've moved the STM8 up a lot on my priority list; if I worked at ST, I'd send you one of the best evaluation boards or a bunch of MCUs.

-Note: I just saw that someone made a (low speed) USB driver for the STM8.

[cs]

Hi Xavi92,

I tried your toolchain yesterday and I was able to successfully build it. The stm8-dce-example gave the expected results.

However, when I tried to compile my own application, I encoutered the following error:

-:0: error 33: Attempt to assign value to a constant variable (=)

This SDCC bug seems have been solved eleven years ago in SDCC 2.8.1 #5154 by applying patch #1957148.

I wonder why it still exists in your modified version.

Did you start your work on a recent version of SDCC?

If not, do you think it's possible to apply your modification on the latest mainline SDCC version?

Thanks an regards

[Xavi92]

@cs, the fork was checked out from SDCC's SVN repository at revision 11345, which dates from 2019-08-22. That is newer than the latest release, 3.9.0, that was released on 2019-04-15. See https://sourceforge.net/p/sdcc/code/11345/tree/ for further reference. From my own experience, I have compiled a 30+ file project successfully, although I did find an issue:

• In some cases, when static initialized data is defined inside a scope block, such data is stored into a "memmap" instance namely "statsg" instead of "initializer", generating invalid code when the "--gas" switch is used. As a workaround, the variable can simply be moved outside the scope block.

So please check if there are any "const"-qualified variables that might be unconsciously modified.

[cs]

@Xavi92: you're right, SDCC has some trouble with inlined functions with const arguments. I remove the useless const qualifier and the "error 33" disappeared. I will continue the application build process and I'll let you know the outcome.

[cs]

My aplication building work is complete. I flashed the code generated by SDCC on a real hardware. It seems to be working well.

Nice work, Xavi92!

To reach the same level than STVP+Cosmic toolchain, I need to find how to integrate your toolchain in an IDE and achieve source level debugging. @Xavi92: could you advise me on this subject?

[Xavi92]

Ake explains how to run stm8-gdb from Eclipse on the stm8-binutils-gdb website: https://stm8-binutils-gdb.sourceforge.io/

I have not tried it myself since I am used to GDB TUI instead, but I might give it a try too.

OTOH, I fixed some issues affecting sdcc-gas that were reported by Philipp. Among them, the "--gas" switch was changed to "--asm=gas". So please update your local copy of sdcc-gas when possible.

[cs]

Hi Xavi92.

I'll take a look on your debugging options.

For now, I've updated my copy of sdcc-gas with your last version 3.9.3 and encountered a new unexpected error. In my code:

memcpy(cmd, "XXXX", 4);

generates an error: undefined reference to '___str_0'

I found a workaround:

{

const char[] s="XXXX";

memcpy(cmd, s, 4);

}

does not generate the above error.

I didn't encouter this behaviour with the previous version.

[Xavi92]

Hi @cs​ ,

You are right: that bug has appeared after fixing the following regression issue: https://github.com/XaviDCR92/sdcc-gas/issues/4 . I have pushed a new commit that fixes both issues.