• State Answer Suggested
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 2154 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Problem with BSL on CC430F5137: MSP is not detection header and responses with wrong baudrate

Christian Frick
Prodigy 60 points

Hello

We are having problems while implementing an algorithm for the MSP Bootstrap Loader. Entering the BSL seems to be working due to the fact that the MSP is responsing on the UART. But it can't detect the header (0x80) and responses with the message code 0x51. Unfortunately this response is at a baudrate of about 6400 instead of the expected 9600.

Are there any know problems with this device or am i doing something wrong? I have found an interesting post at http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/18565.aspx from Abraham Fechter:

"Although, the bootload routines would not communicate at the documented 9600 baud. Rather, the baud rate was about 6666, verified with an Oscope. I assume that this was due to the internal oscilator not being trimmed since I have the "X" version."

Because we are not using a "X" version i expect a trimmed internal oscillator. Is it possible, that it is not trimmed or the calibration overwritten?

Thanks a lot!

Christian

  • 0
    Guru 227245 points

    The 5x series does not have factory-stored calibration values for the internal DCO clock, so it cannot be overwritten.

    It has instead a factory-trimmed (+-3.5% over whole temperature range) 32768Hz oscillator and an FLL hardware that adjusts the DCO per default for 1MHz based on this oscillator.

    Normally, the adjustment is good enough so I can do a 115200Bd connection derived from a 16MHz clock stabilized by this 32768Hz oscillator.

     It is possible (but shouldn't happen) that the factory trimming is faulty. You can check by flashing the MSP through JTAG with a software that sets ACLK to REFO (the 32768Hz oscillator) and enable output of ACLK to a pin.

    9600Bd is at the very edge of what's reliable with an accurate oscillator (0 error), but there shouldn't be a 33% difference in the baudrate. (but the individual bits can be quite a bit off - literally)

  • 0 in reply to Jens-Michael Gross
    Prodigy 60 points

    Thank you for your answer. We have tested the internal clock and it seems to be correct.

    Fortunately the problem could be localized:

    If a command is sent within 26 ms (with the tested device - could be different in other devices / types) after entry sequence, the BSL seems not to be ready and responses as already described: 0x51 with a corrupt baudrate.

    But if you wait for more than 26 ms between the entry sequence and the first command, than everything is working alright.

    I couldn't find any specified minimum time between entry sequence and first command in the datasheets or application notes. Did i overlook this specification or could it be possible that this isn't mentioned in the official documents?

  • 0 in reply to Christian Frick
    Guru 227245 points

    Based on your observation, I'll make an assumption:

    The BSL timing is derived from DCO rather than REFO. The default settings cause DCO to be stabilized a 1MHz by the FLL based on REFO. But this takes some time (very well these 26ms you observed), as the DCO does start on tap 0 while the one that comes closest to 1MHz is tap 3..20. And it takes about 1ms to advance one tap.

**Attention** This is a public forum