how to read read the data from the data from Flash memory

so what IS checksum? In the (pseudo)code you posted, it is undefined. Where does it come from?

And if it is stored in program memory, the checksum is part of the checksum, so subtracting it from the checksum gives the checksum without the checksum, but not zero (sounds insane? cyclic dependencies are!)

Also, the code does a checksum over all flash area from const_unStartPgmMem to 0xFFFF. This includes not only the program code, but also the init values for the variables. Including checksum itself?

Some compiler/linker has the option to generate checksum as part of the object image. For example IAR can do so and put the checksum at the very beginning of Main Flash (for example 0x2C00, depend on the chip you use).

In your code, you could declare something like:

__no_init volatile unsigned int i_choose_to_call_it_stored_checksum @ 0x2C00

Iam using the IDE code composer studio version5.2

and controller is MSP430F1611IPM

unsigned int unChecksum = 0x4625;  unsigned int sum = 0;  

unsigned int *pFlash = (unsigned int *)const_unStartPgmMem; 

//Start of program memory    //Flash extends to end of address space, loop until rollover  

while ((unsigned int)pFlash >= const_unStartPgmMem)  

 sum += *pFlash++;  

sum=unChecksum -sum;   

return (sum == 0);

 we are using unChecksum ,,the value we are giving unChecksum is dependent one,its precalculted value

we are fetching the value in the dataflash and adding those values,that will be the sum

the sum value should be equal to the  precalculted unChecksum  then only we can tell the data are stored in dataflash is proper

here how can i give the value for  unChecksum  ,,everytime the sum calculted is diiffers hope you understand the problem

do u have any source code for checking the data in the flash

 

 

 

 

 

 

sini sebastian said:

unsigned int unChecksum = 0x4625; 

This will put the init value of unChecksum into flash as well (where it is copied form to ram at program start). So when calculating the checksum later, it is calculated including this value.
See, you are compiling the program and then calculate the checksum. Then you change the program to contain the just calculated checksum. Which will in turn change the checksum of the program. So you're chasing your own tail.

You must store the checksum at a location where it isn't included into building the checksum later. The info memory is a good place for this (actually, it does exist for this kind of data storage)

You must store the checksum at a location where it isn't included into building the checksum later. The info memory is a good place for this (actually, it does exist for this kind of data storage)

How we can store the checksum value(which wont include in the building( you have mentioned that  information memory)

Each MSP has additional flash memory besides the main code memory flash. Depending on MSP, it is 256 to 1024 bytes in four segments (INFOA to INFOD). The datasheet tells where it is located in your MSP.

The method of putting the value there depends on your compiler. Usually a compiler pragma, or a change in the linker script. See the documentation for details. (I only know how to do it on MSPGCC)

I have calculated the checksum and stored the checksum in information memory in the debugg mode

probelm in the release mode: we cant calculate the checksum value bcoz its is is no source code available so it fails in release mode

IS there any way to see the code in release mode or can we step into code in release mode

Basically, debug mode and release mode are rather 'mode 1' and 'mode 2', which hold two independent sets of project parameters.
The main (default) differences are
- in debug mode, a token '__DEBUG' is defined, so you can do some conditional compiling, e.g. include debug code that is not included in release mode
- maybe the optimization settings are different, to make debug code less twisted (and less efficient) but better debuggabele-
- in release mode, no debug info is included into the output file.

In release mode, you should be able to change the setting, so that debug output is created as well.

Alternatively, you can configure the linker in release mode to create an additional output file in Ti TXT format. This text file contains all the binary data required for programming an MSP. YOu can then run this through a program that interprets the data (quite simple and straight), calculates the checksum, and adds it at the proper location. then the file can be used to program the MSP (or many) using a GANG programmer, or a FET with the Elprotronic tool. Or BSL-Scripter.

sini sebastian said:

IS there any way to see the code in release mode or can we step into code in release mode

See above for generating debug information. You can always step through the program. But the relation between the binary executable and the source code is lost, so all you see is a disassembly information at the current program counter. No source code, maybe even no variable and function names. You're just seeing what the processor sees.

You shouldn't need the source code to calculate the checksum. You should be having the toolchain do it automatically for you during link phase.

Additionally, in your linker script, define the range to calculate a checksum over, and tell it to place the checksum in the INFO segment. In your code, you retrieve the checksum from INFO location and compare to the  checksum you calculate on-the-fly.

This way the checksum is included in the image that gets programmed into your part, but is not located in the range you are summing during your check.

Brian Boorman said:

You should be having the toolchain do it automatically for you during link phase.

Well, the question is: how to do it. I would know how to do it externally, calculating a checksum over a generated TITXT file and adding the checksum (and maybe the start and end address) to the file so that the data is programmed into info memory. A small C program could do this.

But how to make the linker do it - it sounds like a special feature that isn't normally available through linker parameters or linker script. So if it is on a particular linker, it is not portable.

Jens-Michael Gross said:

But how to make the linker do it - it sounds like a special feature that isn't normally available through linker parameters or linker script. So if it is on a particular linker, it is not portable.

In the IAR toolchain you add something like this to your .xcl linker command file:

// ---------------------------------------------------------
// Program CRC calculation
// ---------------------------------------------------------
// **  NOTE  **
// The assumption here is that the first-declared CRC is allocated in the lowest
// available CHECKSUM segment address.
-Z(CONST)CHECKSUM=E7FC-E7FF
-J2,crc16,=5c00-E7FB
-J2,crc16,=10000-1ffff

Checksumming and checking your code is fairly common in the embedded world. If your linker doesn't have a similar feature, then how good of a tool for embedded design can it really be? Just my 2-cents.

Brian Boorman said:

If your linker doesn't have a similar feature, then how good of a tool for embedded design can it really be?

It's still a linker. The job of a linker is to link object data, not to perform fancy operations on the generated binary.
It' snice to have this feature, but won't help if the required checksum needs to be calculated using a different algorithm,as there is no universal 'THE checksum' method. Which raises the same question: what good is it for if it doesn't support the checksum type I need?

It sure is convenient if you can make use of it, but neither a 'must have' nor is it sufficient to cover all needs.

Usually, generating checksums or adding serials or such things are done further down the toolchain.

Jens-Michael Gross said:

It' snice to have this feature, but won't help if the required checksum needs to be calculated using a different algorithm,as there is no universal 'THE checksum' method.

Since I know you don't use IAR, I will tell you that it supports standard arithmetic checksums as well as CRC-16 or CRC-32 with any polynomial, bit ordering, or initial value you want. That is about as flexible as you can get.

I still stand by my statement that tools meant for embedded should include these types of features. I buy a tool to make my life easier, not so that I have to develop more tools of my own to get the job done. If CCS doesn't support this, then developers should *** to TI until it does. My 2-cents.

Brian Boorman said:

Since I know you don't use IAR, I will tell you that it supports standard arithmetic checksums as well as CRC-16 or CRC-32 with any polynomial, bit ordering, or initial value you want. That is about as flexible as you can get.

Impressive.

Brian Boorman said:

I still stand by my statement that tools meant for embedded should include these types of features.

I don't disagree. I just don't think the linker is the right place to put this type of features in. Nobody prevents you from running any tool on the generated output to perform this (or any other thinkable manipulation) on the linker output.