MSP430F5437A DIE revision changed UART A1 behavior

BSL is factory programmed in Flash. TI could have changed it between batches. Dump the BSL Flash and compare them.

Ben,

There were significant errata fixes between Rev E and Rev F/H.  One in particular that is causing a lot of people issues is UCS6, which states:  USCI source clock does not turn off in LPM3/4 when UART is idle.

What we see happen is the code is written for a Rev E part and depends on the USCI source clock (typically SMCLK to get 115200 baud) when the device is in LPM3/4.  Then, when they get the newer silicon that is not impacted by this erratum, their firmware quits working.

I suggest looking into your firmware to see if you are dependent on whatever clock you are sourcing the USCI from while in LPM3/4.

Mike

Thanks for the response, but the BSL is our own fault :)

The BSL code is programmed on by the distributor. Both the BSL code and the production code use the SMCLK for the UART clock source, and the biggest difference that I can see is that the BSL code polls the UART while production is interrupt driven. At this point it appears the interrupt is never getting called because I added a LED toggle which is not occurring.

Hi Mike,

Thanks for the information. We looked at UCS6 when we were developing the code originally because we were porting the code over from a 2618 and saw an alarming increase in power consumption. The UART uses the SMCLK as the clock source. I believe that our solution was to set the UART dormant to conserve power. We could do this because there is a time limit to how long the UART would be active and after that time it was shut off.

Unfortunately there are no comments in the code indicating what workarounds were employed for the USCI and UCS erratum, so I'm trying to follow what breadcrumbs I can.

Can you identify what particular UART settings would work with the older REV E but cause the REV F/H to stop working?

Thanks

Ben Willis said:

Can you identify what particular UART settings would work with the older REV E but cause the REV F/H to stop working?

Now the clock is switched off. The UART onyl slwitches it on when it detects a start bit, but the DCO needs some time to come up. So when the first DCo clock pulse arrives, some µs have passed and the UART has probably missed msot or all of the start bit or more, dependign on baudrate. This results in a framing error and no byte is received.
The advantage is that power consumption is reduced in LPM3 where it wasn't on olde rsilicon.

So if you are entering LPM3 or 4 while the UART is waiting for incoming data, change this to LPM0.

btw: LPMx is jsut a combination of bits with ascending 'effect'. But you may as well combine the settings for LP2 with the OSCOFF bit that disables XT1, or switch off ACLK but leave SMCLK active. These "low power modes" doen't have a number, but might be still useful in some situations.

Ben,

I just got off the phone with Michael and we both think that the errata change referenced above looks to be the root of your issue.

1. To test his theory try placing the MSP into LPM0.  This will keep enable the DCO/SMCLOCK active and the UART should be able to recieve information without having to wake the clocks in the IRQ handler.

2. Since in the previous revision of the MSP the DCO never powered down in LPM>1 the SMCLOCK was continuously sourced and the UART was active UART even in LP Mode. To fix this issue you will need to properly wake up your DCO and SMCLOCK in the IRQ handler so that the UART is capable of receiving messages beyond the initial wake up interrupt

Thank Mike!

Ben,

To elaborate a little more on what Michael Questo said, in your firmware, you are probably sourcing the UART clock from SMCLK, which is probably sourced from DCOCLK.  In Rev E devices, erratum UCS6 prevents the UART clock's source from getting turned off, which means DCOCLK is kept running.  Then, while you are receive a start bit on the next UART byte, the DCOCLK is already running, and everything works normally.

The issue with the newer Rev parts and the fixed erratum is exactly what Jens-Michael Gross said.  "Now the clock is switched off. The UART onyl slwitches it on when it detects a start bit, but the DCO needs some time to come up. So when the first DCo clock pulse arrives, some µs have passed and the UART has probably missed msot or all of the start bit or more, dependign on baudrate. This results in a framing error and no byte is received."

There are a couple of solutions here.  The first, as Jens-Michael Gross said, is to run the MSP430 in a mode that does turn off the DCOCLK that ultimately sources the UART Clock when you could get UART communication.  This is the first test that Michael Questo is suggesting of running the system in LPM0 instead of LPM3.

Another solution is to slow down the buad rate to something that can be sourced from a clock that can remain active in the LPM mode used (likely LPM3) such as ACLK at 32768Hz.  You can then receive one byte and use that to start up the DCO again to run at a higher baudrate (after the DCO has fully started) if you want faster communication for the rest of the transaction.  This would also allow you to keep the device in LPM3 while waiting on the UART to start communicating, then switch to LPM0 during communication (to not turn off the DCO with the faster baudrates), then switch back to LPM3 (and the lower baudrate) after the communication is done and the firmware is waiting on the next packet.

Mike

Michael Questo said:

1. To test his theory try placing the MSP into LPM0.  This will keep enable the DCO/SMCLOCK active and the UART should be able to recieve information without having to wake the clocks in the IRQ handler.

I changed the code to use LPM0 instead of 3 and now the serial is working!

Previously I had modified the Port A1 ISR to toggle an LED whenever it was called and I never saw it come on. Is the problem that the DCO is not starting up quick enough for the UART to pick up the start bit so it never calls the ISR?

Thanks,
Ben 

Ben Willis said:

Is the problem that the DCO is not starting up quick enough for the UART to pick up the start bit so it never calls the ISR?

Exactly.  Because the DCO is not turned off in LPM0, the UART module has it's clock source readily available to start timing when it should sample the RX line.  But when you are in LPM3, the DCO is turned off, then when you get a start on the RX line, the UART module starts the DCO back up again, but it takes some time to settle and misses one or more of the bits.

Mike