Hugh

Thanks for your very detailed and expansive response. I've done my best to answer the points you've raised below.

> Note here that since we have
> not had sight of any code, we assume that you are
> correctly handling both receiver overruns and
> received frame errors, and often in code I have
> reviewed this is not the case :-)

I don't really want to go to the extent of posting code on a public forum at this stage but the UART0 receive ISR is very simple, in essence the procedure is;

If RXERR set in U0RCTL then record contents of U0RCTL in error log and read U0RXBUF to clear error, loop to start of ISR if URXIFG0 still set in IFG1.

If RXERR clear in U0RCTL then read U0RXBUF, process received character and exit LPM3 if full msg received, loop to start of ISR if URXIFG0 still set in IFG1.

Simple length and CRC16 processing of received bytes is done inside the ISR and the foreground code is restarted when a full packet is received by clearing CPUOFF, SCG1 and SCG0 flags in the foreground SR on the stack. Neither UART0 RX or RX interrupt are disabled while the foreground code processes and responds to the received msg. With this configuration it should not be possible for an overrun error to occur, GIE is never cleared for more than a few instructions during the msg processing code, except for one case in the event recording (see below).

The only process I can I identify that does clear GIE long enough for an overrun to be possible is the event recording process. Occasionally the event log fills up and it is necessary to erase one of the Flash sectors to allow event logging to continue. The Flash sector erase operation takes 4819 Flash controller cycles and 8 (6 time/date, 2 event code) Flash byte write operations take 8x33 controller cycles, 5083 cycles in total. Flash clock is the DCO frequency divided by 3 to give 400kHz. This means the Flash erase and program operation takes approx 13ms, long enough for 3 characters to be received at 2400bps. But I don't believe this is happening because if it were then I would expect to see an event log entry followed immediately by an overrun event log entry, and this is not the case, the overruns occur in isolation.

> USART0 - which you indicated is source of the
> problem with overruns - can only be properly
> eclipsed on the F1481 by the watchdog timer,
> comparator A, Timer B7, NMI group (NMI, Flash,
> Oscillator fault) or various forms of reset.
> So, which of these are enabled?

Watchdog is configured as interval timer, Timer B7 (both vectors) for TBCCR0,1,2 interrupts, all the other interrupt sources you mentioned are disabled.

> Now we have two options, foreground stall with
> GIE reset or a high-priority interrupt thrashing.
> There is a third option, where the cpu is stalled
> with GIE set so that the USART0 interrupts are
> running, but the code fails when the foreground
> code does not process received data buffers such
> that they fill and the receiver interrupt then
> (erroneously) allows a receiver overrun condition
> to occur because it incorrectly stops emptying
> the USART Rx register. Only an inspection of your
> code will reveal that :-) Actually of course
> there is a fourth option as well, the RTC simply
> never brings the cpu core out of sleep.

When the RTC interrupt level code is still running, but the foreground code appears to be stalled, I can infer that the instruction that brings the foreground code out of LPM3 is being executed because there is an event that is recorded directly afterwards. The code could not record the event without executing the LPM3 exit instruction first.

For info, the foreground code only enters LPM3 in two places and in both instances the stack pointer would/should be pointing to the same location, therefore the location of the saved foreground SR on the stack is fixed. The instruction to exit LPM3 is therefore bic.w #CPU_OFF+SCG1+SCG0, &STACK_ORG-4

> So why would a bit or whatever not do the
> expected thing? Here are some known hardware bugs
> in the F1481, and let's start with the bug that
> can "lose" a hardware handshake from a GSM modem
> (are you using either P1 or P2 to handshake with
> the modem or anything else in your design? :-)
> What happens when the handshake doesn't? ...)

There is no hardware comms handshaking with the modem, or anything else for that matter. With regards to the rest of the device errata you mentioned, we've been through all the reported hardware bugs and discounted them all, either because we're not using the affected hardware feature or because it would have no affect on the problem we're facing.

I think I'm at the stage now where I need to review the firmware, put some of the suggestions made into operation and wait for results. I'll report back with my findings.

Thanks everyone.

Start a New Thread

Good answers, just a couple points more, or perhaps they are recommendations.

Do you check RXERR only, or separately to subsequently checking FE,
PE, OE & BRK or do you check them all together in an atomic test?
What I'm getting at here is that U0RCTL should only be read a single
time for each pass (where there is more than one pass) through the
isr. Do you have URXSE set to improve glitch rejection?

How does the isr "record contents of U0RCTL in the error log"?
Hopefully this means you have a buffer in RAM which is simply
incremented or indexed in the isr and is subsequently copied out to
flash by the main foreground process when it next wakes from sleep
and updates flash at a minimum "safe" interval; that interval might
be once per minute, for example. If not - and the error was written
direct to flash from within the isr - then any receive error could
automatically generate (further) overrun errors due to the flash
write time (oh, maybe not, 2400 is pretty slow ..) but more
importantly expose you to the US13 bug. Remember the isr is entered
only at the end of a received character, and the next character must
be removed from RXBUF within 2 bit times, which is only about 800
uSecs. Also if a spurious extra character should be received while
checking the crcc for the previous message this could also be an
issue, particularly if the GSM modem shuts itself off quickly or
generates garbage for other reasons.

How long are the Timer_B interrupts? Hopefully significantly shorter
than 2 bit times (U13 again) @ 2400 baud, which probably means that
there can be no flash writes within the Timer_B isrs in case they
occur when characters are being received.

Side issue, but are you observing tCPT (now only 4mSecs) for the
flash write sequences? It can be difficult to meet and usually only
by ever writing 16-bit words not 8-bit bytes. Multiple segment erase
is also difficult to do without breaking down the erase cycle due to
tCMErase. However you don't report any flash corruption issues so you
may be ok.

Looks like the consensus to fix your site issues is probably just
activating the watchdog, which will fix pretty much all the issues
we've explored; unfortunately that won't help if you are being hit by
the brown-out problem, though it doesn't sound like your units lock
up forever so you may be ok there.

Hugh

At 06:54 AM 11/24/2009, you wrote:

Hugh

Thanks for your very detailed and expansive response. I've done my
best to answer the points you've raised below.

> Note here that since we have
> not had sight of any code, we assume that you are
> correctly handling both receiver overruns and
> received frame errors, and often in code I have
> reviewed this is not the case :-)

I don't really want to go to the extent of posting code on a public
forum at this stage but the UART0 receive ISR is very simple, in
essence the procedure is;

If RXERR set in U0RCTL then record contents of U0RCTL in error log
and read U0RXBUF to clear error, loop to start of ISR if URXIFG0
still set in IFG1.

If RXERR clear in U0RCTL then read U0RXBUF, process received
character and exit LPM3 if full msg received, loop to start of ISR if
URXIFG0 still set in IFG1.

Simple length and CRC16 processing of received bytes is done inside
the ISR and the foreground code is restarted when a full packet is
received by clearing CPUOFF, SCG1 and SCG0 flags in the foreground SR
on the stack. Neither UART0 RX or RX interrupt are disabled while
the foreground code processes and responds to the received msg. With
this configuration it should not be possible for an overrun error to
occur, GIE is never cleared for more than a few instructions during
the msg processing code, except for one case in the event recording
(see below).

The only process I can I identify that does clear GIE long enough for
an overrun to be possible is the event recording
process. Occasionally the event log fills up and it is necessary to
erase one of the Flash sectors to allow event logging to
continue. The Flash sector erase operation takes 4819 Flash
controller cycles and 8 (6 time/date, 2 event code) Flash byte write
operations take 8x33 controller cycles, 5083 cycles in total. Flash
clock is the DCO frequency divided by 3 to give 400kHz. This means
the Flash erase and program operation takes approx 13ms, long enough
for 3 characters to be received at 2400bps. But I don't believe this
is happening because if it were then I would expect to see an event
log entry followed immediately by an overrun event log entry, and
this is not the case, the overruns occur in isolation.

> USART0 - which you indicated is source of the
> problem with overruns - can only be properly
> eclipsed on the F1481 by the watchdog timer,
> comparator A, Timer B7, NMI group (NMI, Flash,
> Oscillator fault) or various forms of reset.
> So, which of these are enabled?

Watchdog is configured as interval timer, Timer B7 (both vectors) for
TBCCR0,1,2 interrupts, all the other interrupt sources you mentioned
are disabled.

> Now we have two options, foreground stall with
> GIE reset or a high-priority interrupt thrashing.
> There is a third option, where the cpu is stalled
> with GIE set so that the USART0 interrupts are
> running, but the code fails when the foreground
> code does not process received data buffers such
> that they fill and the receiver interrupt then
> (erroneously) allows a receiver overrun condition
> to occur because it incorrectly stops emptying
> the USART Rx register. Only an inspection of your
> code will reveal that :-) Actually of course
> there is a fourth option as well, the RTC simply
> never brings the cpu core out of sleep.

When the RTC interrupt level code is still running, but the
foreground code appears to be stalled, I can infer that the
instruction that brings the foreground code out of LPM3 is being
executed because there is an event that is recorded directly
afterwards. The code could not record the event without executing
the LPM3 exit instruction first.

For info, the foreground code only enters LPM3 in two places and in
both instances the stack pointer would/should be pointing to the same
location, therefore the location of the saved foreground SR on the
stack is fixed. The instruction to exit LPM3 is therefore bic.w
#CPU_OFF+SCG1+SCG0, &STACK_ORG-4

> So why would a bit or whatever not do the
> expected thing? Here are some known hardware bugs
> in the F1481, and let's start with the bug that
> can "lose" a hardware handshake from a GSM modem
> (are you using either P1 or P2 to handshake with
> the modem or anything else in your design? :-)
> What happens when the handshake doesn't? ...)

There is no hardware comms handshaking with the modem, or anything
else for that matter. With regards to the rest of the device errata
you mentioned, we've been through all the reported hardware bugs and
discounted them all, either because we're not using the affected
hardware feature or because it would have no affect on the problem
we're facing.

I think I'm at the stage now where I need to review the firmware, put
some of the suggestions made into operation and wait for
results. I'll report back with my findings.

Thanks everyone.

Start a New Thread

Hugh, thanks for your response. Answers to your questions below.

> Do you check RXERR only, or separately to subsequently checking FE,
> PE, OE & BRK or do you check them all together in an atomic test?
> What I'm getting at here is that U0RCTL should only be read a single
> time for each pass (where there is more than one pass) through the
> isr. Do you have URXSE set to improve glitch rejection?

We check individual bit RXERR in U0RCTL to see if it is set and, if so, U0RCTL is read again during the transfer to event log, so it is read twice. I can find no reason why this shouldn't be allowed, can you elaborate?

Actually I have to put my hands up to something, reading through the code and the user guide again I can now see that URXEIE is never set in our application, so the only RX errors that will ever set URXIFG0 are overrun errors, FE, PE and BRK errors will be ignored. This explains the lack of framing or break errors, parity is disabled anyway. I will rectify this.

We're not using URXS (URXSE=0) because we're sourcing BRCLK from 32768Hz crystal that is always on for RTC. I think/hope this makes us immune to US13 bug.

> How does the isr "record contents of U0RCTL in the error log"?
> Hopefully this means you have a buffer in RAM which is simply
> incremented or indexed in the isr and is subsequently copied out to
> flash by the main foreground process when it next wakes from sleep
> and updates flash at a minimum "safe" interval; that interval might
> be once per minute, for example. If not - and the error was written
> direct to flash from within the isr - then any receive error could
> automatically generate (further) overrun errors due to the flash
> write time (oh, maybe not, 2400 is pretty slow ..) but more
> importantly expose you to the US13 bug. Remember the isr is entered
> only at the end of a received character, and the next character must
> be removed from RXBUF within 2 bit times, which is only about 800
> uSecs. Also if a spurious extra character should be received while
> checking the crcc for the previous message this could also be an
> issue, particularly if the GSM modem shuts itself off quickly or
> generates garbage for other reasons.

The event is written directly to Flash within the ISR, the Flash write only requires 660us and at 2400bps characters arrive at a maximum of 4.16ms, so that should be safe (except when a sector erase is required, 1 in 64 chance, but I don't think this is happening for reasons already explained in previous post). The 2 bit times restriction only applies when URXSE=1, or so I believe.

> How long are the Timer_B interrupts? Hopefully significantly shorter
> than 2 bit times (U13 again) @ 2400 baud, which probably means that
> there can be no flash writes within the Timer_B isrs in case they
> occur when characters are being received.

Timer B interrupts are handled very quickly, no event writing, no more than six instructions each.

> Side issue, but are you observing tCPT (now only 4mSecs) for the
> flash write sequences? It can be difficult to meet and usually only
> by ever writing 16-bit words not 8-bit bytes. Multiple segment erase
> is also difficult to do without breaking down the erase cycle due to
> tCMErase. However you don't report any flash corruption issues so you
> may be ok.

tCPT is only applicable to segment writes, I believe. I'm not familiar with tCMErase, can't find it mentioned anywhere.

> Looks like the consensus to fix your site issues is probably just
> activating the watchdog, which will fix pretty much all the issues
> we've explored; unfortunately that won't help if you are being hit by
> the brown-out problem, though it doesn't sound like your units lock
> up forever so you may be ok there.

Yep, I agree, going to make a big effort to get the Watchdog implemented.

Thanks again.

Start a New Thread

Hi Yoda

Interesting comments, especially about URXEIE not being enabled; that
of course re-opens the possibility of occasional garbage from the GSM
modem being the cause of the overruns, particularly when you combine
that with the URXSE bit not rejecting those GSM transmission burst
glitches. It also gives a tilt towards a code review, since even the
most experienced developers can overlook such an issue which might be
quickly picked up by another pair of eyes. I understand your
reluctance to post code here however, and many companies expressly
forbid such posting.

Registers such as U0RCTL could clearly have bits set after the
initial read, which could affect the desired course of action. So it
is good practice to read such a register just once, with a local copy
then being used to derive individual actions. For example, in this
case a second incoming character could fiddle with some of the error
bits and the code could erroneously apply those newly fiddled bits to
the first (good) character; unlikely in your case since the GSM
interaction is so slow, but good practice nonetheless. Hopefully the
error bits would then be correctly applied on the second loop through
the isr. However there are no specific reasons applying to this
register. I'm curious, by the way, why is the baud rate so slow? 9600
is pretty safe using modulation bits and a 32.768kHz crystal, and the
higher baud rate reduces the time in which the packet can be corrupted.

tCPT applies to every byte and word write. You cannot write 64 bytes
to any flash block in any flash segment without violating this
parameter and risking flash corruption. Here is an email I sent to
this group some time ago discussing the issue:

"All Flash fails in time. The variable aspect of this time to failure
depends primarily on two factors, the "depth" of the programming and
the ambient temperature in use. The "depth" is affected by both the
issues we are discussing, since using too short a programming time
leads to a marginal '0' (ie. a '0' that may in time become a '1') and
exceeding Tcpt leads to a marginal '1' (ie. a '1' that may in time
become a '0'). Since you've addressed the first, let me explain the
second (Tcpt) by pasting in an email I sent to the User Group some
time ago (you should verify these figures against the data sheet
version relevant to the parts you are using, by the way):

'There has been a worrying change in the data sheet for the MSP Flash
electrical specifications concerning parameter tCPT (Cumulative
Programming Time). Once upon a time this used to be 3 mSecs for each
block. In the current release it is 4 mSecs for each block but now
additionally applies to ALL programming methods whether individual
word/byte write or block write modes. This is bad news.

Flash write time Tword is defined in cycles, nominally 35 cycles.
At the shortest programming time (with max clock) 476kHz -> 2.1 uSecs
per cycle. 35 cycles -> 73.5 uSecs. 4 mSecs contains just 54 of these
73.5 uSec periods ...
At the longest programming time (with min clock) 257kHz -> 3.89 uSecs
per cycle. 35 cycles -> 136.2 uSecs. 4 mSecs contains just 29 of
these 136.2 uSec periods.

This implies that even at the maximum clock only 54 writes are
allowed to each 64-byte block before the Tcpt parameter is violated.
This plays havoc with any schemes that use incremental sequential
writes to minimise flash erase cycles. Not only that, but you can't
even write 64 bytes to a 64-byte block, instead you have to write 32
16-bit words or some combination of bytes and words (or use block
write mode from RAM).'"

Another tip for the next design is to isolate the MSP430 LDO with a
series schottky to the battery side of the input capacitor to limit
power dips feeding through the LDO's poor high frequency PSRR. The
MSP430 & LDO ground should only be common with the GSM modem at the
battery terminal to minimise ground bounce. Of course using sealed
lead-acid batteries also helps ...

So another important question, why is my nicely typed text so
irritatingly shortened to tiny lines in the posts when I read them
back, when yours and others are not? Is it because I chose to use the
"old style" without all the advertising down the right edge?

Regards
Hugh

At 03:57 AM 11/25/2009, you wrote:
>Hugh, thanks for your response. Answers to your questions below.
>
> > Do you check RXERR only, or separately to subsequently checking FE,
> > PE, OE & BRK or do you check them all together in an atomic test?
> > What I'm getting at here is that U0RCTL should only be read a single
> > time for each pass (where there is more than one pass) through the
> > isr. Do you have URXSE set to improve glitch rejection?
>
>We check individual bit RXERR in U0RCTL to see if it is set and, if
>so, U0RCTL is read again during the transfer to event log, so it is
>read twice. I can find no reason why this shouldn't be allowed, can
>you elaborate?
>
>Actually I have to put my hands up to something, reading through the
>code and the user guide again I can now see that URXEIE is never set
>in our application, so the only RX errors that will ever set URXIFG0
>are overrun errors, FE, PE and BRK errors will be ignored. This
>explains the lack of framing or break errors, parity is disabled
>anyway. I will rectify this.
>
>We're not using URXS (URXSE=0) because we're sourcing BRCLK from
>32768Hz crystal that is always on for RTC. I think/hope this makes
>us immune to US13 bug.
>
> > How does the isr "record contents of U0RCTL in the error log"?
> > Hopefully this means you have a buffer in RAM which is simply
> > incremented or indexed in the isr and is subsequently copied out to
> > flash by the main foreground process when it next wakes from sleep
> > and updates flash at a minimum "safe" interval; that interval might
> > be once per minute, for example. If not - and the error was written
> > direct to flash from within the isr - then any receive error could
> > automatically generate (further) overrun errors due to the flash
> > write time (oh, maybe not, 2400 is pretty slow ..) but more
> > importantly expose you to the US13 bug. Remember the isr is entered
> > only at the end of a received character, and the next character must
> > be removed from RXBUF within 2 bit times, which is only about 800
> > uSecs. Also if a spurious extra character should be received while
> > checking the crcc for the previous message this could also be an
> > issue, particularly if the GSM modem shuts itself off quickly or
> > generates garbage for other reasons.
>
>The event is written directly to Flash within the ISR, the Flash
>write only requires 660us and at 2400bps characters arrive at a
>maximum of 4.16ms, so that should be safe (except when a sector
>erase is required, 1 in 64 chance, but I don't think this is
>happening for reasons already explained in previous post). The 2
>bit times restriction only applies when URXSE=1, or so I believe.
>
> > How long are the Timer_B interrupts? Hopefully significantly shorter
> > than 2 bit times (U13 again) @ 2400 baud, which probably means that
> > there can be no flash writes within the Timer_B isrs in case they
> > occur when characters are being received.
>
>Timer B interrupts are handled very quickly, no event writing, no
>more than six instructions each.
>
> > Side issue, but are you observing tCPT (now only 4mSecs) for the
> > flash write sequences? It can be difficult to meet and usually only
> > by ever writing 16-bit words not 8-bit bytes. Multiple segment erase
> > is also difficult to do without breaking down the erase cycle due to
> > tCMErase. However you don't report any flash corruption issues so you
> > may be ok.
>
>tCPT is only applicable to segment writes, I believe. I'm not
>familiar with tCMErase, can't find it mentioned anywhere.
>
> > Looks like the consensus to fix your site issues is probably just
> > activating the watchdog, which will fix pretty much all the issues
> > we've explored; unfortunately that won't help if you are being hit by
> > the brown-out problem, though it doesn't sound like your units lock
> > up forever so you may be ok there.
>
>Yep, I agree, going to make a big effort to get the Watchdog implemented.
>
>Thanks again.
>
> Start a New Thread

Hi Hugh

I'm glad you asked about the weirdness with the text layout. I don't
know why it's different in this case but if it helps throw any light on
the subject I initially found this forum via
http://www.embeddedrelated.com however
it soon became apparent that is just a portal to the Yahoo MSP430 group
here http://tech.groups.yahoo.com/group/msp430/
I've been doing my recent
reading and responding from the latter, which I also think explains why
my unprofessional looking Yahoo ID is appearing on my posts rather than
the name I initially registered with at the former, not that that user
name is much more professional. I promise I'm not deliberately doing
anything to your text! I'm responding using the rich text editor this
time so I'll see if that makes a difference.

Moving on, I understood that the URXS feature was primarily for when you
want to source BRCLK from the DCO and the DCO is normally off. Under
these circumstances, when the start edge of a serial character is
received, URXS causes an interrupt before the character has been
received and the DCO is started in time to allow the character to be
correctly received. I'd be reluctant to start using this feature now
considering the US13 bug description!

I see your point about reading U0RCTL once only, although as you pointed
out, the comms is very slow and the 2nd read of this register occurs
very early on in the ISR if the error bit is set. The comms is slow
because there are opto-isolators in the comms circuit and 2400bps is the
highest speed we can do reliably.

I see your point about tCPT now, I was working from Rev C of the family
user guide where the importance of this restriction is very far from
clear and doesn't seem to apply to byte or word write access of the
Flash. Having downloaded Rev F and had another look it is very clear.
I will adopt a RAM buffer for the event log and write the Flash in 64
byte blocks in the upcoming code revision. Thank you for pointing out
this very valuable information.

Regards

Rob
--- In m..., Hugh Molesworth
wrote:
>
> Hi Yoda
>
> Interesting comments, especially about URXEIE not being enabled; that
> of course re-opens the possibility of occasional garbage from the GSM
> modem being the cause of the overruns, particularly when you combine
> that with the URXSE bit not rejecting those GSM transmission burst
> glitches. It also gives a tilt towards a code review, since even the
> most experienced developers can overlook such an issue which might be
> quickly picked up by another pair of eyes. I understand your
> reluctance to post code here however, and many companies expressly
> forbid such posting.
>
> Registers such as U0RCTL could clearly have bits set after the
> initial read, which could affect the desired course of action. So it
> is good practice to read such a register just once, with a local copy
> then being used to derive individual actions. For example, in this
> case a second incoming character could fiddle with some of the error
> bits and the code could erroneously apply those newly fiddled bits to
> the first (good) character; unlikely in your case since the GSM
> interaction is so slow, but good practice nonetheless. Hopefully the
> error bits would then be correctly applied on the second loop through
> the isr. However there are no specific reasons applying to this
> register. I'm curious, by the way, why is the baud rate so slow? 9600
> is pretty safe using modulation bits and a 32.768kHz crystal, and the
> higher baud rate reduces the time in which the packet can be
corrupted.
>
> tCPT applies to every byte and word write. You cannot write 64 bytes
> to any flash block in any flash segment without violating this
> parameter and risking flash corruption. Here is an email I sent to
> this group some time ago discussing the issue:
>
> "All Flash fails in time. The variable aspect of this time to failure
> depends primarily on two factors, the "depth" of the programming and
> the ambient temperature in use. The "depth" is affected by both the
> issues we are discussing, since using too short a programming time
> leads to a marginal '0' (ie. a '0' that may in time become a '1') and
> exceeding Tcpt leads to a marginal '1' (ie. a '1' that may in time
> become a '0'). Since you've addressed the first, let me explain the
> second (Tcpt) by pasting in an email I sent to the User Group some
> time ago (you should verify these figures against the data sheet
> version relevant to the parts you are using, by the way):
>
> 'There has been a worrying change in the data sheet for the MSP Flash
> electrical specifications concerning parameter tCPT (Cumulative
> Programming Time). Once upon a time this used to be 3 mSecs for each
> block. In the current release it is 4 mSecs for each block but now
> additionally applies to ALL programming methods whether individual
> word/byte write or block write modes. This is bad news.
>
> Flash write time Tword is defined in cycles, nominally 35 cycles.
> At the shortest programming time (with max clock) 476kHz -> 2.1 uSecs
> per cycle. 35 cycles -> 73.5 uSecs. 4 mSecs contains just 54 of these
> 73.5 uSec periods ...
> At the longest programming time (with min clock) 257kHz -> 3.89 uSecs
> per cycle. 35 cycles -> 136.2 uSecs. 4 mSecs contains just 29 of
> these 136.2 uSec periods.
>
> This implies that even at the maximum clock only 54 writes are
> allowed to each 64-byte block before the Tcpt parameter is violated.
> This plays havoc with any schemes that use incremental sequential
> writes to minimise flash erase cycles. Not only that, but you can't
> even write 64 bytes to a 64-byte block, instead you have to write 32
> 16-bit words or some combination of bytes and words (or use block
> write mode from RAM).'"
>
> Another tip for the next design is to isolate the MSP430 LDO with a
> series schottky to the battery side of the input capacitor to limit
> power dips feeding through the LDO's poor high frequency PSRR. The
> MSP430 & LDO ground should only be common with the GSM modem at the
> battery terminal to minimise ground bounce. Of course using sealed
> lead-acid batteries also helps ...
>
> So another important question, why is my nicely typed text so
> irritatingly shortened to tiny lines in the posts when I read them
> back, when yours and others are not? Is it because I chose to use the
> "old style" without all the advertising down the right edge?
>
> Regards
> Hugh



Start a New Thread

Hi Rob,

All my posts seem to be changed to short lines, not just replies to
yours. Maybe someone else will jump in and point out if there is a reason.

Yes, I see your point that if you don't use URXS then US13 doesn't
apply, and optos explain the slow baud rate indeed. You can obviously
get faster optos - or use other isolation techniques - but perhaps
the ones you have are best for power/cost issues. Also as you
probably know all optos deteriorate over time as the LEDs gradually
loose brilliance, another cause of unexpected failure in the lifetime
of some products.

Regards
Hugh

On tCPT you can just write in 32-word blocks if you want to avoid

At 02:29 AM 11/26/2009, you wrote:

>Hi Hugh
>
>I'm glad you asked about the weirdness with the text layout. I don't
>know why it's different in this case but if it helps throw any light on
>the subject I initially found this forum via
>http://www.embeddedrelated.com however
>it soon became apparent that is just a portal to the Yahoo MSP430 group
>here http://tech.groups.yahoo.com/group/msp430/
> I've been doing my recent
>reading and responding from the latter, which I also think explains why
>my unprofessional looking Yahoo ID is appearing on my posts rather than
>the name I initially registered with at the former, not that that user
>name is much more professional. I promise I'm not deliberately doing
>anything to your text! I'm responding using the rich text editor this
>time so I'll see if that makes a difference.
>
>Moving on, I understood that the URXS feature was primarily for when you
>want to source BRCLK from the DCO and the DCO is normally off. Under
>these circumstances, when the start edge of a serial character is
>received, URXS causes an interrupt before the character has been
>received and the DCO is started in time to allow the character to be
>correctly received. I'd be reluctant to start using this feature now
>considering the US13 bug description!
>
>I see your point about reading U0RCTL once only, although as you pointed
>out, the comms is very slow and the 2nd read of this register occurs
>very early on in the ISR if the error bit is set. The comms is slow
>because there are opto-isolators in the comms circuit and 2400bps is the
>highest speed we can do reliably.
>
>I see your point about tCPT now, I was working from Rev C of the family
>user guide where the importance of this restriction is very far from
>clear and doesn't seem to apply to byte or word write access of the
>Flash. Having downloaded Rev F and had another look it is very clear.
>I will adopt a RAM buffer for the event log and write the Flash in 64
>byte blocks in the upcoming code revision. Thank you for pointing out
>this very valuable information.
>
>Regards
>
>Rob
>--- In m..., Hugh Molesworth
>wrote:
> >
> > Hi Yoda
> >
> > Interesting comments, especially about URXEIE not being enabled; that
> > of course re-opens the possibility of occasional garbage from the GSM
> > modem being the cause of the overruns, particularly when you combine
> > that with the URXSE bit not rejecting those GSM transmission burst
> > glitches. It also gives a tilt towards a code review, since even the
> > most experienced developers can overlook such an issue which might be
> > quickly picked up by another pair of eyes. I understand your
> > reluctance to post code here however, and many companies expressly
> > forbid such posting.
> >
> > Registers such as U0RCTL could clearly have bits set after the
> > initial read, which could affect the desired course of action. So it
> > is good practice to read such a register just once, with a local copy
> > then being used to derive individual actions. For example, in this
> > case a second incoming character could fiddle with some of the error
> > bits and the code could erroneously apply those newly fiddled bits to
> > the first (good) character; unlikely in your case since the GSM
> > interaction is so slow, but good practice nonetheless. Hopefully the
> > error bits would then be correctly applied on the second loop through
> > the isr. However there are no specific reasons applying to this
> > register. I'm curious, by the way, why is the baud rate so slow? 9600
> > is pretty safe using modulation bits and a 32.768kHz crystal, and the
> > higher baud rate reduces the time in which the packet can be
>corrupted.
> >
> > tCPT applies to every byte and word write. You cannot write 64 bytes
> > to any flash block in any flash segment without violating this
> > parameter and risking flash corruption. Here is an email I sent to
> > this group some time ago discussing the issue:
> >
> > "All Flash fails in time. The variable aspect of this time to failure
> > depends primarily on two factors, the "depth" of the programming and
> > the ambient temperature in use. The "depth" is affected by both the
> > issues we are discussing, since using too short a programming time
> > leads to a marginal '0' (ie. a '0' that may in time become a '1') and
> > exceeding Tcpt leads to a marginal '1' (ie. a '1' that may in time
> > become a '0'). Since you've addressed the first, let me explain the
> > second (Tcpt) by pasting in an email I sent to the User Group some
> > time ago (you should verify these figures against the data sheet
> > version relevant to the parts you are using, by the way):
> >
> > 'There has been a worrying change in the data sheet for the MSP Flash
> > electrical specifications concerning parameter tCPT (Cumulative
> > Programming Time). Once upon a time this used to be 3 mSecs for each
> > block. In the current release it is 4 mSecs for each block but now
> > additionally applies to ALL programming methods whether individual
> > word/byte write or block write modes. This is bad news.
> >
> > Flash write time Tword is defined in cycles, nominally 35 cycles.
> > At the shortest programming time (with max clock) 476kHz -> 2.1 uSecs
> > per cycle. 35 cycles -> 73.5 uSecs. 4 mSecs contains just 54 of these
> > 73.5 uSec periods ...
> > At the longest programming time (with min clock) 257kHz -> 3.89 uSecs
> > per cycle. 35 cycles -> 136.2 uSecs. 4 mSecs contains just 29 of
> > these 136.2 uSec periods.
> >
> > This implies that even at the maximum clock only 54 writes are
> > allowed to each 64-byte block before the Tcpt parameter is violated.
> > This plays havoc with any schemes that use incremental sequential
> > writes to minimise flash erase cycles. Not only that, but you can't
> > even write 64 bytes to a 64-byte block, instead you have to write 32
> > 16-bit words or some combination of bytes and words (or use block
> > write mode from RAM).'"
> >
> > Another tip for the next design is to isolate the MSP430 LDO with a
> > series schottky to the battery side of the input capacitor to limit
> > power dips feeding through the LDO's poor high frequency PSRR. The
> > MSP430 & LDO ground should only be common with the GSM modem at the
> > battery terminal to minimise ground bounce. Of course using sealed
> > lead-acid batteries also helps ...
> >
> > So another important question, why is my nicely typed text so
> > irritatingly shortened to tiny lines in the posts when I read them
> > back, when yours and others are not? Is it because I chose to use the
> > "old style" without all the advertising down the right edge?
> >
> > Regards
> > Hugh
>
>
> Start a New Thread