Topic : CRC Check failing

Forum : ST7/STM8

Original Post
Post Information Post
September 26, 2012 - 11:14am
Guest

Hi,

I am trying to crc check the contents of the flash, however without success.

I have STM8 with 8KB flash.

Linker settings :
REMOVEUNCALLED PRESERVE(?PR??APP_MAIN?APP_MAIN) FILLGAP(0xCC) CRCRANGE(0x9000,0x9FE0)
Relocation Directives:
CODE(?PR??APP_MAIN?APP_MAIN(0x09080), ?PR??TASK_CHECK_SOFTWARE_UPDATE?APP_MAIN)

In the code, I called the function:
if(_check_crc16x_() == 0)
{
// invalid Application Code
}

With the above settings I found the following in the map file:
CODE 009FE0H 000012H AT _crc_seg_

----------------------------------------------------------------------
While debugging, I noticed the values of the crc structure in the memory:
009FE0 0F E0 90 00 F8 86 00 00 00 00 00 00 00 00 00 00 ................
009FF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F ................

----------------------------------------------------------------------

But the _check_crc16x_() is failing.

I even tried to include the sources from %ridedir%/\Inc\Sources\ST7-STM8\IEC60335 directory.
The tcrc16X_info structure is correctly populated.

However I can only see that the computed value of crc16 using the _check_crc16x_() is different from what is stored at 0x9FE0..

What am I missing in my settings?

Thank you.

..
..
..
..
..
..
Replies
Post Information Post
+1
0
-1
September 26, 2012 - 3:00pm
Raisonance Support Team

Hello,

Did you check that the gaps between 0x9000 and 0x9FE are correctly filled with 0xCC?

Can you give us your RKit-STM8 version number?

Stéphane
+1
0
-1
September 27, 2012 - 1:59pm
Guest

My RKit-STM8 version number is RKit-STM8_2.44.12.0199

The gaps are correctly filled with 0xCC

Later I noticed that CRC check between 0x9000 to 0x9fe0 passed.
(to my knowledge i did not change anything much)
But crc check between 0x8000 to 0x9fe0 failed.
Now I think I am not anymore sure about the behavior. There must be something I am missing.

I tried to track it down.
Any crc check for region starting 0x812E(and above) to 0x9fe0 is always passing.
Any crc check for region starting 0x812D(and below) to 0x9fe0 is failing.
May be there is more than 1 factor(not just filling the gaps with 0xcc) on which crc check result is based??

Part of the Memory map is as shown below:
CODE 008074H 000004H AT ?IT?VECTOR#27
CODE 008078H 000004H AT ?IT?VECTOR#28
CODE 00807CH 000004H AT ?IT?VECTOR#29
CODE 008080H 000032H INSECTION0 CSTDLIB_CRC16
CODE 0080B2H 00001BH INSECTION0 CSTDLIB_MULU1616
CODE 0080CDH 000001H INSECTION PR??TRAP_SW_IRQ_HANDLER?STM8S_INTVECTOR_TA
CODE 0080CEH 00001AH INSECTION0 CSTDLIB_SLL328
CODE 0080E8H 000019H INSECTION0 ?PR?MAIN?MAIN
CODE 008101H 000015H INSECTION0 CSTDLIB_ADD3232
CODE 008116H 00000DH INSECTION0 CSTART
CODE 008123H 0002B3H INSECTION ?PR??INIT_GPIO?GPIO_FUNCTIONS
CODE 0083D6H 000025H INSECTION ?PR??TIM1_ITCONFIG?STM8S_TIM1
CODE 0083FBH 000001H INSECTION ?PR??IRQ_00HANDLER_TLI?STM8S_INTVECTOR_TABLE

Please do let me know your opinion as what the issue might be.
Thank you.
Pradeep
+1
0
-1
September 27, 2012 - 4:45pm
Raisonance Support Team

Pradeep,

What is your debugger? STM8 simulator or RLink STM8? Did you try on both?

According to your report the trouble comes from the 1st bytes of ?PR??INIT_GPIO?GPIO_FUNCTIONS
Did you check that code at that point doesn't change?

Stéphane
+1
0
-1
September 28, 2012 - 4:27pm
Guest

Hi Stéphane,

I have ST Link. I do not have the RLink STM8.

Anyway, I think I found the issue and solution.
From page 70 of the compiler manual, I noted that for STM8 with 8KB, leaving 32 bytes for CRC checksum signature, I could use CRCRANGE(0x8000,0x9FE0) as linker directive.
I simply followed this example, as it suits my needs.

Now because of the crc check failures that I encountered, I changed this to CRCRANGE(0x8000,0x9FDF). Note the 0x9FDF as end address and not 0x9FE0.

Since the time I made this change, crc check is always passing.

Seems this is a "<=" or "<" comparison thing in the crc-checking function.

Please let me know if you have any comments.
For now I would say this is solved. In case I find something else, I will let you know.

Thank you,
Pradeep
+1
0
-1
October 1, 2012 - 3:22pm
Raisonance Support Team

Hi Pradeep,

I'm trying to find where the error comes from.

Did you use the CRCPLACE directive?

Did you get the issue only with ST Link or did you try with the simulator?

Stéphane
+1
0
-1
October 2, 2012 - 5:29pm
Guest

Hi Stéphane,

Thanks for the reply.
Here is what I have seen in my analysis.

| | | Result of CRC Check
|--------------+-----------------------------------------------+---------------------
| Using STLink | CRCRANGE(0x9000,0x9FE0) without CRCPLACE | Failed
| Using STLink | CRCRANGE(0x9000,0x9FDF) without CRCPLACE | Passed

| Using STLink | CRCRANGE(0x9000,0x9FE0) with CRCPLACE(0x9FE0) | Failed
| Using STLink | CRCRANGE(0x9000,0x9FDF) with CRCPLACE(0x9FE0) | Failed

| Using STLink | CRCRANGE(0x9000,0x9FD0) CRCPLACE(0x9FDF) | Passed
| Using STLink | CRCRANGE(0x9000,0x9FD0) CRCPLACE(0x9FE0) | Failed

Using Simulator (with both CRCRANGE(0x9000,0x9FE0) and CRCRANGE(0x9000,0x9FDF)):
The memory map setting, while using the simulator, have regions beyond 0x9fff and are set to RESERVED.
The debugger is failing while the crc function tries to read beyond 0x9fff.
I am seeing the following error on the debugger:
Error: stopped on read protection at 0xffff

The above results are seen only with the project I am working on.
i.e there is some functionality built.

Using a test project where main calls only the crc function:
In this case, the crc is always passing, using stlink or simulator.
In this case, using the simulator I did not see any error like the one I mentioned above,
and the crc check passed.

Best Regards,
Pradeep
+1
0
-1
October 3, 2012 - 5:22pm
Raisonance Support Team

Pradeep,

I can see why the address over 0x9fff are read.
Isn't _crc_seg_ the last segment on the memory map?
If your memory dump provided in a post above is right, the _check_crc16x_ only reads 10 bytes at 0x9fe0:
2 for length, 2 for address, 2 for CRC and 2 for length, 2 for address and stops because length == address == 0

Stéphane
+1
0
-1
October 8, 2012 - 11:30am
Guest

Hi Stéphane,

Sorry, but I did not understand what you explained.
I just have one crc check to perfom.
I can see 6 bytes between 0x9FE0 & 0x9E5 (2 for length, 2 for address and 2 for crc)
I think the _check_crc16x_ should stop after reading these 6 bytes when it encounters the length to be zero at the 7th byte position.

Below are some more details on two failing cases and two passing cases.

Thank you,
Pradeep

CRC Check Failing:
REMOVEUNCALLED PRESERVE(?PR??APP_MAIN?APP_MAIN) FILLGAP(0xCC) CRCRANGE(0x9000,0x9FE0)

009FC0  CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC   ................
009FD0  CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC   ................
009FE0  0F E0 90 00 49 5C 00 00 00 00 00 00 00 00 00 00   ....I\..........
009FF0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

             00908AH      000F56H                     *** GAP ***
    CODE     009FE0H      000012H    AT              _crc_seg_


CRC Check Failing:
REMOVEUNCALLED PRESERVE(?PR??APP_MAIN?APP_MAIN) FILLGAP(0xCC) CRCRANGE(0x9000,0x9FDF) CRCPLACE(0x9FE0)

009FC0  CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC   ................
009FD0  CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC   ................
009FE0  0F DF 90 00 56 4A 00 00 00 00 00 00 00 00 00 00   ....VJ..........
009FF0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

             00908AH      000F56H                     *** GAP ***
    CODE     009FE0H      000012H    AT              _crc_seg_


CRC Check Passing:
REMOVEUNCALLED PRESERVE(?PR??APP_MAIN?APP_MAIN) FILLGAP(0xCC) CRCRANGE(0x9000,0x9FDF)

009FC0  CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC   ................
009FD0  CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC 0F   ................
009FE0  DF 90 00 56 4A 5C 00 00 00 00 00 00 00 00 00 00   ...VJ\..........
009FF0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

             00908AH      000F55H                     *** GAP ***
    CODE     009FDFH      000012H    AT              _crc_seg_


CRC Check Passing:
REMOVEUNCALLED PRESERVE(?PR??APP_MAIN?APP_MAIN) FILLGAP(0xCC) CRCRANGE(0x9000,0x9FD0) CRCPLACE(0x9FDF)

009FC0  CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC   ................
009FD0  CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC 0F   ................
009FE0  D0 90 00 8A 88 4A 00 00 00 00 00 00 00 00 00 00   .....J..........
009FF0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

             00908AH      000F55H                     *** GAP ***
    CODE     009FDFH      000012H    AT              _crc_seg_
+1
0
-1
October 16, 2012 - 11:03am
Raisonance Support Team

Hi Pradeep,

I'm still trying to understand why you CRC doesn't always work properly.
Do you have the ?PR?STATINIT segment (see in the map file)? And is it followed by a gap?

Regards,

Stéphane
+1
0
-1
October 19, 2012 - 9:38am
Guest

Hi Stéphane,

I did not find the ?PR?STATINIT segment in the map file.
I have sent you an email with more details and test code.

Thank you,
Pradeep
+1
0
-1
October 19, 2012 - 11:56am
Raisonance Support Team

Hello Pradeep,

As explained in "2.3 Run-time routines and choice of algorithm" of the "AN59-ClassB requirements.pdf" available
in the documentation part of the Raisonance Download Center for RKit-STM8 the crc check routines return :
1 in case of success
0 in case of failure.

In your project, you do the opposite:

if(_check_crc16x_() == 0)
{
    // Your application!
}

Regards,

Stéphane
+1
0
-1
October 19, 2012 - 1:31pm
Guest

Hi Stéphane,

If I have always a failing crc check, your correction is true.
But I see a failing crc check and also a passing crc check for the same code, depending on how I run the project.
If you see the content of my email, I explained the two different behaviours.

Seems in the test code I have sent you, I have made a typo.
Nevertheless, can you please reconsider the content of my email. (pls dont mind the if(==0) thing)

Thank you,
Pradeep
+1
0
-1
October 19, 2012 - 2:04pm
Guest

Is it possible that CRC check works consistently only in release mode.
And may fail in the debug mode?

May be this is the case. If so, it will be nice to know why..!

Thanks,
Pradeep
+1
0
-1
October 19, 2012 - 2:52pm
Raisonance Support Team

Pradeep,

If the CRC fails when you set a breakpoint (or more) or when you're using the debug step feature (that uses a ... breakpoint), it is normal, because the debugger changes the flash to set the breakpoint(s).
To set a breakpoint, the debugger swaps the 1st byte of the flagged instruction with the BREAK instruction opcode (0x8B).

If you want to debug your application, you have to temporally disable the CRC check.

Regards,

Stéphane
+1
0
-1
October 19, 2012 - 3:09pm
Guest

Dear Stéphane,

Thanks a lot for explaining and for staying with me.

I just did not have enough knowledge about this and so did not doubt the debug/release modes....

Seems all the in-differences that I stated above are either because I was running the code in release (1 step) or with break points!!

Thanks again,
Pradeep