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.

MSP430F5438: BSL: Writing to flash memory or restricted memory

Part Number: MSP430F5438
Other Parts Discussed in Thread: MSP-FET, MSPBSL, UNIFLASH

Hello,

I am currently trying to use the BSL to reprogram a microcontroller via UART.

I am trying to use the RX Data Block to Address command and am sending this test to see if it works:

0x80 0x0B 0x00 0x10 0x5C 0x00 0x5C 0x02 0x5C 0x04 0x81 0x00 0x00 0x5C 0x74 0xF8

As you can see above, I am attempting to send 4 bytes (0x81 0x00 0x00 0x5C) to address 0x5C00.

 

Whenever sending the above command however, the BSL sends back the error message "Byte Write Forbidden. This error is returned when a byte write is attempted in a flash area." I have looked a bit through the forums and have attempted to unlock this flash area by changing the SYSBSLC register to 0x07 but keep ending up with the same result. Below is a screenshot of the datasheet entry for SYSBSLC Register:

Thank you for the help as always,

Nick Nguyen

  • Hi Nicholas,
    I have a few questions on your setup.
    Could you please let us know the details about the tool chain you're using for your test?
    You're also starting kind of in the middle of the whole activity. So could you please let me know the flow you're applying? e.g. how are you invoking the BSL, what are the steps, you execute before you hit the point you're describing?
    Also a basic question. Do you know about our main landing page for BSL related MSP430 topics (http://www.ti.com/tool/mspbsl) and are you familiar with the FLASH MSP BSL User's Guide www.ti.com/.../slau319x.pdf

    Best regards
    Peter
  • Hello Peter,

    I am using an FTDI cable to communicate with the MSP430F5438 on p1.1 and p1.2 which are the RX and TX line for the BSL.  I am using a MSP-FET UIF in order to flash programs onto it. In my program, I have use the software invokeable command to jump the BSL after a button is pushed.  I am currently using Realterm to send and receive data for the BSL.

    I am familiar with slau319x.pdf (BSL for Flash Devices).  Also, the ti.com/tool/mspbsl link seems to not work.

    I hope this clarifies my tool chain.

    Thank you,

    Nick

  • Hello Nick,
    many thanks for your additional information.
    I have a few questions on your statements.
    1. You stated "Also, the ti.com/tool/mspbsl link seems to not work." I just tested the link, and it works. Thus please let me know, whether this was just a typo in your post or you're really experiencing issues with it.
    2. You stated, you're using an FTDI cable for the RX/TX communication. This is not a mistake, but as you later stated to be using an MSP-FET I just wanted to bring to your attention, that the MSP-FET has an virtual COM port on the 14pin header. Please check the HW Tools User's Guide for further details www.ti.com/.../slau278ae.pdf . So there is no need to use another HW than the MSP-FET.

    Did you check, whether the MSP430 is receiving the pattern you're transmitting correctly?

    Best regards
    Peter
  • Hello Peter,

    Thank you for your help. I appreciate your time.

    1. The link seems to be fixed as it was not working yesterday for me.

    2. To further explain my connections, the MSP-FET does indeed have UART capabilities, however I would like to be able to control my code using the MSP-FET UIF paired with Code Composer Studio for debugging purposes.  Also, the pins to which the MSP-FET UIF are connected to in order to flash code onto the device are not the BSL's RX and TX line which are TA0.0 and TA0.1 thus leading me to use the FTDI cable.

    I don't know if this answers your question, but I am receiving messages from the BSL correctly.  The change baudrate, return buffer size, return bsl version, and entering in the password for the BSL all return the correct messages.

    Here are message packets I am sending to the BSL. I am receiving packets back that confirm that my message packets are working.

    The problem I am still having however is that I cannot seem to input bytes into flash memory of the MCU. The message I had tried to send was just a test to see if the inputting data would work. This is the data i tried to input below:

    0x80 0x0B 0x00 0x10 0x5C 0x00 0x5C 0x02 0x5C 0x04 0x81 0x00 0x00 0x5C 0x74 0xF8

    ... =  Address bytes. The low, middle, and upper bytes, respectively, of an address

    ... = Databytes 1 through n

    Here is a snippet of the portion I am trying to send:

    The message I am receiving can be seen above in my post.

    If this did not answer "Did you check whether the MSP430 is receiving the pattern you're transmitting correctly", please let me know.

    Thank you again for your help!

    Sincerely,

    Nick

  • Hi Nick,
    sorry for my late response. I had to address other topics. Many thanks for the additional clarification. Yes, this answers my question on the correctness of reception to great extent. I understood, you're receiving the packets and commands you're mentioning. In addition I was trying to understand, whether by debugging, e.g. like setting the USCI module up like in the BSL case you do receive the sequence of bytes you're transmitting in case of your attempt to write to FLASH correctly.
    But as we looked deeper into your sequence, we on one hand found an error in your data packet, and on the other hand a bug in our documentation, though you did not run into it. (just in case in SLAU319V table 2 there are two errors in the commands CMD for RX data block should be 10, and CMD for RX password should be 11).
    But coming to the error in your sequence,
    With data
    @5c00
    81 00 00 5c

    is: : 0x80 0x0B 0x00 0x10 0x5C 0x00 0x5C 0x02 0x5C 0x04 0x81 0x00 0x00 0x5C 0x74 0xF8
    should be: : 0x80 0x08 0x00 0x10 0x00 0x5C 0x00 0x81 0x00 0x00 0x5C CSL CSH
    H LL LH CM AL AM AH Data …….

    Please try this, and let me know if it works.
    The other general recommendation, when hitting such issues, is to e.g. try using UNIFLASH. What I mean is trying to run a programming sequence by BSL with this tool, and record the sequence with a scope or logic analyzer, comparing it with your own. This way you can obtain a reference on the required sequence.

    Best regards
    Peter
  • Hello Peter,

    I have tried your packet and it seems to still not work.  I believe the Table 2 in SLAU319V  is for the BSL Commands for the 1xx, 2xx, and 4xx families.  I am using a MSP430 from the 5xx family in which I have refered to Table 5. UART Protocol Interface and Table 9. BSL Core Commands.  I will be sure to try UNIFLASH tomorrow as you have suggested although I do not have access to a scope or logic analyzer at this time..

    On a side note along with my current on going issue, I was looking at Table 24.

    I was wondering what function this was referring to as it only says "this function".

    Thank you for your continual help.

    V/r,

    Nick

  • Hi Nick,
    the only suspicion we have at the moment is the calculated checksum for the failing case might be wrong, though for the other working portions the checksum calculation seems to work.
    Apart from that, we're trying to reproduce the problem, but this might take some time. I'll keep you updated on this.

    Best regards
    Peter
  • Hello Peter,

    Thank you for your help thus far. I have figured out what I had done wrong.  I had messed up the endianness of my addresses.

    @5c00
    81 00 00 5C B1

    old wrong one: 0x80 0x0B 0x00 0x10 0x5C 0x00 0x5C 0x02 0x5C 0x04 0x81 0x00 0x00 0x5C 0x74 0xF8

    new fixed one: 0x80 0x0C 0x00 0x10 0x00 0x5C 0x02 0x5C 0x04 0x5C 0x81 0x00 0x00 0x5C 0xB1 0xF7 0x60

    I had bolded the portion I had fixed.  I had also added one more byte to be sent just for the face of finding a "middle byte" for the AL AM AH portion of the message.

    Upon changing this, I was able to receive an Operation Successful response back.

    edit: I had only realized this when looking at the message you had suggested and noticed you had different "endianness" when sending the address.

    Thank you for your time!

    Nick Nguyen

**Attention** This is a public forum