This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F5437 UART Rx problem when flashing

Other Parts Discussed in Thread: MSP430F5437

Hi,

I am using MSP430F5437 and I am seeing some varying results. I have created code to download firmware upgrades, and this works fine on 3 our of the 4 boards that I have. The processor is running at 18MHz and the baud rate is 115200.

*************************************************************

Clock settings:

 UCSCTL1 |= DISMOD;
  UCSCTL0 = 0x0000;
 
  UCSCTL3 = 0x0020;
 
  __bis_SR_register(SCG0);
 
  UCSCTL1 = DCORSEL_7;                    // Select suitable range
 
  UCSCTL2 = 548 + FLLD_1;         // Set DCO Multiplier
  UCSCTL4 = SELA__REFOCLK | SELS__DCOCLKDIV  |  SELM__DCOCLKDIV ;
 

***************************************************

UART settings:

UCA1BR0  = 9;             
 UCA1BR1  = 0;
 UCA1MCTL = 0xC1;

***************************************************

Let me explain what I have done.

With the current code I have setup a test case were data is streamed to the device. All devices can receive hundreds of megabytes without giving me any failures. If I start copying this data from my incoming buffer to flash that is when I get into trouble. 

My flashing routine globally disables interrupts and uses polling on the UART Rx flag to check for incoming bytes (UCA1IFG & UCRXIFG). One test that I did was to replace flashing with delays to simulate the timing, and this test again showed no problems with receiving data. 

I have tried the 3 methods for flashing data. Byte, long word and even block write (128 bytes).

Byte writes are too slow, and even a 4K buffer (About 60K of code) overflows.

Long word writes are fine on 3 out of 4 boards.

Block writes does not seems to work at full speed (Inserting breaks between chars and it does work). Documentation is a little unclear here, as it seems no access to flash can be done while a block write is in progress.

******************************************************

Summarize:

My current code writes to flash 4 bytes at a time, while receiving data on the UART. 3 devices out of 4 that I are testing have no problems, while a 4th has any of these bits set: UCFE, UCOE, UCRXERR or UCBRK. If flashing is disabled, all boards can receive an endless amount of data without issues, it seems.

Any advice would be much appreciated.

Thanks,

Jorgen

  • Hi Jorgan,

    I realize you said the communication is perfect as long as you are not flashing, but I see something ominous.

    Erratum UCS10.

    Can you turn off the FLL just before this barrage of serial input and see if the symptom changes?

    Jeff

    (Edit - I am assuming in some code not posted you turn the FLL back on and then leave it on.)

  • Hi Jeff,

    Really appreciate you pointing me to that errata, that seems to be the fix I needed. I realize I did not have the latest version of the errata and so did not see this issue. 

    Thank you so much for the help!

    -Jorgen

  • Jorgen,

    So glad it helped you.

    Turning off the FLL is really a great work around for the problem, but watch out when turning it off.  It's possible that you could turn it off just after an instance of UCS10 occurs. That would leave the DCO off speed by up to 12%.

    Your code can identify this condition by examining the DCO and MOD settings left by the FLL after turning it OFF in a few consecutive ON-OFF cycles of the FLL.  If the FLL consistently picks the same (or close) settings, then those settings are correct and not affected by UCS10.  Otherwise, give the FLL a few more ON-OFF cycles.

    I'm sure there are other approaches, too, but you really do have to watch out for UCS10.

    Jeff

**Attention** This is a public forum