Our MCU is MSP430F169. FAE reported that one of our products doesn't
work. I have checked it and found it's running strangely. I uploaded
its code data and info flash data via JTAG port and programmer. I
found some of the data has been changed:
The original data is 01 D2 C0 12 80 13 41 D3 00 11 C1 D1 81 D0 40 10
but it's changed to 01 40 40 02 00 00 00 00 00 00 00 01 81 D0 40 10
Some data's bits have been changed from 1 to 0.
Both info flash and code flash have this problem.
I want to know the reason that might cause this problem, since the
other boards haven't met such problem. There is a voltage supervisor
(MAX706) on board, which can reset the mcu if voltage is lower that
2.9V. So there is no possibility that flash was erased nor written
under 2.7V.
Besides, at info flash, some parameters are store. At code flash,
it's composed of bootloader and firmware. Both have flash program
function.
Can anybody give some suggestions? Thanks.
SOS: Data corruption of MSP 430 Flash
Started by ●March 16, 2008
Reply by ●March 16, 20082008-03-16
----- Original Message -----
From: "maple_1982"
To:
Sent: Sunday, March 16, 2008 12:31 PM
Subject: [msp430] SOS: Data corruption of MSP 430 Flash
> Our MCU is MSP430F169. FAE reported that one of our products doesn't
> work. I have checked it and found it's running strangely. I uploaded
> its code data and info flash data via JTAG port and programmer. I
> found some of the data has been changed:
> The original data is 01 D2 C0 12 80 13 41 D3 00 11 C1 D1 81 D0 40 10
> but it's changed to 01 40 40 02 00 00 00 00 00 00 00 01 81 D0 40 10
>
> Some data's bits have been changed from 1 to 0.
> Both info flash and code flash have this problem.
>
> I want to know the reason that might cause this problem, since the
> other boards haven't met such problem. There is a voltage supervisor
> (MAX706) on board, which can reset the mcu if voltage is lower that
> 2.9V. So there is no possibility that flash was erased nor written
> under 2.7V.
>
> Besides, at info flash, some parameters are store. At code flash,
> it's composed of bootloader and firmware. Both have flash program
> function.
>
> Can anybody give some suggestions? Thanks.
When I worked on military comms systems, built-in test functions were used
to check code integrity when a system was first switched on. That might be a
good idea in your case, even if you find the cause of the problem.
Leon
From: "maple_1982"
To:
Sent: Sunday, March 16, 2008 12:31 PM
Subject: [msp430] SOS: Data corruption of MSP 430 Flash
> Our MCU is MSP430F169. FAE reported that one of our products doesn't
> work. I have checked it and found it's running strangely. I uploaded
> its code data and info flash data via JTAG port and programmer. I
> found some of the data has been changed:
> The original data is 01 D2 C0 12 80 13 41 D3 00 11 C1 D1 81 D0 40 10
> but it's changed to 01 40 40 02 00 00 00 00 00 00 00 01 81 D0 40 10
>
> Some data's bits have been changed from 1 to 0.
> Both info flash and code flash have this problem.
>
> I want to know the reason that might cause this problem, since the
> other boards haven't met such problem. There is a voltage supervisor
> (MAX706) on board, which can reset the mcu if voltage is lower that
> 2.9V. So there is no possibility that flash was erased nor written
> under 2.7V.
>
> Besides, at info flash, some parameters are store. At code flash,
> it's composed of bootloader and firmware. Both have flash program
> function.
>
> Can anybody give some suggestions? Thanks.
When I worked on military comms systems, built-in test functions were used
to check code integrity when a system was first switched on. That might be a
good idea in your case, even if you find the cause of the problem.
Leon
Reply by ●March 16, 20082008-03-16
Does your code do any flash writing of its own? It's virtually
impossible to accidentally write to flash on this processor.
If you do have flash-writing capabilities, you probably have a bug
causing the wrong address to be written. It may be hard to correlate
the data you're reading with the corrupted data in flash because you
can only "write" 1's to 0's and not 0's to 1's (without erasing the
segment).
We have done very strenuous "highly accelerated life testing" and
other stress-tests on the flash and have never found corrupted flash.
As the previous tester suggested, redundancy or other error-detection
information is a good tool (CRC, etc.), but it sounds like your
product may already be deployed.
Some other hints:
Don't keep code in the same segments as areas that you write to.
Then, customize your flash-writing routines to double-check the erase
range for valid addresses.
Encode all data with CRC, checksum, or some kind or error check.
Stuart
--- In m..., "maple_1982" wrote:
>
> Our MCU is MSP430F169. FAE reported that one of our products doesn't
> work. I have checked it and found it's running strangely. I uploaded
> its code data and info flash data via JTAG port and programmer. I
> found some of the data has been changed:
> The original data is 01 D2 C0 12 80 13 41 D3 00 11 C1 D1 81 D0 40 10
> but it's changed to 01 40 40 02 00 00 00 00 00 00 00 01 81 D0 40 10
>
> Some data's bits have been changed from 1 to 0.
> Both info flash and code flash have this problem.
>
> I want to know the reason that might cause this problem, since the
> other boards haven't met such problem. There is a voltage supervisor
> (MAX706) on board, which can reset the mcu if voltage is lower that
> 2.9V. So there is no possibility that flash was erased nor written
> under 2.7V.
>
> Besides, at info flash, some parameters are store. At code flash,
> it's composed of bootloader and firmware. Both have flash program
> function.
>
> Can anybody give some suggestions? Thanks.
>
impossible to accidentally write to flash on this processor.
If you do have flash-writing capabilities, you probably have a bug
causing the wrong address to be written. It may be hard to correlate
the data you're reading with the corrupted data in flash because you
can only "write" 1's to 0's and not 0's to 1's (without erasing the
segment).
We have done very strenuous "highly accelerated life testing" and
other stress-tests on the flash and have never found corrupted flash.
As the previous tester suggested, redundancy or other error-detection
information is a good tool (CRC, etc.), but it sounds like your
product may already be deployed.
Some other hints:
Don't keep code in the same segments as areas that you write to.
Then, customize your flash-writing routines to double-check the erase
range for valid addresses.
Encode all data with CRC, checksum, or some kind or error check.
Stuart
--- In m..., "maple_1982" wrote:
>
> Our MCU is MSP430F169. FAE reported that one of our products doesn't
> work. I have checked it and found it's running strangely. I uploaded
> its code data and info flash data via JTAG port and programmer. I
> found some of the data has been changed:
> The original data is 01 D2 C0 12 80 13 41 D3 00 11 C1 D1 81 D0 40 10
> but it's changed to 01 40 40 02 00 00 00 00 00 00 00 01 81 D0 40 10
>
> Some data's bits have been changed from 1 to 0.
> Both info flash and code flash have this problem.
>
> I want to know the reason that might cause this problem, since the
> other boards haven't met such problem. There is a voltage supervisor
> (MAX706) on board, which can reset the mcu if voltage is lower that
> 2.9V. So there is no possibility that flash was erased nor written
> under 2.7V.
>
> Besides, at info flash, some parameters are store. At code flash,
> it's composed of bootloader and firmware. Both have flash program
> function.
>
> Can anybody give some suggestions? Thanks.
>
Reply by ●March 16, 20082008-03-16
In our system, there is a preamble for the firmware, which has the
firmware's CRC information. Before bootloader boots firmware, it
would calculate firmware's CRC and check this with the value stored
in preamble. This can ensure the code integrity, I think.
Now the problem is both bootloader and firmware has been corrupted.
Bootloader is running abnormally.
--- In m..., "Leon" wrote:
>
> ----- Original Message -----
> From: "maple_1982"
> To:
> Sent: Sunday, March 16, 2008 12:31 PM
> Subject: [msp430] SOS: Data corruption of MSP 430 Flash
> > Our MCU is MSP430F169. FAE reported that one of our products
doesn't
> > work. I have checked it and found it's running strangely. I
uploaded
> > its code data and info flash data via JTAG port and programmer. I
> > found some of the data has been changed:
> > The original data is 01 D2 C0 12 80 13 41 D3 00 11 C1 D1 81 D0 40
10
> > but it's changed to 01 40 40 02 00 00 00 00 00 00 00 01 81 D0 40
10
> >
> > Some data's bits have been changed from 1 to 0.
> > Both info flash and code flash have this problem.
> >
> > I want to know the reason that might cause this problem, since the
> > other boards haven't met such problem. There is a voltage
supervisor
> > (MAX706) on board, which can reset the mcu if voltage is lower
that
> > 2.9V. So there is no possibility that flash was erased nor written
> > under 2.7V.
> >
> > Besides, at info flash, some parameters are store. At code flash,
> > it's composed of bootloader and firmware. Both have flash program
> > function.
> >
> > Can anybody give some suggestions? Thanks.
>
> When I worked on military comms systems, built-in test functions
were used
> to check code integrity when a system was first switched on. That
might be a
> good idea in your case, even if you find the cause of the problem.
>
> Leon
>
firmware's CRC information. Before bootloader boots firmware, it
would calculate firmware's CRC and check this with the value stored
in preamble. This can ensure the code integrity, I think.
Now the problem is both bootloader and firmware has been corrupted.
Bootloader is running abnormally.
--- In m..., "Leon" wrote:
>
> ----- Original Message -----
> From: "maple_1982"
> To:
> Sent: Sunday, March 16, 2008 12:31 PM
> Subject: [msp430] SOS: Data corruption of MSP 430 Flash
> > Our MCU is MSP430F169. FAE reported that one of our products
doesn't
> > work. I have checked it and found it's running strangely. I
uploaded
> > its code data and info flash data via JTAG port and programmer. I
> > found some of the data has been changed:
> > The original data is 01 D2 C0 12 80 13 41 D3 00 11 C1 D1 81 D0 40
10
> > but it's changed to 01 40 40 02 00 00 00 00 00 00 00 01 81 D0 40
10
> >
> > Some data's bits have been changed from 1 to 0.
> > Both info flash and code flash have this problem.
> >
> > I want to know the reason that might cause this problem, since the
> > other boards haven't met such problem. There is a voltage
supervisor
> > (MAX706) on board, which can reset the mcu if voltage is lower
that
> > 2.9V. So there is no possibility that flash was erased nor written
> > under 2.7V.
> >
> > Besides, at info flash, some parameters are store. At code flash,
> > it's composed of bootloader and firmware. Both have flash program
> > function.
> >
> > Can anybody give some suggestions? Thanks.
>
> When I worked on military comms systems, built-in test functions
were used
> to check code integrity when a system was first switched on. That
might be a
> good idea in your case, even if you find the cause of the problem.
>
> Leon
>
Reply by ●March 17, 20082008-03-17
Hi, Stuart
Thanks very much for your reply.
Now the flash allocation is like this:
0x1000-0x1100 Info Flash for parameters
0x2500-0x4000 Bootloader
0x4000-0xFFFF Firmware
While firmware is running, if we want to upgrade the firmware, we
would send a command to set a update flag stored in info flash, and
then reset the board. It would enter bootloader and check this flag,
if it has been set to UPDATE mode, it would begin the update process
and receive data via data , and then program it to flash.
So the code won't write itself.
I'll look for the possibility that flash program function writes data
to a wrong address, which might cause the data corruption.
Besides, now the corruption appears in both info flash and code flash
(both bootloader and firmware).
--- In m..., "Stuart_Rubin"
wrote:
>
> Does your code do any flash writing of its own? It's virtually
> impossible to accidentally write to flash on this processor.
>
> If you do have flash-writing capabilities, you probably have a bug
> causing the wrong address to be written. It may be hard to
correlate
> the data you're reading with the corrupted data in flash because you
> can only "write" 1's to 0's and not 0's to 1's (without erasing the
> segment).
>
> We have done very strenuous "highly accelerated life testing" and
> other stress-tests on the flash and have never found corrupted
flash.
>
> As the previous tester suggested, redundancy or other error-
detection
> information is a good tool (CRC, etc.), but it sounds like your
> product may already be deployed.
>
> Some other hints:
> Don't keep code in the same segments as areas that you write to.
> Then, customize your flash-writing routines to double-check the
erase
> range for valid addresses.
> Encode all data with CRC, checksum, or some kind or error check.
>
> Stuart
>
=======================================================================Groups related to msp430
=======================================================================
e-embedded (265 common members)
http://groups.yahoo.com/group/e-embedded?v=1&t=ipt&ch=email&pub=groups&slktr0&sec=recg
Internet/Internet Appliances: Open-membership mailing list for embedded system d...
LTspice (203 common members)
http://groups.yahoo.com/group/LTspice?v=1&t=ipt&ch=email&pub=groups&slktr1&sec=recg
Engineering/Electrical: Dedicated to the exchange of information about LTs...
AVR-Chat (161 common members)
http://groups.yahoo.com/group/AVR-Chat?v=1&t=ipt&ch=email&pub=groups&slktr2&sec=recg
Microprocessors/Microcontrollers: A place for Atmel AVR Microcontroller users to sha...
piclist (141 common members)
http://groups.yahoo.com/group/piclist?v=1&t=ipt&ch=email&pub=groups&slktr3&sec=recg
Microprocessors/Microcontrollers: A discussion group for the PICMicro microcontrolle...
rabbit-semi (138 common members)
http://groups.yahoo.com/group/rabbit-semi?v=1&t=ipt&ch=email&pub=groups&slktr4&sec=recg
Microprocessors/Microcontrollers: This is a user group for folks designing and progr...
Thanks very much for your reply.
Now the flash allocation is like this:
0x1000-0x1100 Info Flash for parameters
0x2500-0x4000 Bootloader
0x4000-0xFFFF Firmware
While firmware is running, if we want to upgrade the firmware, we
would send a command to set a update flag stored in info flash, and
then reset the board. It would enter bootloader and check this flag,
if it has been set to UPDATE mode, it would begin the update process
and receive data via data , and then program it to flash.
So the code won't write itself.
I'll look for the possibility that flash program function writes data
to a wrong address, which might cause the data corruption.
Besides, now the corruption appears in both info flash and code flash
(both bootloader and firmware).
--- In m..., "Stuart_Rubin"
wrote:
>
> Does your code do any flash writing of its own? It's virtually
> impossible to accidentally write to flash on this processor.
>
> If you do have flash-writing capabilities, you probably have a bug
> causing the wrong address to be written. It may be hard to
correlate
> the data you're reading with the corrupted data in flash because you
> can only "write" 1's to 0's and not 0's to 1's (without erasing the
> segment).
>
> We have done very strenuous "highly accelerated life testing" and
> other stress-tests on the flash and have never found corrupted
flash.
>
> As the previous tester suggested, redundancy or other error-
detection
> information is a good tool (CRC, etc.), but it sounds like your
> product may already be deployed.
>
> Some other hints:
> Don't keep code in the same segments as areas that you write to.
> Then, customize your flash-writing routines to double-check the
erase
> range for valid addresses.
> Encode all data with CRC, checksum, or some kind or error check.
>
> Stuart
>
=======================================================================Groups related to msp430
=======================================================================
e-embedded (265 common members)
http://groups.yahoo.com/group/e-embedded?v=1&t=ipt&ch=email&pub=groups&slktr0&sec=recg
Internet/Internet Appliances: Open-membership mailing list for embedded system d...
LTspice (203 common members)
http://groups.yahoo.com/group/LTspice?v=1&t=ipt&ch=email&pub=groups&slktr1&sec=recg
Engineering/Electrical: Dedicated to the exchange of information about LTs...
AVR-Chat (161 common members)
http://groups.yahoo.com/group/AVR-Chat?v=1&t=ipt&ch=email&pub=groups&slktr2&sec=recg
Microprocessors/Microcontrollers: A place for Atmel AVR Microcontroller users to sha...
piclist (141 common members)
http://groups.yahoo.com/group/piclist?v=1&t=ipt&ch=email&pub=groups&slktr3&sec=recg
Microprocessors/Microcontrollers: A discussion group for the PICMicro microcontrolle...
rabbit-semi (138 common members)
http://groups.yahoo.com/group/rabbit-semi?v=1&t=ipt&ch=email&pub=groups&slktr4&sec=recg
Microprocessors/Microcontrollers: This is a user group for folks designing and progr...
Reply by ●March 17, 20082008-03-17
It sounds like your bootloader scheme with the flag is reasonable. Do
you have built-in protections against overwriting the bootloader?
Another issue may be your clock speed. The Users Guide is very
prescriptive about the flash write clock (usually a derivative of
MCLK) as well as VCC, as the previous responder mentioned. Being
marginally beyond the limits may explain why you have problems with
one device, but not all of them.
Stuart
--- In m..., "maple_1982" wrote:
>
> Hi, Stuart
>
> Thanks very much for your reply.
> Now the flash allocation is like this:
>
> 0x1000-0x1100 Info Flash for parameters
> 0x2500-0x4000 Bootloader
> 0x4000-0xFFFF Firmware
>
> While firmware is running, if we want to upgrade the firmware, we
> would send a command to set a update flag stored in info flash, and
> then reset the board. It would enter bootloader and check this flag,
> if it has been set to UPDATE mode, it would begin the update process
> and receive data via data , and then program it to flash.
> So the code won't write itself.
>
> I'll look for the possibility that flash program function writes data
> to a wrong address, which might cause the data corruption.
>
> Besides, now the corruption appears in both info flash and code flash
> (both bootloader and firmware).
>
> --- In m..., "Stuart_Rubin"
> wrote:
> >
> > Does your code do any flash writing of its own? It's virtually
> > impossible to accidentally write to flash on this processor.
> >
> > If you do have flash-writing capabilities, you probably have a bug
> > causing the wrong address to be written. It may be hard to
> correlate
> > the data you're reading with the corrupted data in flash because you
> > can only "write" 1's to 0's and not 0's to 1's (without erasing the
> > segment).
> >
> > We have done very strenuous "highly accelerated life testing" and
> > other stress-tests on the flash and have never found corrupted
> flash.
> >
> > As the previous tester suggested, redundancy or other error-
> detection
> > information is a good tool (CRC, etc.), but it sounds like your
> > product may already be deployed.
> >
> > Some other hints:
> > Don't keep code in the same segments as areas that you write to.
> > Then, customize your flash-writing routines to double-check the
> erase
> > range for valid addresses.
> > Encode all data with CRC, checksum, or some kind or error check.
> >
> > Stuart
>
you have built-in protections against overwriting the bootloader?
Another issue may be your clock speed. The Users Guide is very
prescriptive about the flash write clock (usually a derivative of
MCLK) as well as VCC, as the previous responder mentioned. Being
marginally beyond the limits may explain why you have problems with
one device, but not all of them.
Stuart
--- In m..., "maple_1982" wrote:
>
> Hi, Stuart
>
> Thanks very much for your reply.
> Now the flash allocation is like this:
>
> 0x1000-0x1100 Info Flash for parameters
> 0x2500-0x4000 Bootloader
> 0x4000-0xFFFF Firmware
>
> While firmware is running, if we want to upgrade the firmware, we
> would send a command to set a update flag stored in info flash, and
> then reset the board. It would enter bootloader and check this flag,
> if it has been set to UPDATE mode, it would begin the update process
> and receive data via data , and then program it to flash.
> So the code won't write itself.
>
> I'll look for the possibility that flash program function writes data
> to a wrong address, which might cause the data corruption.
>
> Besides, now the corruption appears in both info flash and code flash
> (both bootloader and firmware).
>
> --- In m..., "Stuart_Rubin"
> wrote:
> >
> > Does your code do any flash writing of its own? It's virtually
> > impossible to accidentally write to flash on this processor.
> >
> > If you do have flash-writing capabilities, you probably have a bug
> > causing the wrong address to be written. It may be hard to
> correlate
> > the data you're reading with the corrupted data in flash because you
> > can only "write" 1's to 0's and not 0's to 1's (without erasing the
> > segment).
> >
> > We have done very strenuous "highly accelerated life testing" and
> > other stress-tests on the flash and have never found corrupted
> flash.
> >
> > As the previous tester suggested, redundancy or other error-
> detection
> > information is a good tool (CRC, etc.), but it sounds like your
> > product may already be deployed.
> >
> > Some other hints:
> > Don't keep code in the same segments as areas that you write to.
> > Then, customize your flash-writing routines to double-check the
> erase
> > range for valid addresses.
> > Encode all data with CRC, checksum, or some kind or error check.
> >
> > Stuart
>
Reply by ●March 17, 20082008-03-17
maple_1982 wrote on 16/03/08 12:31 MET:
>
> Can anybody give some suggestions? Thanks.
Maybe gives you some
hints.
--
MfG / Regards
Friedrich Lobenstock
>
> Can anybody give some suggestions? Thanks.
Maybe gives you some
hints.
--
MfG / Regards
Friedrich Lobenstock
Reply by ●March 17, 20082008-03-17
The recommended decoupling for the supply pins used to be stated as a
10UF in parallel with a 100nF. that is still the case for the 24x
series, but it is not included in the data sheet for the 21x1 parts. I
have been running data logging to a 4k block of flash in temperatures
varying from about 5C to 70C with 1 word write per second since mid
january on 2 test devices and have yet to detect a verify error. (my
code goes)
set loop count
write flash
read flash
if OK then skip
count--
if count!0 loop
exit
It has yet to have to retry. it loops back on the 4k buffer 42+ times
per day, so has done around 2500 erase/write cycles approx or around
5,000,000 writes. Voltage varies between 2.7 and 3.1V. I too have
cheated and used only a 100nF cap to decouple the supply, which is a
CR2477 battery.
For me this sounds much more like a code bug that periodically finds its
way to the flash write routines with unknown data in the 'write buffer'.
I don't recall if the OP said this was intermittent or constant. If
constant simply add a RAM counter to the flash write access code and
trace that against the number of expected accesses. Also double check
that all data and addresses to be written are within bounds. If the
flash procedure is called from only 1 place then have a RAM value that
is set prior to calling the routine and cleared afterwards. his will
have the flash access password in it. In this way no illicit call can
reslt in a write, it will (if enabled) trigger a flash access violation,
which is trackable through the NMI vector. It's just too easy to have
the access settings in the local write procedure, but the dowside is
that a false call to the routne cannot be detected.
Cheers
Al
Dan Muzzey wrote:
>Long story short....
>
>We have had trouble using the MSP430 program space to store data. Some
>testing revealed that there would be an occasional bad flash write or
>bad erase. Not very often but it could happen. In order to combat this
>we have increased the bypass capacitance on Vcc so that we now use a
>couple .01uF and a 1uF directly on the VCC pins. Additionally we added
>a CRC to the data and a verify routine to make sure that we actually
>wrote what we intended to write.
>
>Several different people have reviewed the code without finding any
>errors that could cause the problem. The hardware has been reviewed
>several times without any clues.
>
>Dan
>
>________________________________
>
>From: m... [mailto:m...] On Behalf
>Of Stuart_Rubin
>Sent: Monday, March 17, 2008 11:28 AM
>To: m...
>Subject: [msp430] Re: SOS: Data corruption of MSP 430 Flash
>
>It sounds like your bootloader scheme with the flag is reasonable. Do
>you have built-in protections against overwriting the bootloader?
>
>Another issue may be your clock speed. The Users Guide is very
>prescriptive about the flash write clock (usually a derivative of
>MCLK) as well as VCC, as the previous responder mentioned. Being
>marginally beyond the limits may explain why you have problems with
>one device, but not all of them.
>
>Stuart
>
>--- In m... ,
>"maple_1982" wrote:
>
>
>>Hi, Stuart
>>
>>Thanks very much for your reply.
>>Now the flash allocation is like this:
>>
>>0x1000-0x1100 Info Flash for parameters
>>0x2500-0x4000 Bootloader
>>0x4000-0xFFFF Firmware
>>
>>While firmware is running, if we want to upgrade the firmware, we
>>would send a command to set a update flag stored in info flash, and
>>then reset the board. It would enter bootloader and check this flag,
>>if it has been set to UPDATE mode, it would begin the update process
>>and receive data via data , and then program it to flash.
>>So the code won't write itself.
>>
>>I'll look for the possibility that flash program function writes data
>>to a wrong address, which might cause the data corruption.
>>
>>Besides, now the corruption appears in both info flash and code flash
>>(both bootloader and firmware).
>>
>>--- In m... ,
>>
>>
>"Stuart_Rubin"
>
>
>>wrote:
>>
>>
>>>Does your code do any flash writing of its own? It's virtually
>>>impossible to accidentally write to flash on this processor.
>>>
>>>If you do have flash-writing capabilities, you probably have a bug
>>>causing the wrong address to be written. It may be hard to
>>>
>>>
>>correlate
>>
>>
>>>the data you're reading with the corrupted data in flash because you
>>>can only "write" 1's to 0's and not 0's to 1's (without erasing the
>>>segment).
>>>
>>>We have done very strenuous "highly accelerated life testing" and
>>>other stress-tests on the flash and have never found corrupted
>>>
>>>
>>flash.
>>
>>
>>>As the previous tester suggested, redundancy or other error-
>>>
>>>
>>detection
>>
>>
>>>information is a good tool (CRC, etc.), but it sounds like your
>>>product may already be deployed.
>>>
>>>Some other hints:
>>>Don't keep code in the same segments as areas that you write to.
>>>Then, customize your flash-writing routines to double-check the
>>>
>>>
>>erase
>>
>>
>>>range for valid addresses.
>>>Encode all data with CRC, checksum, or some kind or error check.
>>>
>>>Stuart
>>>
>>>
>>>
>
10UF in parallel with a 100nF. that is still the case for the 24x
series, but it is not included in the data sheet for the 21x1 parts. I
have been running data logging to a 4k block of flash in temperatures
varying from about 5C to 70C with 1 word write per second since mid
january on 2 test devices and have yet to detect a verify error. (my
code goes)
set loop count
write flash
read flash
if OK then skip
count--
if count!0 loop
exit
It has yet to have to retry. it loops back on the 4k buffer 42+ times
per day, so has done around 2500 erase/write cycles approx or around
5,000,000 writes. Voltage varies between 2.7 and 3.1V. I too have
cheated and used only a 100nF cap to decouple the supply, which is a
CR2477 battery.
For me this sounds much more like a code bug that periodically finds its
way to the flash write routines with unknown data in the 'write buffer'.
I don't recall if the OP said this was intermittent or constant. If
constant simply add a RAM counter to the flash write access code and
trace that against the number of expected accesses. Also double check
that all data and addresses to be written are within bounds. If the
flash procedure is called from only 1 place then have a RAM value that
is set prior to calling the routine and cleared afterwards. his will
have the flash access password in it. In this way no illicit call can
reslt in a write, it will (if enabled) trigger a flash access violation,
which is trackable through the NMI vector. It's just too easy to have
the access settings in the local write procedure, but the dowside is
that a false call to the routne cannot be detected.
Cheers
Al
Dan Muzzey wrote:
>Long story short....
>
>We have had trouble using the MSP430 program space to store data. Some
>testing revealed that there would be an occasional bad flash write or
>bad erase. Not very often but it could happen. In order to combat this
>we have increased the bypass capacitance on Vcc so that we now use a
>couple .01uF and a 1uF directly on the VCC pins. Additionally we added
>a CRC to the data and a verify routine to make sure that we actually
>wrote what we intended to write.
>
>Several different people have reviewed the code without finding any
>errors that could cause the problem. The hardware has been reviewed
>several times without any clues.
>
>Dan
>
>________________________________
>
>From: m... [mailto:m...] On Behalf
>Of Stuart_Rubin
>Sent: Monday, March 17, 2008 11:28 AM
>To: m...
>Subject: [msp430] Re: SOS: Data corruption of MSP 430 Flash
>
>It sounds like your bootloader scheme with the flag is reasonable. Do
>you have built-in protections against overwriting the bootloader?
>
>Another issue may be your clock speed. The Users Guide is very
>prescriptive about the flash write clock (usually a derivative of
>MCLK) as well as VCC, as the previous responder mentioned. Being
>marginally beyond the limits may explain why you have problems with
>one device, but not all of them.
>
>Stuart
>
>--- In m... ,
>"maple_1982" wrote:
>
>
>>Hi, Stuart
>>
>>Thanks very much for your reply.
>>Now the flash allocation is like this:
>>
>>0x1000-0x1100 Info Flash for parameters
>>0x2500-0x4000 Bootloader
>>0x4000-0xFFFF Firmware
>>
>>While firmware is running, if we want to upgrade the firmware, we
>>would send a command to set a update flag stored in info flash, and
>>then reset the board. It would enter bootloader and check this flag,
>>if it has been set to UPDATE mode, it would begin the update process
>>and receive data via data , and then program it to flash.
>>So the code won't write itself.
>>
>>I'll look for the possibility that flash program function writes data
>>to a wrong address, which might cause the data corruption.
>>
>>Besides, now the corruption appears in both info flash and code flash
>>(both bootloader and firmware).
>>
>>--- In m... ,
>>
>>
>"Stuart_Rubin"
>
>
>>wrote:
>>
>>
>>>Does your code do any flash writing of its own? It's virtually
>>>impossible to accidentally write to flash on this processor.
>>>
>>>If you do have flash-writing capabilities, you probably have a bug
>>>causing the wrong address to be written. It may be hard to
>>>
>>>
>>correlate
>>
>>
>>>the data you're reading with the corrupted data in flash because you
>>>can only "write" 1's to 0's and not 0's to 1's (without erasing the
>>>segment).
>>>
>>>We have done very strenuous "highly accelerated life testing" and
>>>other stress-tests on the flash and have never found corrupted
>>>
>>>
>>flash.
>>
>>
>>>As the previous tester suggested, redundancy or other error-
>>>
>>>
>>detection
>>
>>
>>>information is a good tool (CRC, etc.), but it sounds like your
>>>product may already be deployed.
>>>
>>>Some other hints:
>>>Don't keep code in the same segments as areas that you write to.
>>>Then, customize your flash-writing routines to double-check the
>>>
>>>
>>erase
>>
>>
>>>range for valid addresses.
>>>Encode all data with CRC, checksum, or some kind or error check.
>>>
>>>Stuart
>>>
>>>
>>>
>
Reply by ●March 17, 20082008-03-17
The OP was using a 169. I have no idea how close this is to the 2X
parts but I think it is safe to assume that they are not exactly the
same. Therefore, while it is good to know that a 2X part seems to work
well, I would not carry over that data to a 169. In the interest of
full disclosure, my test was done using a 449.
One of the most basic mistakes someone can make is to assume the code is
good. One of the first steps should always be to inspect the code. We
have found many lingering problems in other code this way. However, we
were not able to find any problems with the code in this case. If there
is one it is buried deep.
I did pretty much the same test as you did with 10 449's. The write
sequence was much faster but still within specs on the chip. If memory
serves me I had some units with about a 1 in 10,000 error rate and other
units that did not have any errors until well past the 300,000 mark.
The units were erased/written/checked until they could no longer be
written.
The test showed me several things which are probably good to implement
if possible. Checking a flash write does not take much time. Implement
it. Put some debugging code in there. The new code we are running will
attempt to leave bread crumbs behind. Depending on how the flash fails
(sometimes it was all erased, some times only a single byte was bad) it
may still be possible to get usefully info out of a bad unit.
Several other people on the list have posted about variations of this
problem. It could be a power supply issue but then that just means the
chip is extremely picky about the power supply. TI was very quick to
respond to our request and set up a call with Harman Grewal almost
immediately. This tells me that TI may be hearing about this problem
from other areas. Finally, TI thought it was worth implementing a
"marginal write" feature on the new chips. I can't help but wonder why
this was implemented. Do some of the other chips have some lingering
issues that this "marginal write" feature was aimed at fixing?
I'll be very leery of using any on board flash in the future.
Dan
________________________________
From: m... [mailto:m...] On Behalf
Of One Stone
Sent: Monday, March 17, 2008 12:10 PM
To: m...
Subject: Re: [msp430] Re: SOS: Data corruption of MSP 430 Flash
The recommended decoupling for the supply pins used to be stated as a
10UF in parallel with a 100nF. that is still the case for the 24x
series, but it is not included in the data sheet for the 21x1 parts. I
have been running data logging to a 4k block of flash in temperatures
varying from about 5C to 70C with 1 word write per second since mid
january on 2 test devices and have yet to detect a verify error. (my
code goes)
set loop count
write flash
read flash
if OK then skip
count--
if count!0 loop
exit
It has yet to have to retry. it loops back on the 4k buffer 42+ times
per day, so has done around 2500 erase/write cycles approx or around
5,000,000 writes. Voltage varies between 2.7 and 3.1V. I too have
cheated and used only a 100nF cap to decouple the supply, which is a
CR2477 battery.
For me this sounds much more like a code bug that periodically finds its
way to the flash write routines with unknown data in the 'write buffer'.
I don't recall if the OP said this was intermittent or constant. If
constant simply add a RAM counter to the flash write access code and
trace that against the number of expected accesses. Also double check
that all data and addresses to be written are within bounds. If the
flash procedure is called from only 1 place then have a RAM value that
is set prior to calling the routine and cleared afterwards. his will
have the flash access password in it. In this way no illicit call can
reslt in a write, it will (if enabled) trigger a flash access violation,
which is trackable through the NMI vector. It's just too easy to have
the access settings in the local write procedure, but the dowside is
that a false call to the routne cannot be detected.
Cheers
Al
Dan Muzzey wrote:
>Long story short....
>
>We have had trouble using the MSP430 program space to store data. Some
>testing revealed that there would be an occasional bad flash write or
>bad erase. Not very often but it could happen. In order to combat this
>we have increased the bypass capacitance on Vcc so that we now use a
>couple .01uF and a 1uF directly on the VCC pins. Additionally we added
>a CRC to the data and a verify routine to make sure that we actually
>wrote what we intended to write.
>
>Several different people have reviewed the code without finding any
>errors that could cause the problem. The hardware has been reviewed
>several times without any clues.
>
>Dan
>
>________________________________
>
>From: m...
[mailto:m... ] On
Behalf
>Of Stuart_Rubin
>Sent: Monday, March 17, 2008 11:28 AM
>To: m...
>Subject: [msp430] Re: SOS: Data corruption of MSP 430 Flash
>
>It sounds like your bootloader scheme with the flag is reasonable. Do
>you have built-in protections against overwriting the bootloader?
>
>Another issue may be your clock speed. The Users Guide is very
>prescriptive about the flash write clock (usually a derivative of
>MCLK) as well as VCC, as the previous responder mentioned. Being
>marginally beyond the limits may explain why you have problems with
>one device, but not all of them.
>
>Stuart
>
>--- In m...
,
>"maple_1982" wrote:
>>Hi, Stuart
>>
>>Thanks very much for your reply.
>>Now the flash allocation is like this:
>>
>>0x1000-0x1100 Info Flash for parameters
>>0x2500-0x4000 Bootloader
>>0x4000-0xFFFF Firmware
>>
>>While firmware is running, if we want to upgrade the firmware, we
>>would send a command to set a update flag stored in info flash, and
>>then reset the board. It would enter bootloader and check this flag,
>>if it has been set to UPDATE mode, it would begin the update process
>>and receive data via data , and then program it to flash.
>>So the code won't write itself.
>>
>>I'll look for the possibility that flash program function writes data
>>to a wrong address, which might cause the data corruption.
>>
>>Besides, now the corruption appears in both info flash and code flash
>>(both bootloader and firmware).
>>
>>--- In m...
,
>"Stuart_Rubin"
>>wrote:
>>>Does your code do any flash writing of its own? It's virtually
>>>impossible to accidentally write to flash on this processor.
>>>
>>>If you do have flash-writing capabilities, you probably have a bug
>>>causing the wrong address to be written. It may be hard to
>>>
>>>
>>correlate
>>>the data you're reading with the corrupted data in flash because you
>>>can only "write" 1's to 0's and not 0's to 1's (without erasing the
>>>segment).
>>>
>>>We have done very strenuous "highly accelerated life testing" and
>>>other stress-tests on the flash and have never found corrupted
>>>
>>>
>>flash.
>>>As the previous tester suggested, redundancy or other error-
>>>
>>>
>>detection
>>>information is a good tool (CRC, etc.), but it sounds like your
>>>product may already be deployed.
>>>
>>>Some other hints:
>>>Don't keep code in the same segments as areas that you write to.
>>>Then, customize your flash-writing routines to double-check the
>>>
>>>
>>erase
>>>range for valid addresses.
>>>Encode all data with CRC, checksum, or some kind or error check.
>>>
>>>Stuart
>>>
>>>
>>>
>
parts but I think it is safe to assume that they are not exactly the
same. Therefore, while it is good to know that a 2X part seems to work
well, I would not carry over that data to a 169. In the interest of
full disclosure, my test was done using a 449.
One of the most basic mistakes someone can make is to assume the code is
good. One of the first steps should always be to inspect the code. We
have found many lingering problems in other code this way. However, we
were not able to find any problems with the code in this case. If there
is one it is buried deep.
I did pretty much the same test as you did with 10 449's. The write
sequence was much faster but still within specs on the chip. If memory
serves me I had some units with about a 1 in 10,000 error rate and other
units that did not have any errors until well past the 300,000 mark.
The units were erased/written/checked until they could no longer be
written.
The test showed me several things which are probably good to implement
if possible. Checking a flash write does not take much time. Implement
it. Put some debugging code in there. The new code we are running will
attempt to leave bread crumbs behind. Depending on how the flash fails
(sometimes it was all erased, some times only a single byte was bad) it
may still be possible to get usefully info out of a bad unit.
Several other people on the list have posted about variations of this
problem. It could be a power supply issue but then that just means the
chip is extremely picky about the power supply. TI was very quick to
respond to our request and set up a call with Harman Grewal almost
immediately. This tells me that TI may be hearing about this problem
from other areas. Finally, TI thought it was worth implementing a
"marginal write" feature on the new chips. I can't help but wonder why
this was implemented. Do some of the other chips have some lingering
issues that this "marginal write" feature was aimed at fixing?
I'll be very leery of using any on board flash in the future.
Dan
________________________________
From: m... [mailto:m...] On Behalf
Of One Stone
Sent: Monday, March 17, 2008 12:10 PM
To: m...
Subject: Re: [msp430] Re: SOS: Data corruption of MSP 430 Flash
The recommended decoupling for the supply pins used to be stated as a
10UF in parallel with a 100nF. that is still the case for the 24x
series, but it is not included in the data sheet for the 21x1 parts. I
have been running data logging to a 4k block of flash in temperatures
varying from about 5C to 70C with 1 word write per second since mid
january on 2 test devices and have yet to detect a verify error. (my
code goes)
set loop count
write flash
read flash
if OK then skip
count--
if count!0 loop
exit
It has yet to have to retry. it loops back on the 4k buffer 42+ times
per day, so has done around 2500 erase/write cycles approx or around
5,000,000 writes. Voltage varies between 2.7 and 3.1V. I too have
cheated and used only a 100nF cap to decouple the supply, which is a
CR2477 battery.
For me this sounds much more like a code bug that periodically finds its
way to the flash write routines with unknown data in the 'write buffer'.
I don't recall if the OP said this was intermittent or constant. If
constant simply add a RAM counter to the flash write access code and
trace that against the number of expected accesses. Also double check
that all data and addresses to be written are within bounds. If the
flash procedure is called from only 1 place then have a RAM value that
is set prior to calling the routine and cleared afterwards. his will
have the flash access password in it. In this way no illicit call can
reslt in a write, it will (if enabled) trigger a flash access violation,
which is trackable through the NMI vector. It's just too easy to have
the access settings in the local write procedure, but the dowside is
that a false call to the routne cannot be detected.
Cheers
Al
Dan Muzzey wrote:
>Long story short....
>
>We have had trouble using the MSP430 program space to store data. Some
>testing revealed that there would be an occasional bad flash write or
>bad erase. Not very often but it could happen. In order to combat this
>we have increased the bypass capacitance on Vcc so that we now use a
>couple .01uF and a 1uF directly on the VCC pins. Additionally we added
>a CRC to the data and a verify routine to make sure that we actually
>wrote what we intended to write.
>
>Several different people have reviewed the code without finding any
>errors that could cause the problem. The hardware has been reviewed
>several times without any clues.
>
>Dan
>
>________________________________
>
>From: m...
[mailto:m... ] On
Behalf
>Of Stuart_Rubin
>Sent: Monday, March 17, 2008 11:28 AM
>To: m...
>Subject: [msp430] Re: SOS: Data corruption of MSP 430 Flash
>
>It sounds like your bootloader scheme with the flag is reasonable. Do
>you have built-in protections against overwriting the bootloader?
>
>Another issue may be your clock speed. The Users Guide is very
>prescriptive about the flash write clock (usually a derivative of
>MCLK) as well as VCC, as the previous responder mentioned. Being
>marginally beyond the limits may explain why you have problems with
>one device, but not all of them.
>
>Stuart
>
>--- In m...
,
>"maple_1982" wrote:
>>Hi, Stuart
>>
>>Thanks very much for your reply.
>>Now the flash allocation is like this:
>>
>>0x1000-0x1100 Info Flash for parameters
>>0x2500-0x4000 Bootloader
>>0x4000-0xFFFF Firmware
>>
>>While firmware is running, if we want to upgrade the firmware, we
>>would send a command to set a update flag stored in info flash, and
>>then reset the board. It would enter bootloader and check this flag,
>>if it has been set to UPDATE mode, it would begin the update process
>>and receive data via data , and then program it to flash.
>>So the code won't write itself.
>>
>>I'll look for the possibility that flash program function writes data
>>to a wrong address, which might cause the data corruption.
>>
>>Besides, now the corruption appears in both info flash and code flash
>>(both bootloader and firmware).
>>
>>--- In m...
,
>"Stuart_Rubin"
>>wrote:
>>>Does your code do any flash writing of its own? It's virtually
>>>impossible to accidentally write to flash on this processor.
>>>
>>>If you do have flash-writing capabilities, you probably have a bug
>>>causing the wrong address to be written. It may be hard to
>>>
>>>
>>correlate
>>>the data you're reading with the corrupted data in flash because you
>>>can only "write" 1's to 0's and not 0's to 1's (without erasing the
>>>segment).
>>>
>>>We have done very strenuous "highly accelerated life testing" and
>>>other stress-tests on the flash and have never found corrupted
>>>
>>>
>>flash.
>>>As the previous tester suggested, redundancy or other error-
>>>
>>>
>>detection
>>>information is a good tool (CRC, etc.), but it sounds like your
>>>product may already be deployed.
>>>
>>>Some other hints:
>>>Don't keep code in the same segments as areas that you write to.
>>>Then, customize your flash-writing routines to double-check the
>>>
>>>
>>erase
>>>range for valid addresses.
>>>Encode all data with CRC, checksum, or some kind or error check.
>>>
>>>Stuart
>>>
>>>
>>>
>
Reply by ●March 18, 20082008-03-18
Hi, Hugh
It's a pity that I am not in US, otherwise I would like to talk with
you about this problem in Starbucks of San Diego:)
This problem is serious potentially. Now about one thousand products
have been used in field, but only one board met this problem, but I
am not sure whether the others would come out with this problem in
future. If the code flash was corrupted, we would have to take back
the board and reload the code. The FAE has no way to repair this.
That would cause lots of trouble.
I have read your suggestions several times and will check my code
then. I would give a detailed description after the review. One
problem is that it's hard to reproduce the case.
Thanks so much to your reply. I have never met such a good group in
which there are so many kind-hearted and experienced engineers. Hope
we can help each other and progress together.
--- In m..., Hugh Molesworth
wrote:
>
> I sent this email to your address earlier, but it got bounced.
>
> As I expect you already know, writing anything to FLASH can only
ever
> change a '1' to a '0', so the most likely cause of the problem is
> that indeed something tried to write data to a memory area
> incorrectly. This type of problem could also be caused by marginal
> programming and voltage and temperature extremes, but that is much
> more rare in practice. The usual cause for this problem is a
firmware
> bug triggered by an unexpected or unanticipated sequence of events,
> perhaps triggered by an external site condition. The best approach
to
> solving the problem is usually to do a review of the hardware and
> software of the design. How long that takes depends on the
complexity
> of your system, and how well it is designed.
>
> Should this data corruption be a serious problem for you, then I
> could look through both your schematics and source code to advise
on
> potential problem areas. This brief initial appraisal would be for
no
> charge, and could result in identifying the problem you are seeing
> (or not). If you should happen to be in San Diego, that could be
done
> over a coffee at Starbucks.
>
> Meantime, I'd recommend that you review the FLASH write functions
in
> both Boot Loader and Main Application; in particular pay attention
to
> any pointers and other parameters passed to functions involved in
> such writes to be sure all values are checked for nonsense (for
> example, byte counts too low, too high or addresses pointing at
> unreasonable locations). You might also invest in a version of
Lint,
> which might spot some coding issues you may have missed (such as
> uninitialised variables, holes in switch and if, and so on). Also
> ensure there is no possibility of an interrupt occurring during a
> FLASH write. Also ensure that you have a working NMI interrupt
> handler in place (which must be available in both Boot and Main).
>
> Regards, Hugh
>
> At 06:35 PM 3/16/2008, you wrote:
> In our system, there is a preamble for the firmware, which has the
> firmware's CRC information. Before bootloader boots firmware, it
> would calculate firmware's CRC and check this with the value stored
> in preamble. This can ensure the code integrity, I think.
>
> Now the problem is both bootloader and firmware has been corrupted.
> Bootloader is running abnormally.
>
> --- In m..., "Leon" wrote:
> >
> > ----- Original Message -----
> > From: "maple_1982"
> > To:
> > Sent: Sunday, March 16, 2008 12:31 PM
> > Subject: [msp430] SOS: Data corruption of MSP 430 Flash
> >
> >
> > > Our MCU is MSP430F169. FAE reported that one of our products
> doesn't
> > > work. I have checked it and found it's running strangely. I
> uploaded
> > > its code data and info flash data via JTAG port and
programmer. I
> > > found some of the data has been changed:
> > > The original data is 01 D2 C0 12 80 13 41 D3 00 11 C1 D1 81 D0
40
> 10
> > > but it's changed to 01 40 40 02 00 00 00 00 00 00 00 01 81 D0
40
> 10
> > >
> > > Some data's bits have been changed from 1 to 0.
> > > Both info flash and code flash have this problem.
> > >
> > > I want to know the reason that might cause this problem, since
the
> > > other boards haven't met such problem. There is a voltage
> supervisor
> > > (MAX706) on board, which can reset the mcu if voltage is lower
> that
> > > 2.9V. So there is no possibility that flash was erased nor
written
> > > under 2.7V.
> > >
> > > Besides, at info flash, some parameters are store. At code
flash,
> > > it's composed of bootloader and firmware. Both have flash
program
> > > function.
> > >
> > > Can anybody give some suggestions? Thanks.
> >
> > When I worked on military comms systems, built-in test functions
> were used
> > to check code integrity when a system was first switched on. That
> might be a
> > good idea in your case, even if you find the cause of the
problem.
> >
> > Leon
>
It's a pity that I am not in US, otherwise I would like to talk with
you about this problem in Starbucks of San Diego:)
This problem is serious potentially. Now about one thousand products
have been used in field, but only one board met this problem, but I
am not sure whether the others would come out with this problem in
future. If the code flash was corrupted, we would have to take back
the board and reload the code. The FAE has no way to repair this.
That would cause lots of trouble.
I have read your suggestions several times and will check my code
then. I would give a detailed description after the review. One
problem is that it's hard to reproduce the case.
Thanks so much to your reply. I have never met such a good group in
which there are so many kind-hearted and experienced engineers. Hope
we can help each other and progress together.
--- In m..., Hugh Molesworth
wrote:
>
> I sent this email to your address earlier, but it got bounced.
>
> As I expect you already know, writing anything to FLASH can only
ever
> change a '1' to a '0', so the most likely cause of the problem is
> that indeed something tried to write data to a memory area
> incorrectly. This type of problem could also be caused by marginal
> programming and voltage and temperature extremes, but that is much
> more rare in practice. The usual cause for this problem is a
firmware
> bug triggered by an unexpected or unanticipated sequence of events,
> perhaps triggered by an external site condition. The best approach
to
> solving the problem is usually to do a review of the hardware and
> software of the design. How long that takes depends on the
complexity
> of your system, and how well it is designed.
>
> Should this data corruption be a serious problem for you, then I
> could look through both your schematics and source code to advise
on
> potential problem areas. This brief initial appraisal would be for
no
> charge, and could result in identifying the problem you are seeing
> (or not). If you should happen to be in San Diego, that could be
done
> over a coffee at Starbucks.
>
> Meantime, I'd recommend that you review the FLASH write functions
in
> both Boot Loader and Main Application; in particular pay attention
to
> any pointers and other parameters passed to functions involved in
> such writes to be sure all values are checked for nonsense (for
> example, byte counts too low, too high or addresses pointing at
> unreasonable locations). You might also invest in a version of
Lint,
> which might spot some coding issues you may have missed (such as
> uninitialised variables, holes in switch and if, and so on). Also
> ensure there is no possibility of an interrupt occurring during a
> FLASH write. Also ensure that you have a working NMI interrupt
> handler in place (which must be available in both Boot and Main).
>
> Regards, Hugh
>
> At 06:35 PM 3/16/2008, you wrote:
> In our system, there is a preamble for the firmware, which has the
> firmware's CRC information. Before bootloader boots firmware, it
> would calculate firmware's CRC and check this with the value stored
> in preamble. This can ensure the code integrity, I think.
>
> Now the problem is both bootloader and firmware has been corrupted.
> Bootloader is running abnormally.
>
> --- In m..., "Leon" wrote:
> >
> > ----- Original Message -----
> > From: "maple_1982"
> > To:
> > Sent: Sunday, March 16, 2008 12:31 PM
> > Subject: [msp430] SOS: Data corruption of MSP 430 Flash
> >
> >
> > > Our MCU is MSP430F169. FAE reported that one of our products
> doesn't
> > > work. I have checked it and found it's running strangely. I
> uploaded
> > > its code data and info flash data via JTAG port and
programmer. I
> > > found some of the data has been changed:
> > > The original data is 01 D2 C0 12 80 13 41 D3 00 11 C1 D1 81 D0
40
> 10
> > > but it's changed to 01 40 40 02 00 00 00 00 00 00 00 01 81 D0
40
> 10
> > >
> > > Some data's bits have been changed from 1 to 0.
> > > Both info flash and code flash have this problem.
> > >
> > > I want to know the reason that might cause this problem, since
the
> > > other boards haven't met such problem. There is a voltage
> supervisor
> > > (MAX706) on board, which can reset the mcu if voltage is lower
> that
> > > 2.9V. So there is no possibility that flash was erased nor
written
> > > under 2.7V.
> > >
> > > Besides, at info flash, some parameters are store. At code
flash,
> > > it's composed of bootloader and firmware. Both have flash
program
> > > function.
> > >
> > > Can anybody give some suggestions? Thanks.
> >
> > When I worked on military comms systems, built-in test functions
> were used
> > to check code integrity when a system was first switched on. That
> might be a
> > good idea in your case, even if you find the cause of the
problem.
> >
> > Leon
>
