STM8 _block_cksum161

[irfan karazor]

Posted on April 12, 2017 at 11:01

i used _blockcksum160 then we increase code size 32K to 64K

depends on code size increased;

we changed memory model +modsl0 to modsl.

We changed library list libislo.sm8;libmo.sm8 to libisl.sm8;libm.sm8

We changed startup file crtsi0.sm8 to crtsi.sm8.

When we run software, during runtime check. Ä°t fails.

_block_checksum160() return CRC_ERROR.

Then we start to use _block_checksum161() however, it return error;

#error clnk Debug\canli.lkf:1 symbol _MSB_RunCrc16Chk not defined (Debug\_block_cksum161.o )

#error clnk Debug\canli.lkf:1 symbol _MSB_RunCrc16ChkInv not defined (Debug\_block_cksum161.o )

As i understand that stm8l_stl_classB_var.h ,which sent by ST guys, should update.

Where can be get 

stm8l_stl_classB_var.h file which suit for 64K

stm8l_stl_classB_var.h :

#ifdef _COSMIC_

#pragma section @near [RUN_TIME_BUF]

/* Buffer to store original RAM content during run-time tests */

EXTERN NEAR u8 RunTimeRamBuf[RT_RAM_BUF_SIZE];

/* RAM pointers for run-time tests */

EXTERN NEAR u8 *p_RunTimeRamChk;

EXTERN NEAR u8 *p_RunTimeRamChkInv;

#ifdef STL_VERBOSE

EXTERN NEAR s16 FreqDifDisplay; /* Not really a Class B variable, but useful for debugging */

#endif /* STL_VERBOSE */

#pragma section @near [CLASS_B]

EXTERN NEAR u16 MarchOverlayGap; /* gap in memory due to March test overlay */

EXTERN NEAR u16 CtrlFlowCnt; /* program flow execution at start */

EXTERN NEAR u8 LSI_HSIStartUpFreqkHz; /* First measure LSI over HSI stored */

EXTERN NEAR u8 LSI_HSEStartUpFreqkHz; /* First measure LSI over HSE stored */

EXTERN NEAR u16 LSI_StartUpPeriod; /* Initial measure of LSI - reference for run-time checks */

EXTERN NEAR u16 LastCtrlFlowCnt; /* Control flow counter from one main loop to the other */

EXTERN NEAR const u8 *p_RunCrc16Chk; /* Pointer to FLASH for crc16 run-time tests */

EXTERN NEAR u16 CurrentCrc16; /* Current FLASH 16-bit Crc */

EXTERN NEAR u16 CurrentDesc; /* Current Descriptor Address */

EXTERN NEAR u8 CRCBlockIndex; /* Counter needed for partial CRC test */

EXTERN NEAR u16 MarchOverlayGap_; /* gap in memory due to March test overlay */

#pragma section @near [STACK_BOTTOM]

/* Magic pattern for Stack overflow in this array */

EXTERN NEAR volatile u8 StackOverFlowPtrn[4];

#pragma section @near [CLASS_B_REV]

EXTERN NEAR u16 MarchOverlayGapInv;

EXTERN NEAR u16 CtrlFlowCntInv;

EXTERN NEAR u8 LSI_HSIStartUpFreqkHzInv;

EXTERN NEAR u8 LSI_HSEStartUpFreqkHzInv;

EXTERN NEAR u16 LSI_StartUpPeriodInv;

EXTERN NEAR u16 TickCounterInv;

EXTERN NEAR u16 LastCtrlFlowCntInv;

EXTERN NEAR const u8 *p_RunCrc16ChkInv;

EXTERN NEAR u16 CurrentCrc16Inv;

EXTERN NEAR u16 CurrentDescInv;

EXTERN NEAR u8 CRCBlockIndexInv;

EXTERN NEAR u16 MarchOverlayGapInv_;

#endif /* _COSMIC_ */

[irfan karazor]

Posted on April 12, 2017 at 14:23

i add below parts;

at [CLASS_B] section:

            EXTERN NEAR u16 MSB_RunCrc16Chk;          /* Current MSB of the address at FLASH */

and [CLASS_B_REV] section there:

            EXTERN NEAR u16 MSB_RunCrc16ChkInv;     /* Current MSB of the address at FLASH */

Compiler is ok however,

When we run software, during runtime check. Ä°t fails.

_block_checksum161() return CRC_ERROR.

How can i get 

_block_checksum16

x

() for memory model 

modsl (64K flash memory)?

[luca239955_stm1_st]

Posted on April 13, 2017 at 12:07

Hello,

from the Cosmic point of view, all you need to make the checksum work again after moving to a 'far' (>0xFFFF, that is 32k of code for the stm8) memory model is to use the far version of the checksum verification routine, and that is done automatically when you link libi instead of libi0.

For your case however, you seem to use some checksum verification routines that are not provided by us (_

block_checksum161()

), so the obvious answer would be to check with the provider of those routines (I guess that's ST) because I also see that some header files that you use force some variables @near, so I'm not sure if there is a @far version of the same file for when you change the memory model or if these variables are supposed to stay @near even when other parts of the code go @far..

If you don't get out of it easily you can send your whole project to us and we'll take a look at it.

Regards,

Luca

[irfan karazor]

Posted on April 13, 2017 at 12:43

i have done another work 

. Depends on these work. May you result anything?

We had one segmet(Code and constant) which locate 0x8080 to 0x17fff.

_block_checksum161() return CRC_ERROR.

Now we have 2 segment. First segment  for constant and code where locate 0x8080 to 0xffff, seconds segment is for .text where locate 0x10000 to 0x17ffff. 

block_checksum161() return OK

Unfortunately we can not use first segment for .text.  .text which locate  0x8080 to 0xffff is not used.

?f .text of secons is overflow, it do not use .text of first segment. ?t gives overflow error.