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.

MSP430F2274: BSL UART Baud Rate

Part Number: MSP430F2274
Other Parts Discussed in Thread: MSP430F149, AM5746

I would like to know if a baud rate other then the 9600 baud may be used in BSL protocol.

Looking at the SLAU319AD – JULY 2010 – REVISED JUNE 2020 version of the document, I observe an apparent contradiction as follows:

  1. On page 7 of the document, section 1.4 UART Protocol is says:
    1. Baud rate is fixed to 9600 baud in half-duplex mode (one sender at a time).
    2. Also, in the note on the same page is says:
      Applying baud rates other than 9600 baud at initialization results in communication problems or
      violates the flash memory write timing specification. The flash memory can be extensively stressed or
      can react with unreliable program or erase operations.
    3. From this, one can conclude that only the 9600 baud UART date rate is allowed to be used.

  2. However, on page 9 of the document, the Data-Stream Structure table lists the Change Baud Rate BSL command, which allows the UART baud rate to be changed to 19200 or 38400 baud in addition to the default of 9600 baud.

I assume that both statement are applicable to different types/versions of msp430 device.

In my case, I use the msp430f2274 device.

So, can I apply the 38400 baud rate on the device I use?

Bud

  • Hi Bud,

    Yes. You can.

    Eason

  • Thank you Eason!

    I have one related question but I will ask it here as, for some reason, the "Ask a related question" button does not work.

    Based on 2.4.4.8 Change Baud Rate section of the SLAU319AD – JULY 2010 – REVISED JUNE 2020 version of the document, I can see that for my device (MSP430F2274) I should use the D1, D2 and D3 bytes of the BSL Change Baud Rate command to set up:

    • Processor frequency where:
      • D1 should carry the value of the DCOCTL register at offset 0x56
      • D2 should carry the value of the BCSCTL register at offset 0x57

    • Flesh timing generator frequency where:
      • D3 should carry:
        • 0x00 - for 9600 baud
        • 0x01 - for 19200 baud
        • 0x10 - for 38400 baud

    The question is how do I determine the values for D1 and D2 bytes if my msp4302274 device uses 12MHz clock generated by an external crystal and connected to pin 3 as CLK_12M_IN  and pin 2 as CLK_12M_OUT?  Please refer to the Attachment_0.pdf file.

    I have seen the Table 2-2. Recommendations for MSP430F149 in the document but I do not get how to calculate the values for D1 and D2.

    Regards,

    Bud

  • Hi,

    I think you can refer to this one:

    See from UG, it doesn't use external oscillator:

  • Hi Eason,

    I only now managed to try your suggestion above but it did not work.  Let me explain.

    We use msp430F2274 device, which pin 40 (P2.5/ROSC) is pulled down with an 100K resistor.  Please see Attachment_1.

    So I did try to change the baud-rate to 38400, using the values from the recommendation above but the BSL replies with NACK (0xA0), meaning something is wrong with the command data.  Please see Attachment_2.

    I have a feeling that some is wrong with the Basic Clock Module+ Registers' setting as I do not quite know what my current system clock frequency is.

    Do you have a suggestion how to go about solving this problem?

    Cheers,

    Bud

    Attachment_3.pdf

  • It is quite strange. As I check it will use internal clock. Can you help me to check the version of BSL using this command:

  • Hi Eason,

    I have tried to check the BSL version of my msp430F2274 device.  However, I do not get the expected response from the device.  I get only a NACK (0x0A)?!

    Here is trace capture:

    The message I send is: |80|1E|04|04|7F|7F|7F|7F|7B|E5|

    I do not know what could  wrong with that command, unless I wrongly calculated the checksum.  Could you check if it is correct?

    Regards,

    Bud

  • The calculated result on my side is 0xC0FA. Can you send this result for a test.

    I also not quite sure about whether this is right. The easiest way to check if the calculated tool you used is right is to try other command like mass erase.

  • Hello Eason,

    I will test your checksum.

    However, I am puzzled why is this happening.

    Let me share my BSL application code with you.  I obtained the code from the TI website.  Every C module has the Texas Instrument copyright from 2016 and the author is certain Nima Eskandari.  Please see the attached file bud_bsl_arch.tar.

    I have modified the original code as follows: (refer to main.c)

        Line 151: Commented out PinMuxConfig() as in my application the CPU (AM5746) pin-muxing has been already done by boot-loader.
        Line 156-158: Configured the necessary CPU GPIO pins using the gpiod library.
        Line 217-225: Perform the Mass Erase command first to reset the password to FFFF.

    With these modifications the program works fine.  It is interesting that, by omission, I implemented a new Mass_Erase() (line 229) function in the bsl.c module as I failed to notice that there was one there already, the MassErase (line508) :-)

    If you compare the two functions, you can see that they are effectively identical except for the DUMMY_BYTE, which in the original MassErase() function was hard-coded with 0 and in my implementation I used the value of 0x7F.

    The main point here is that in the line 248 I use the CalculateChecsum() function which is used for all other commands in the bsl.c module.  And as I said, my Mass_Erase() function works.

    Now, going back to main.c, you can see where I have tried to change the baud-rate:

    - After reset (line 176), I initialise the CPU UART, execute the BSLEntrySequence, then (in the commented out code) I send the Chage_Baud_Rate command (line 190).  Please refer to bsl.c line 187, where I build the sendBuffer and calculate the checksum the same way as in Mass_Erase(), send it and wait for the device response.  The respons comes immendiatelly but it is a NACK as I reported before.

    Then going back again to main.c, I (at line 206) I try to get the BSL version as you suggested.  I call the Tx_Bsl_Version() function implemented in bsl.c line 150.  As you can see I build the sendBuffer array, calculate the checksum the same way as before, send the command and wait for the ackResult. 

    However, for this testing I am not checking the returned value as I am monitoring the UART Tx & Rx lines so the function returns true back to the main.c where I just terminate the program.  However, the only response I get from the device is the NACK!?

    So, I am very confused here about what is going on.  I think I am consistently calculating the checksum using the same function, which is used throughout the code.

    Can you please review my code and try to see if there are some hidden traps in it.

    Regards,
    Bud

    ps - In the meantime I have tested your checksum and got the same result - NACK!  See the attached image.

  • I check your code, your CRC is right. Sorry, FRAM series device have different CRC calculation equation. You can also use this for check:

    I also check the BSL version, it is the right one 0x0202. But I can't find anything in the UG.

    As you can see mass erase, send password, read version are three unprotected command. I am not sure why you meet this problem. The only thing, I can think of is that the product doesn't support this function.

    I also check our system and can't find the source code...

  • I am back.

    Refer to this thread: https://e2e.ti.com/support/microcontrollers/msp430/f/msp-low-power-microcontroller-forum/985271/msp430g2755-correct-d1-and-d2-values-to-change-bsl-uart-baud-rate-to-38400/3642512#3642512

    It seems that the Baud rate change command is also protected.

    I think you can follow this follow to check if it can work. Wait for your good news.

  • Yes,

    I have seen it too and will be trying it soon.

    So the UG should be updated!

    Cheers,

    Bud

  • Hello Eason,

    Yes, I have tried with the password and, of course, it works.

    Cheers,

    Bud

**Attention** This is a public forum