Topic : eeprom keyword (STM8)

Forum : ST7/STM8

Original Post
Post Information Post
June 9, 2009 - 4:16pm
Guest

I am trying to place a string in the eeprom space:

char eeprom device_type[4] = {'X','Y','Z',0};

The problem that I have is that it places it at the wrong address: 0x800 instead of 0x4000.

I am using the keyword incorrectly?

Replies
Post Information Post
+1
0
-1
June 9, 2009 - 5:22pm
Raisonance Support Team

Hi Edge,

If you are using Ride7, it should work fine. Just ensure that you are using the latest version (released 2009/05/20) and Ride7/RKit-STM8 will do everything automatically.

If you are using STVD, the EEPROM is not automatically supported yet, and you have to add the appropriate linker directives on its command-line (it is called "user options" in the linker settings).

For instance on STM8S208RB:EEPROMSTART(0x4000) EEPROMSIZE(0x800)

Regards,
Bruno

+1
0
-1
June 10, 2009 - 8:20pm
Guest

I am using STVD and tried your suggestion. I get the following linker warning

***WARNING 4 : CODE SPACE MEMORY OVERLAP
ADDRESS: 4000

Any thoughts?

TYPE BASE LENGTH RELOCATION SEGMENT NAME
---- ---- ------ ---------- ------------

* * * * * * * * E E P R O M M E M O R Y * * * * * * * *

***WARNING 4: CODE SPACE MEMORY OVERLAP
ADDRESS: 4000
EEPROM 004000H 000004H INSECTION ?EE?SERIAL_NUMBER

* * * * * * * * D A T A M E M O R Y * * * * * * * *
000000H 000008H OVERLAID GROUP ***
DATA 000000H 000006H ------------- ?D0??XCP_ON_GET_DAQ_LIST_INFO?XCP_ON_GET_DAQ_LIST_INFO
DATA 000000H 000008H ------------- ?D0??XCP_ON_CONNECT?XCP_ON_CONNECT
DATA 000000H 000007H ------------- ?D0??XCP_ON_GET_DAQ_EVENT_INFO?XCP_ON_GET_DAQ_EVENT_INFO
DATA 000008H 000004H PAGE0 SEG_REGISTERS
DATA 00000CH 000002H INSECTION0 ?ZDT?EGT_PROCESS
DATA 00000EH 000001H INSECTION0 ?ZDT?XCP_CACHE
DATA 00000FH 000002H INSECTION0 ?ZDT?EVENT
DATA 000011H 000005H INSECTION0 ?ZDT?TIMER
DATA 000016H 00000CH INSECTION0 ?DT?STM8S_CLK
DATA 000022H 000004H INSECTION0 ?DT?EGT_PROCESS
DATA 000026H 000004H INSECTION0 ?DT?MAIN
DATA 00002AH 000010H INSECTION0 ?EDT?STM8S_CAN
DATA 00003AH 000024H INSECTION0 ?EDT?EGT_PROCESS
DATA 00005EH 00012CH INSECTION0 ?EDT?XCP_CACHE
DATA 00018AH 000083H INSECTION0 ?EDT?XCP
DATA 00020DH 00001EH INSECTION0 ?EDT?ADC
DATA 00022BH 000002H INSECTION0 ?EDT?EVENT
00022DH 0011D3H *** GAP ***
DATA 001400H 000400H UNIT ?C_STACK?SEG

* * * * * * * * C O D E M E M O R Y * * * * * * * *
CODE 008000H 000004H AT ?CO?STARTUP_V_Z00
CODE 008004H 00000DH INSECTION ?PR??ADC2_STARTCONVERSION?STM8S_ADC2
008011H 000001H *** GAP ***

+1
0
-1
June 11, 2009 - 9:42am
Raisonance Support Team

Hi,

I do not have extensive knowledge about STVD, but it looks like another segment is taking the place at address 0x4000.

Have a closer look at your linker's command line, you should find the guilty one. Although I am not sure how you can fix the problem from the STVD interface.

If you are using Raisonance hardware such RLink or REva, I would strongly recommend that you switch to Ride7 instead of STVD; issues like the one you meet are natively handled in Ride7. And productivity of the tool is excellent.

Regards,
Bruno

+1
0
-1
June 11, 2009 - 7:00pm
Guest

I tried to take your advice and rebuild my application using Ride7. I want to have a library and an application that links to the library. I created a library project, added a number of files and everything built fine. I then closed the project. When I re-open the library project all of the paths are wrong for the source files and Ride can't find them. For example the correct path for stm8s_wwdg.c is "C:\dev\EAS_Devices\FW\tm8s_wwdg.c". Ride now thinks the file is located at "C:\dev\FW\tm8s_wwdg.c". It is missing the entire "EAS_Devices" path. This is for all of the files in the project. This does not appear to be the case for an application project I created but is definitely a problem for libs. So far, the productivity is a bit less than excellent :( Any suggestions?

+1
0
-1
June 12, 2009 - 9:38am
Raisonance Support Team

Wow, Ride7 also embeds an automatic file-renaming tool! Great feature!

Joke apart, this looks like a bug.
We made the experiment in our labs but did not find any issue concerning the library source file names. Could you send us the steps you followed in order for us to reproduce the problem ?

In order to quickly fix the problem, open your .rapp file in your favorite editor and change the file names by hand. this should do the trick.

Thanks,
Bruno