Howdy folks,

We have an MSP430F155-based product which has it's configuration data stored in the MSP flash info. memory.

On power up, the MSP fills an integer registermap (modbus) array with data from the info. mem, but the info. mem is
only updated when a configuration value has been changed (via software / modbus), which is rare.

Some customers who use this product are seeing a corruption (in most cases complete erasure) of the configuration data, which
means the info. memory is getting corrupted / erased for some reason, at some point.
They give us the impression it is happening even without doing anything (i.e. just powering up!)

Given that the process of updating the info. memory begins by first erasing the info. memory block, then writing to it... then
i can understand the odd unit becoming erased when there's a badly timed power cut at precisly the time just after info. erasure.
But I can't understand why this would happen without performing a write to the info. memory.

NOTES:
- The product is NOT fitted with an external watchdog or supply monitor chip.
- The internal watchdog is set to trigger an interrupt every 8mS
- We use IAR V4.0

Can anyone shed any light on why / at what point / how info. memory may become erased? and perhaps how to avoid
it?

Thanks

Regards,
Darren
This communication contains information which is confidential
and may also be privileged It is for the exclusive use of the
intended recipient(s). If you are not the intended recipient(s),
please note that any distribution, copying or use of this
communication or the information in it is strictly prohibited.
If you have received this communication in error, please
notify the sender immediately and then destroy any copies of it.
[Non-text portions of this message have been removed]
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

----- Original Message -----
From: "Darren Logan"
To:
Sent: Thursday, September 11, 2008 3:52 PM
Subject: [msp430] Info. memory corruption
> Howdy folks,
>
> We have an MSP430F155-based product which has it's configuration data
> stored in the MSP flash info. memory.
>
> On power up, the MSP fills an integer registermap (modbus) array with data
> from the info. mem, but the info. mem is
> only updated when a configuration value has been changed (via software /
> modbus), which is rare.
>
> Some customers who use this product are seeing a corruption (in most cases
> complete erasure) of the configuration data, which
> means the info. memory is getting corrupted / erased for some reason, at
> some point.
> They give us the impression it is happening even without doing anything
> (i.e. just powering up!)
>
> Given that the process of updating the info. memory begins by first
> erasing the info. memory block, then writing to it... then
> i can understand the odd unit becoming erased when there's a badly timed
> power cut at precisly the time just after info. erasure.
> But I can't understand why this would happen without performing a write to
> the info. memory.
>
> NOTES:
> - The product is NOT fitted with an external watchdog or supply monitor
> chip.
> - The internal watchdog is set to trigger an interrupt every 8mS
> - We use IAR V4.0
>
> Can anyone shed any light on why / at what point / how info. memory may
> become erased? and perhaps how to avoid
> it?

How is it powered? If it is powered from the mains it could be getting
transients via the power supply.

Leon
--
Leon Heller
Amateur radio call-sign G1HSM
Yaesu FT-817ND transceiver
Suzuki SV1000S motorcycle
l...@btinternet.com
http://www.geocities.com/leon_heller
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Is it only the info memory? Or is other flash corrupted too?

Edd

--- In m...@yahoogroups.com, "Darren Logan"
wrote:
>
> Howdy folks,
>
> We have an MSP430F155-based product which has it's configuration
data stored in the MSP flash info. memory.
>
> On power up, the MSP fills an integer registermap (modbus) array
with data from the info. mem, but the info. mem is
> only updated when a configuration value has been changed (via
software / modbus), which is rare.
>
> Some customers who use this product are seeing a corruption (in
most cases complete erasure) of the configuration data, which
> means the info. memory is getting corrupted / erased for some
reason, at some point.
> They give us the impression it is happening even without doing
anything (i.e. just powering up!)
>
> Given that the process of updating the info. memory begins by first
erasing the info. memory block, then writing to it... then
> i can understand the odd unit becoming erased when there's a badly
timed power cut at precisly the time just after info. erasure.
> But I can't understand why this would happen without performing a
write to the info. memory.
>
> NOTES:
> - The product is NOT fitted with an external watchdog or supply
monitor chip.
> - The internal watchdog is set to trigger an interrupt every 8mS
> - We use IAR V4.0
>
> Can anyone shed any light on why / at what point / how info. memory
may become erased? and perhaps how to avoid
> it?
>
> Thanks
>
> Regards,
> Darren
> This communication contains information which is confidential
> and may also be privileged It is for the exclusive use of the
> intended recipient(s). If you are not the intended recipient(s),
> please note that any distribution, copying or use of this
> communication or the information in it is strictly prohibited.
> If you have received this communication in error, please
> notify the sender immediately and then destroy any copies of it.
> [Non-text portions of this message have been removed]
>

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



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi Edd / Leon,

It is a transmitter, powererd by DC (between 10 and 24V).
Like any electronics, I guess transients could be getting through - but how will that erase the info. memory?
Could it erase it, even if I'm just READING it?

It is JUST the info. memory getting corrupted. The rest remains unharmed.

Vbr,
Darren

-----Original Message-----
From: m...@yahoogroups.com [mailto:m...@yahoogroups.com]On Behalf Of e.tury
Sent: 11 September 2008 15:59
To: m...@yahoogroups.com
Subject: [msp430] Re: Info. memory corruption

Is it only the info memory? Or is other flash corrupted too?

Edd

--- In msp430@yahoogroups. com, "Darren Logan"
wrote:
>
> Howdy folks,
>
> We have an MSP430F155-based product which has it's configuration
data stored in the MSP flash info. memory.
>
> On power up, the MSP fills an integer registermap (modbus) array
with data from the info. mem, but the info. mem is
> only updated when a configuration value has been changed (via
software / modbus), which is rare.
>
> Some customers who use this product are seeing a corruption (in
most cases complete erasure) of the configuration data, which
> means the info. memory is getting corrupted / erased for some
reason, at some point.
> They give us the impression it is happening even without doing
anything (i.e. just powering up!)
>
> Given that the process of updating the info. memory begins by first
erasing the info. memory block, then writing to it... then
> i can understand the odd unit becoming erased when there's a badly
timed power cut at precisly the time just after info. erasure.
> But I can't understand why this would happen without performing a
write to the info. memory.
>
> NOTES:
> - The product is NOT fitted with an external watchdog or supply
monitor chip.
> - The internal watchdog is set to trigger an interrupt every 8mS
> - We use IAR V4.0
>
> Can anyone shed any light on why / at what point / how info. memory
may become erased? and perhaps how to avoid
> it?
>
> Thanks
>
> Regards,
> Darren
> This communication contains information which is confidential
> and may also be privileged It is for the exclusive use of the
> intended recipient(s). If you are not the intended recipient(s),
> please note that any distribution, copying or use of this
> communication or the information in it is strictly prohibited.
> If you have received this communication in error, please
> notify the sender immediately and then destroy any copies of it.
> [Non-text portions of this message have been removed]
>

This communication contains information which is confidential
and may also be privileged It is for the exclusive use of the
intended recipient(s). If you are not the intended recipient(s),
please note that any distribution, copying or use of this
communication or the information in it is strictly prohibited.
If you have received this communication in error, please
notify the sender immediately and then destroy any copies of it.
[Non-text portions of this message have been removed]
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Darren,

I guess the erase or write processes are executed only under a specific
MODBUS command or especial condition the firmware encounter during normal
work. So, the first place I would check is if there is a condition the
firmware can believe it has received an acceptable command and execute it
even if it hasn't received such a command. Sometimes a MODBUS handling
machine has a simple bit flag to tell other processes it has received a
valid command. If this flag is not properly initialized or there is a chance
of some other process change it by mistake than the main process who will
execute the received MODBUS command may use a scratch RAM data as it was a
valid command package. Depending what command you have had before (since the
voltage to hold the RAM is very low some old data can still be there after a
power off) and having some bits changed because power switching you can find
the lucky pattern and have the info memory erased.

Such possibility can also happen with the processes you have to decide when
to update the info memory.

Since you do not have a power monitor to make a safe wake-up I would
consider doing a checksum in the relevant RAM locations before performing
any command that can erase your data. It is because in the worst case your
CPU may wake at any point in the software (not performing a real reset
process).

The erase command should also come with the new data to be written. Then you
can check the validity of the data before performing the erase. It is the
normal process I have done because you cannot rely your system will, in
fact, receive the new data after an erase command (communications failure,
etc). After an erase command your unit shall be completely useless and it is
why the erase should be done only when you have new data on hand.

Hope it helps,

-Augusto

-----Mensagem original-----
De: m...@yahoogroups.com [mailto:m...@yahoogroups.com] Em nome de Darren
Logan
Enviada em: quinta-feira, 11 de setembro de 2008 11:53
Para: m...@yahoogroups.com
Assunto: [msp430] Info. memory corruption
Prioridade: Alta

Howdy folks,

We have an MSP430F155-based product which has it's configuration data stored
in the MSP flash info. memory.

On power up, the MSP fills an integer registermap (modbus) array with data
from the info. mem, but the info. mem is
only updated when a configuration value has been changed (via software /
modbus), which is rare.

Some customers who use this product are seeing a corruption (in most cases
complete erasure) of the configuration data, which
means the info. memory is getting corrupted / erased for some reason, at
some point.
They give us the impression it is happening even without doing anything
(i.e. just powering up!)

Given that the process of updating the info. memory begins by first erasing
the info. memory block, then writing to it... then
i can understand the odd unit becoming erased when there's a badly timed
power cut at precisly the time just after info. erasure.
But I can't understand why this would happen without performing a write to
the info. memory.

NOTES:
- The product is NOT fitted with an external watchdog or supply monitor
chip.
- The internal watchdog is set to trigger an interrupt every 8mS
- We use IAR V4.0

Can anyone shed any light on why / at what point / how info. memory may
become erased? and perhaps how to avoid
it?

Thanks

Regards,
Darren
This communication contains information which is confidential
and may also be privileged It is for the exclusive use of the
intended recipient(s). If you are not the intended recipient(s),
please note that any distribution, copying or use of this
communication or the information in it is strictly prohibited.
If you have received this communication in error, please
notify the sender immediately and then destroy any copies of it.

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

This sounds more like a software error that is allowing the program
counter to be altered to point somewher in your flash write procedure.
Unless the micro is being hit with very large external noise, induced or
directly through amains power supply if used, or ESD, which I presume
you've looked at before asking for help, then Flash re-writes,
especially something as specific as a block erase require setting of the
correct flash access plus other specific procedures before it can
operate. In general it would be quite rare for an external source, such
as a massive spike froman arc welder or something similar to be so
specific. I would expect semi random corruption throughout the memory,
including program memory, I would expect corruption to 0's NOT erasure
were this the case.

So what else. Low voltage genrally won't do this, providing you have a
decent power up control, even toggling on and off as power rises and
falls under load will not, in my experience cause this sort of problem,
unless the stack is perhaps being corrupted either due to voltage
fluctuations OR noise OR a bug (most likely) causing the program to
perform a jump to flash writing code, so that writes and erases are legal.

tracking down stack bugs, if this is one, is pretty damned hard to do,
especially as you don't know at which point the flash routine is being
entered, although you can deduce that it must be jumping in somewhere
before the flash is unlocked.

This is hard to trace, since it requires storage in RAM of the stack on
entry, but one method you may try is to put in a trap routine. prior to
every call to the flash write routine that is legitimate set a speciifc
2 word code in two different RAM locations, and clear them on exit. In
the flash write routine, immediately before the erase or write test
these, and if either is NOT set jump to an erro handler. Either indictae
a bug to the client and display the stack, or dump the sack, or just
allow the code to stop on error. this won't fix it, but if the fault is
not reproducible in the lab where you can simply set a breakpoit after
the sanity check and work back from there, it may save your ciients
data, albeit clumsily, and perhaps even allow you to set it up to a test
rig and trap the fault.

By the way if there is a power cut during table update you should have
written routines to handle this. as simple as running a table CRC and
reporting or halting on error, or asking for a new table, but handle it,
don't allow the customer to be left in the air guessing. T

Finally the 155 is an old device, is this an old design and a long term
bug, or is this a new design? The 155 also has an SVS and a brownout
detector, are you using these? I've never found i necessary to use any
external monitoring device, especially with newer family members.

Cheers

Al

Darren Logan wrote:

>Howdy folks,
>
>We have an MSP430F155-based product which has it's configuration data stored in the MSP flash info. memory.
>
>On power up, the MSP fills an integer registermap (modbus) array with data from the info. mem, but the info. mem is
>only updated when a configuration value has been changed (via software / modbus), which is rare.
>
>Some customers who use this product are seeing a corruption (in most cases complete erasure) of the configuration data, which
>means the info. memory is getting corrupted / erased for some reason, at some point.
>They give us the impression it is happening even without doing anything (i.e. just powering up!)
>
>Given that the process of updating the info. memory begins by first erasing the info. memory block, then writing to it... then
>i can understand the odd unit becoming erased when there's a badly timed power cut at precisly the time just after info. erasure.
>But I can't understand why this would happen without performing a write to the info. memory.
>
>NOTES:
>- The product is NOT fitted with an external watchdog or supply monitor chip.
>- The internal watchdog is set to trigger an interrupt every 8mS
>- We use IAR V4.0
>
>Can anyone shed any light on why / at what point / how info. memory may become erased? and perhaps how to avoid
>it?
>
>Thanks
>
>Regards,
> Darren
>This communication contains information which is confidential
>and may also be privileged It is for the exclusive use of the
>intended recipient(s). If you are not the intended recipient(s),
>please note that any distribution, copying or use of this
>communication or the information in it is strictly prohibited.
>If you have received this communication in error, please
>notify the sender immediately and then destroy any copies of it.
>[Non-text portions of this message have been removed]
>------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Then I'm sorry to say, as I sugegsted, you most certainly hve a bug, and
most likely something like stack corruption. Is this code in C or asm?
If it does not happen every time then I suggest that some particular
path through the power on sequence (if this is where it happens
immediately after power up) result in the error, taking other paths may
bypass the bug. use tis to find what branches may have been taken at
power on or durign the sequence where this happens if the bug is not
repeatable.

Al

Darren Logan wrote:

>Hi Edd / Leon,
>
>It is a transmitter, powererd by DC (between 10 and 24V).
>Like any electronics, I guess transients could be getting through - but how will that erase the info. memory?
>Could it erase it, even if I'm just READING it?
>
>It is JUST the info. memory getting corrupted. The rest remains unharmed.
>
>Vbr,
> Darren
>-----Original Message-----
>From: m...@yahoogroups.com [mailto:m...@yahoogroups.com]On Behalf Of e.tury
>Sent: 11 September 2008 15:59
>To: m...@yahoogroups.com
>Subject: [msp430] Re: Info. memory corruption
>
>Is it only the info memory? Or is other flash corrupted too?
>
>Edd
>
>--- In msp430@yahoogroups. com, "Darren Logan"
>wrote:
>
>
>>Howdy folks,
>>
>>We have an MSP430F155-based product which has it's configuration
>>
>>
>data stored in the MSP flash info. memory.
>
>
>>On power up, the MSP fills an integer registermap (modbus) array
>>
>>
>with data from the info. mem, but the info. mem is
>
>
>>only updated when a configuration value has been changed (via
>>
>>
>software / modbus), which is rare.
>
>
>>Some customers who use this product are seeing a corruption (in
>>
>>
>most cases complete erasure) of the configuration data, which
>
>
>>means the info. memory is getting corrupted / erased for some
>>
>>
>reason, at some point.
>
>
>>They give us the impression it is happening even without doing
>>
>>
>anything (i.e. just powering up!)
>
>
>>Given that the process of updating the info. memory begins by first
>>
>>
>erasing the info. memory block, then writing to it... then
>
>
>>i can understand the odd unit becoming erased when there's a badly
>>
>>
>timed power cut at precisly the time just after info. erasure.
>
>
>>But I can't understand why this would happen without performing a
>>
>>
>write to the info. memory.
>
>
>>NOTES:
>>- The product is NOT fitted with an external watchdog or supply
>>
>>
>monitor chip.
>
>
>>- The internal watchdog is set to trigger an interrupt every 8mS
>>- We use IAR V4.0
>>
>>Can anyone shed any light on why / at what point / how info. memory
>>
>>
>may become erased? and perhaps how to avoid
>
>
>>it?
>>
>>Thanks
>>
>>Regards,
>>Darren
>>This communication contains information which is confidential
>>and may also be privileged It is for the exclusive use of the
>>intended recipient(s). If you are not the intended recipient(s),
>>please note that any distribution, copying or use of this
>>communication or the information in it is strictly prohibited.
>>If you have received this communication in error, please
>>notify the sender immediately and then destroy any copies of it.
>>[Non-text portions of this message have been removed]
>>
>>
>>This communication contains information which is confidential
>and may also be privileged It is for the exclusive use of the
>intended recipient(s). If you are not the intended recipient(s),
>please note that any distribution, copying or use of this
>communication or the information in it is strictly prohibited.
>If you have received this communication in error, please
>notify the sender immediately and then destroy any copies of it.
>[Non-text portions of this message have been removed]
>------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi Augusto,

Some good pointers there. Thanks.

Note that there is no ERASE command in the modbus itself. The device automatically updates it's info. memory (during
which time it is erased) whenever modbus data comes in.

I guess there may be a condition where the device could think it has new modbus data, even though it hasn't.

It's a particularly frustrating problem because I can't re-produce it on my bench, and without being able to
reproduce it... obviously it's hard to impossible to debug.

I'm rapidly power-cycling the transmitters... switching the PSU on and off like a crazy switching thing, hundreds
of times... but I can't corrupt that data!

As I said originally, it is only when I send some configuration data (via modbus) to the device, that the device will
update it's info. memory.
To update the info. memory, I read it all into scratch ram (temporary store), erase it, then upload the scratch ram
(and any new values just sent by modbus) back into it.
This is the only time the info. memory "should" get erased, so this is obviously the most vulnerable time.

I'll keep looking...

Vbr,
Darren

-----Original Message-----
From: m...@yahoogroups.com [mailto:m...@yahoogroups.com]On Behalf Of Augusto Einsfeldt
Sent: 11 September 2008 16:10
To: m...@yahoogroups.com
Subject: RES: [msp430] Info. memory corruption

Darren,

I guess the erase or write processes are executed only under a specific
MODBUS command or especial condition the firmware encounter during normal
work. So, the first place I would check is if there is a condition the
firmware can believe it has received an acceptable command and execute it
even if it hasn't received such a command. Sometimes a MODBUS handling
machine has a simple bit flag to tell other processes it has received a
valid command. If this flag is not properly initialized or there is a chance
of some other process change it by mistake than the main process who will
execute the received MODBUS command may use a scratch RAM data as it was a
valid command package. Depending what command you have had before (since the
voltage to hold the RAM is very low some old data can still be there after a
power off) and having some bits changed because power switching you can find
the lucky pattern and have the info memory erased.

Such possibility can also happen with the processes you have to decide when
to update the info memory.

Since you do not have a power monitor to make a safe wake-up I would
consider doing a checksum in the relevant RAM locations before performing
any command that can erase your data. It is because in the worst case your
CPU may wake at any point in the software (not performing a real reset
process).

The erase command should also come with the new data to be written. Then you
can check the validity of the data before performing the erase. It is the
normal process I have done because you cannot rely your system will, in
fact, receive the new data after an erase command (communications failure,
etc). After an erase command your unit shall be completely useless and it is
why the erase should be done only when you have new data on hand.

Hope it helps,

-Augusto

-----Mensagem original-----
De: msp430@yahoogroups. com [mailto: msp430@yahoogroups. com] Em nome de Darren
Logan
Enviada em: quinta-feira, 11 de setembro de 2008 11:53
Para: msp430@yahoogroups. com
Assunto: [msp430] Info. memory corruption
Prioridade: Alta

Howdy folks,

We have an MSP430F155-based product which has it's configuration data stored
in the MSP flash info. memory.

On power up, the MSP fills an integer registermap (modbus) array with data
from the info. mem, but the info. mem is
only updated when a configuration value has been changed (via software /
modbus), which is rare.

Some customers who use this product are seeing a corruption (in most cases
complete erasure) of the configuration data, which
means the info. memory is getting corrupted / erased for some reason, at
some point.
They give us the impression it is happening even without doing anything
(i.e. just powering up!)

Given that the process of updating the info. memory begins by first erasing
the info. memory block, then writing to it... then
i can understand the odd unit becoming erased when there's a badly timed
power cut at precisly the time just after info. erasure.
But I can't understand why this would happen without performing a write to
the info. memory.

NOTES:
- The product is NOT fitted with an external watchdog or supply monitor
chip.
- The internal watchdog is set to trigger an interrupt every 8mS
- We use IAR V4.0

Can anyone shed any light on why / at what point / how info. memory may
become erased? and perhaps how to avoid
it?

Thanks

Regards,
Darren
This communication contains information which is confidential
and may also be privileged It is for the exclusive use of the
intended recipient(s). If you are not the intended recipient(s),
please note that any distribution, copying or use of this
communication or the information in it is strictly prohibited.
If you have received this communication in error, please
notify the sender immediately and then destroy any copies of it.

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

This communication contains information which is confidential
and may also be privileged It is for the exclusive use of the
intended recipient(s). If you are not the intended recipient(s),
please note that any distribution, copying or use of this
communication or the information in it is strictly prohibited.
If you have received this communication in error, please
notify the sender immediately and then destroy any copies of it.
[Non-text portions of this message have been removed]
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi Darren,

Since the failure may happen when the unit is switched on then most likely
the main routine believes there is a new valid command received. I would do
two things: erase the command receiver buffer after each command execution
and, of course, check the integrity of the command before executing every
new command received (not relying only in the Command Received Flag).

In the erase/write routines include some checking procedure between the two
unlock instructions. Something like the existence of a word value in RAM
(0xA5CB or other bit pattern). If it is not there you abort the erase/write.
Clear that RAM word after the operation and update it again only when you
have a valid command in the buffer.

This would reduce the chance of damage caused by wrong program counter jump
during power up or glitches.

I know very well the difficulties to debug something that never happens in
the bench. In this case you must try to find how the software could do this
mistaken erase/write and implement verifications to avoid such
possibilities.

Best regards,

-Augusto

-----Mensagem original-----
De: m...@yahoogroups.com [mailto:m...@yahoogroups.com] Em nome de Darren
Logan
Enviada em: quinta-feira, 11 de setembro de 2008 12:30
Para: m...@yahoogroups.com
Assunto: RE: [msp430] Info. memory corruption

Hi Augusto,

Some good pointers there. Thanks.

Note that there is no ERASE command in the modbus itself. The device
automatically updates it's info. memory (during
which time it is erased) whenever modbus data comes in.

I guess there may be a condition where the device could think it has new
modbus data, even though it hasn't.

It's a particularly frustrating problem because I can't re-produce it on my
bench, and without being able to
reproduce it... obviously it's hard to impossible to debug.

I'm rapidly power-cycling the transmitters... switching the PSU on and off
like a crazy switching thing, hundreds
of times... but I can't corrupt that data!

As I said originally, it is only when I send some configuration data (via
modbus) to the device, that the device will
update it's info. memory.
To update the info. memory, I read it all into scratch ram (temporary
store), erase it, then upload the scratch ram
(and any new values just sent by modbus) back into it.
This is the only time the info. memory "should" get erased, so this is
obviously the most vulnerable time.

I'll keep looking...

Vbr,
Darren
-----Original Message-----
From: msp430@yahoogroups. com
[mailto:msp430@yahoogroups. com]On Behalf
Of Augusto Einsfeldt
Sent: 11 September 2008 16:10
To: msp430@yahoogroups. com
Subject: RES: [msp430] Info. memory corruption

Darren,

I guess the erase or write processes are executed only under a specific
MODBUS command or especial condition the firmware encounter during normal
work. So, the first place I would check is if there is a condition the
firmware can believe it has received an acceptable command and execute it
even if it hasn't received such a command. Sometimes a MODBUS handling
machine has a simple bit flag to tell other processes it has received a
valid command. If this flag is not properly initialized or there is a chance
of some other process change it by mistake than the main process who will
execute the received MODBUS command may use a scratch RAM data as it was a
valid command package. Depending what command you have had before (since the
voltage to hold the RAM is very low some old data can still be there after a
power off) and having some bits changed because power switching you can find
the lucky pattern and have the info memory erased.

Such possibility can also happen with the processes you have to decide when
to update the info memory.

Since you do not have a power monitor to make a safe wake-up I would
consider doing a checksum in the relevant RAM locations before performing
any command that can erase your data. It is because in the worst case your
CPU may wake at any point in the software (not performing a real reset
process).

The erase command should also come with the new data to be written. Then you
can check the validity of the data before performing the erase. It is the
normal process I have done because you cannot rely your system will, in
fact, receive the new data after an erase command (communications failure,
etc). After an erase command your unit shall be completely useless and it is
why the erase should be done only when you have new data on hand.

Hope it helps,

-Augusto

-----Mensagem original-----
De: msp430@yahoogroups. com [mailto:
msp430@yahoogroups. com] Em nome de Darren
Logan
Enviada em: quinta-feira, 11 de setembro de 2008 11:53
Para: msp430@yahoogroups. com
Assunto: [msp430] Info. memory corruption
Prioridade: Alta

Howdy folks,

We have an MSP430F155-based product which has it's configuration data stored
in the MSP flash info. memory.

On power up, the MSP fills an integer registermap (modbus) array with data
from the info. mem, but the info. mem is
only updated when a configuration value has been changed (via software /
modbus), which is rare.

Some customers who use this product are seeing a corruption (in most cases
complete erasure) of the configuration data, which
means the info. memory is getting corrupted / erased for some reason, at
some point.
They give us the impression it is happening even without doing anything
(i.e. just powering up!)

Given that the process of updating the info. memory begins by first erasing
the info. memory block, then writing to it... then
i can understand the odd unit becoming erased when there's a badly timed
power cut at precisly the time just after info. erasure.
But I can't understand why this would happen without performing a write to
the info. memory.

NOTES:
- The product is NOT fitted with an external watchdog or supply monitor
chip.
- The internal watchdog is set to trigger an interrupt every 8mS
- We use IAR V4.0

Can anyone shed any light on why / at what point / how info. memory may
become erased? and perhaps how to avoid
it?

Thanks

Regards,
Darren
This communication contains information which is confidential
and may also be privileged It is for the exclusive use of the
intended recipient(s). If you are not the intended recipient(s),
please note that any distribution, copying or use of this
communication or the information in it is strictly prohibited.
If you have received this communication in error, please
notify the sender immediately and then destroy any copies of it.

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

This communication contains information which is confidential
and may also be privileged It is for the exclusive use of the
intended recipient(s). If you are not the intended recipient(s),
please note that any distribution, copying or use of this
communication or the information in it is strictly prohibited.
If you have received this communication in error, please
notify the sender immediately and then destroy any copies of it.

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I designed several similar Modbus systems, and have two suggestions for you.

The first is to duplicate the INFO area parameters; typically use
INFOA as the master and INFOB as the backup. Both areas require an
embedded CRCC, which for convenience can be the same CRCC calculation
as the one used in the Modbus protocol. When updating INFOA on Modbus
command, embed the newly calculated CRCC over the whole of INFOA and
verify that whole update then copy INFOA to INFOB and verify INFOB.
By verify I mean do a byte-by-byte comparison on both INFOA and INFOB
and also calculate and verify a separate CRCC on both. On power up
check the CRCC on both INFOA and INFOB; if INFOA is corrupted repair
it by copying from INFOB and vice versa. If both are corrupted (such
as on newly installed firmware) then restore a set of safe defaults
to both. If you have too much data to sit within the size of INFOA
then use the whole of INFO as your master copy and part of a spare
flash segment in main flash as the backup. In my designs I typically
have 4 parameter areas; 128-byte INFOA and INFOB, and 512-byte
Pareameter_! and Parameter_2. Two primary and two backup, each CRCC
protected. You still need to trap unauthorized Modbus update
commands, of course.

The second suggestion is to observe the worst-case minimum start
voltage on Vcc that will allow a complete erase-update cycle when the
power fails (this complete cycle must be finished before Vcc falls to
2.2V); this start voltage will depend on how fast you switch off
peripherals which consume power and how much pre-regulator and Vcc
bulk capacitance your design contains. You may have to calculate
this, but better to observe it on a 'scope in a real-life scenario as
the power fails with a judiciously placed software-driven output port
toggle which will allow you to observe the start and end of the
erase-write sequence. Other than that you can estimate the value by
assuming a flash erase-write loading of approximately 5mA. Allow a
safety margin on this voltage, so if you measure a start voltage of
(say) 2.7V choose a trip voltage of (say) 2.9V. This trip voltage now
becomes your go/no-go decision point on which to base whether top
allow the erase-write cycle to proceed or not. Of course now you have
to measure this Vcc voltage EVERY time you do a flash erase-write,
but it is well worth doing.

The third suggestion (ok, I have three, not two) is to always do a
test for whether the erase is required at all; either the update data
is the same or the change can be achieved by setting '1's to '0's. I
expect you're doing that anyway to detect if an update is requiored.
In the latter case you have to keep some track of Tcwt, which is a
pain but probably worth doing. Just keep a counter for the total
number of word writes to each sector, and if it is exceeded then
proceed with a full erase rather than taking the short cut.

Hugh

At 08:30 AM 9/11/2008, you wrote:
Hi Augusto,

Some good pointers there. Thanks.

Note that there is no ERASE command in the modbus itself. The device
automatically updates it's info. memory (during
which time it is erased) whenever modbus data comes in.

I guess there may be a condition where the device could think it has
new modbus data, even though it hasn't.

It's a particularly frustrating problem because I can't re-produce it
on my bench, and without being able to
reproduce it... obviously it's hard to impossible to debug.

I'm rapidly power-cycling the transmitters... switching the PSU on
and off like a crazy switching thing, hundreds
of times... but I can't corrupt that data!

As I said originally, it is only when I send some configuration data
(via modbus) to the device, that the device will
update it's info. memory.
To update the info. memory, I read it all into scratch ram (temporary
store), erase it, then upload the scratch ram
(and any new values just sent by modbus) back into it.
This is the only time the info. memory "should" get erased, so this
is obviously the most vulnerable time.

I'll keep looking...

Vbr,
Darren
-----Original Message-----
From: m...@yahoogroups.com [mailto:m...@yahoogroups.com]On Behalf
Of Augusto Einsfeldt
Sent: 11 September 2008 16:10
To: m...@yahoogroups.com
Subject: RES: [msp430] Info. memory corruption

Darren,

I guess the erase or write processes are executed only under a specific
MODBUS command or especial condition the firmware encounter during normal
work. So, the first place I would check is if there is a condition the
firmware can believe it has received an acceptable command and execute it
even if it hasn't received such a command. Sometimes a MODBUS handling
machine has a simple bit flag to tell other processes it has received a
valid command. If this flag is not properly initialized or there is a chance
of some other process change it by mistake than the main process who will
execute the received MODBUS command may use a scratch RAM data as it was a
valid command package. Depending what command you have had before (since the
voltage to hold the RAM is very low some old data can still be there after a
power off) and having some bits changed because power switching you can find
the lucky pattern and have the info memory erased.

Such possibility can also happen with the processes you have to decide when
to update the info memory.

Since you do not have a power monitor to make a safe wake-up I would
consider doing a checksum in the relevant RAM locations before performing
any command that can erase your data. It is because in the worst case your
CPU may wake at any point in the software (not performing a real reset
process).

The erase command should also come with the new data to be written. Then you
can check the validity of the data before performing the erase. It is the
normal process I have done because you cannot rely your system will, in
fact, receive the new data after an erase command (communications failure,
etc). After an erase command your unit shall be completely useless and it is
why the erase should be done only when you have new data on hand.

Hope it helps,

-Augusto

-----Mensagem original-----
De: msp430@yahoogroups. com
[mailto: msp430@yahoogroups. com]
Em nome de Darren
Logan
Enviada em: quinta-feira, 11 de setembro de 2008 11:53
Para: msp430@yahoogroups. com
Assunto: [msp430] Info. memory corruption
Prioridade: Alta

Howdy folks,

We have an MSP430F155-based product which has it's configuration data stored
in the MSP flash info. memory.

On power up, the MSP fills an integer registermap (modbus) array with data
from the info. mem, but the info. mem is
only updated when a configuration value has been changed (via software /
modbus), which is rare.

Some customers who use this product are seeing a corruption (in most cases
complete erasure) of the configuration data, which
means the info. memory is getting corrupted / erased for some reason, at
some point.
They give us the impression it is happening even without doing anything
(i.e. just powering up!)

Given that the process of updating the info. memory begins by first erasing
the info. memory block, then writing to it... then
i can understand the odd unit becoming erased when there's a badly timed
power cut at precisly the time just after info. erasure.
But I can't understand why this would happen without performing a write to
the info. memory.

NOTES:
- The product is NOT fitted with an external watchdog or supply monitor
chip.
- The internal watchdog is set to trigger an interrupt every 8mS
- We use IAR V4.0

Can anyone shed any light on why / at what point / how info. memory may
become erased? and perhaps how to avoid
it?

Thanks

Regards,
Darren

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



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Oh, one other thought. Modbus isn't a very strong protocol,
particularly when you have multiple slaves and therefore lots of
message packets which should be ignored. It is possible to have a
good message left over from a prior transaction in the buffer, with
(say) just the first character or two reset to indicate that there is
no valid message. Now along comes a bit of noise on the serial line,
which of course starts to populate the message packet buffer, and
this fills in those first few locations. Modbus RTU end-of-packet is
indicated by time, not or any other character, so now you have
a "complete" message constructed partially from a previous message
and partly from line noise. This should be rejected by address
mis-match or CRCC fail or some byte-count mechanism, but if it
happens a lot there will come a time when the message can be accepted
as valid. Not convinced? I have seen this happen, and resorted to
wiping the entire message buffer to '0's after processing as another
level of protection. If your Modbus physical layer happens to be
wireless as opposed to RS485 or some other wired layer, then it is
even more vulnerable.

Hugh

At 09:24 AM 9/11/2008, hugh wrote:
I designed several similar Modbus systems, and have two suggestions for you.

The first is to duplicate the INFO area parameters; typically use
INFOA as the master and INFOB as the backup. Both areas require an
embedded CRCC, which for convenience can be the same CRCC calculation
as the one used in the Modbus protocol. When updating INFOA on Modbus
command, embed the newly calculated CRCC over the whole of INFOA and
verify that whole update then copy INFOA to INFOB and verify INFOB.
By verify I mean do a byte-by-byte comparison on both INFOA and INFOB
and also calculate and verify a separate CRCC on both. On power up
check the CRCC on both INFOA and INFOB; if INFOA is corrupted repair
it by copying from INFOB and vice versa. If both are corrupted (such
as on newly installed firmware) then restore a set of safe defaults
to both. If you have too much data to sit within the size of INFOA
then use the whole of INFO as your master copy and part of a spare
flash segment in main flash as the backup. In my designs I typically
have 4 parameter areas; 128-byte INFOA and INFOB, and 512-byte
Pareameter_! and Parameter_2. Two primary and two backup, each CRCC
protected. You still need to trap unauthorized Modbus update
commands, of course.

The second suggestion is to observe the worst-case minimum start
voltage on Vcc that will allow a complete erase-update cycle when the
power fails (this complete cycle must be finished before Vcc falls to
2.2V); this start voltage will depend on how fast you switch off
peripherals which consume power and how much pre-regulator and Vcc
bulk capacitance your design contains. You may have to calculate
this, but better to observe it on a 'scope in a real-life scenario as
the power fails with a judiciously placed software-driven output port
toggle which will allow you to observe the start and end of the
erase-write sequence. Other than that you can estimate the value by
assuming a flash erase-write loading of approximately 5mA. Allow a
safety margin on this voltage, so if you measure a start voltage of
(say) 2.7V choose a trip voltage of (say) 2.9V. This trip voltage now
becomes your go/no-go decision point on which to base whether top
allow the erase-write cycle to proceed or not. Of course now you have
to measure this Vcc voltage EVERY time you do a flash erase-write,
but it is well worth doing.

The third suggestion (ok, I have three, not two) is to always do a
test for whether the erase is required at all; either the update data
is the same or the change can be achieved by setting '1's to '0's. I
expect you're doing that anyway to detect if an update is requiored.
In the latter case you have to keep some track of Tcwt, which is a
pain but probably worth doing. Just keep a counter for the total
number of word writes to each sector, and if it is exceeded then
proceed with a full erase rather than taking the short cut.

Hugh

At 08:30 AM 9/11/2008, you wrote:
Hi Augusto,

Some good pointers there. Thanks.

Note that there is no ERASE command in the modbus itself. The device
automatically updates it's info. memory (during
which time it is erased) whenever modbus data comes in.

I guess there may be a condition where the device could think it has
new modbus data, even though it hasn't.

It's a particularly frustrating problem because I can't re-produce it
on my bench, and without being able to
reproduce it... obviously it's hard to impossible to debug.

I'm rapidly power-cycling the transmitters... switching the PSU on
and off like a crazy switching thing, hundreds
of times... but I can't corrupt that data!

As I said originally, it is only when I send some configuration data
(via modbus) to the device, that the device will
update it's info. memory.
To update the info. memory, I read it all into scratch ram (temporary
store), erase it, then upload the scratch ram
(and any new values just sent by modbus) back into it.
This is the only time the info. memory "should" get erased, so this
is obviously the most vulnerable time.

I'll keep looking...

Vbr,
Darren
-----Original Message-----
From: m...@yahoogroups.com [mailto:m...@yahoogroups.com]On Behalf
Of Augusto Einsfeldt
Sent: 11 September 2008 16:10
To: m...@yahoogroups.com
Subject: RES: [msp430] Info. memory corruption

Darren,

I guess the erase or write processes are executed only under a specific
MODBUS command or especial condition the firmware encounter during normal
work. So, the first place I would check is if there is a condition the
firmware can believe it has received an acceptable command and execute it
even if it hasn't received such a command. Sometimes a MODBUS handling
machine has a simple bit flag to tell other processes it has received a
valid command. If this flag is not properly initialized or there is a chance
of some other process change it by mistake than the main process who will
execute the received MODBUS command may use a scratch RAM data as it was a
valid command package. Depending what command you have had before (since the
voltage to hold the RAM is very low some old data can still be there after a
power off) and having some bits changed because power switching you can find
the lucky pattern and have the info memory erased.

Such possibility can also happen with the processes you have to decide when
to update the info memory.

Since you do not have a power monitor to make a safe wake-up I would
consider doing a checksum in the relevant RAM locations before performing
any command that can erase your data. It is because in the worst case your
CPU may wake at any point in the software (not performing a real reset
process).

The erase command should also come with the new data to be written. Then you
can check the validity of the data before performing the erase. It is the
normal process I have done because you cannot rely your system will, in
fact, receive the new data after an erase command (communications failure,
etc). After an erase command your unit shall be completely useless and it is
why the erase should be done only when you have new data on hand.

Hope it helps,

-Augusto

-----Mensagem original-----
De: msp430@yahoogroups. com
[mailto: msp430@yahoogroups. com]
Em nome de Darren
Logan
Enviada em: quinta-feira, 11 de setembro de 2008 11:53
Para: msp430@yahoogroups. com
Assunto: [msp430] Info. memory corruption
Prioridade: Alta

Howdy folks,

We have an MSP430F155-based product which has it's configuration data stored
in the MSP flash info. memory.

On power up, the MSP fills an integer registermap (modbus) array with data
from the info. mem, but the info. mem is
only updated when a configuration value has been changed (via software /
modbus), which is rare.

Some customers who use this product are seeing a corruption (in most cases
complete erasure) of the configuration data, which
means the info. memory is getting corrupted / erased for some reason, at
some point.
They give us the impression it is happening even without doing anything
(i.e. just powering up!)

Given that the process of updating the info. memory begins by first erasing
the info. memory block, then writing to it... then
i can understand the odd unit becoming erased when there's a badly timed
power cut at precisly the time just after info. erasure.
But I can't understand why this would happen without performing a write to
the info. memory.

NOTES:
- The product is NOT fitted with an external watchdog or supply monitor
chip.
- The internal watchdog is set to trigger an interrupt every 8mS
- We use IAR V4.0

Can anyone shed any light on why / at what point / how info. memory may
become erased? and perhaps how to avoid
it?

Thanks

Regards,
Darren

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



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I'm sure I'm missing something obvious and will have egg on my face but ....

Document SLAU144C lists USART registers in 12.4 (table 12-6):
Control reg 0: 60h
Receive buffer 66h
Status reg 65h
etc.

Basically - in the 60-6Fh range is where everything sits

However:
Looking at msp430-gcc header files:
...../include/msp430/usart.h shows
U0CTL 0x70
RXBUF 0x76
TXBUF 0x77

Basically - 70-7F range.
(and I haven't seen sign of Status Reg yet - but maybe I haven't looked
enough yet).

Yes - there are some 12x and 12x2 #if-defines to tap-dance through - but
I don't see any of those shifting the
address ranges that I'm whingeing about.

So - what have I missed? I'm going to have a cup of coffee and hope that
fixes the problem. It's worked before. :)

Thanks
rde

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



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

SLAU144 is for the entire F2xx family. Some members of F2xx have the
so called USCI module. Some others have the so called USI module
instead. Still others have none of the above. You have to look at the
datasheet of the specific member to find out what it has and then go
to the corresponding Chapter/Section of SLAU144. USI and USCI are
different!

By the way, the current rev for SLAU144 is "E", and you have "C".

--- In m...@yahoogroups.com, Roger Edgecombe wrote:
>
> I'm sure I'm missing something obvious and will have egg on my face
but ....
>
> Document SLAU144C lists USART registers in 12.4 (table 12-6):
> Control reg 0: 60h
> Receive buffer 66h
> Status reg 65h
> etc.
>
> Basically - in the 60-6Fh range is where everything sits
>
> However:
> Looking at msp430-gcc header files:
> ...../include/msp430/usart.h shows
> U0CTL 0x70
> RXBUF 0x76
> TXBUF 0x77
>
> Basically - 70-7F range.
> (and I haven't seen sign of Status Reg yet - but maybe I haven't looked
> enough yet).
>
> Yes - there are some 12x and 12x2 #if-defines to tap-dance through -
but
> I don't see any of those shifting the
> address ranges that I'm whingeing about.
>
> So - what have I missed? I'm going to have a cup of coffee and hope
that
> fixes the problem. It's worked before. :)
>
> Thanks
> rde
>

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



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

old_cow_yellow wrote:]

Many thanks .. I can stop hair-tearing here. :)

cheers
rde

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



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )