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.

MSP430FR5969-SP: Initialization of BSL via firmware inconsisteny/failuer

Part Number: MSP430FR5969-SP
Other Parts Discussed in Thread: MSP430FR5969, MSP-FET

MSP430FR5969 Software/Firmware Initialization of BSL

Hello there,

I am working with the MSP430FR5969 and trying to invoke the BSL using the firmware function found in the datasheet. I am also using the MSP-FET to act as the go between the BSL-Scripter and MSP430FR5969. I am using the UART A0 Port for BSL programming. 

My issue is that I cannot get the firmware invocation to work reliably. The hardware invocation is bulletproof and can get that to work every time, however it is not the method I can use to program the device in the field and therefore need to use firmware method to do this. The firmware invocation seems to work one out of every ten times, if that. It’s extremely unreliable and impossible to duplicate back to back.  I’ve tried multiple things, and as of right now the most reliable method is setting the MCLK to 1 MHz and still I have issues.

Below is my code. I’ve been so frustrated with this that I just have the device jump right to the bootloader after I set my clocks.

 

 

Here is my scripter text file

Order of operations.

  1. Program the MSP430FR5969 using the MSP-FET using Two-Wire Programming
  2. Disable/disconnect from the debugger
  3. Pop over to the scripter and run my script.
  4. Mass confusion ensues.

  The error messages I see via BSL-Scripter are:

  1. Unknown ACK – which I understand to be a bad acknowledgement and that the BSL is not being invoked. This is for both the wrong and correct password RX transmissions

 

  1. BSL Password is correct! – I get this sometimes when I pass the wrong password through. Usually after multiple attempts of using the scripter. Which is odd because the password is intentionally wrong.

 

  1. BSL is locked – This error makes sense for when the wrong password is passed through but the chip doesn’t go jump to BSL. I see this with the correct password and when I attempt to upload my hex file via the BSL-Scripter. I did notice something however, its that when I send the wrong password and I get the BSL is locked error more often than not it seems to work. Odd and inconsistent, may mean nothing at all.

 

 

  1. Invalid header – not sure what this is, need to dig around more. Is usually paired with an Unknown Command error.

 

 

When it does decide to behave this is the log from the Scripter

 

 

My question is:

What am I missing? Do I need to set up my CLK’s differently? Do I need to do something with the UART port as well? Why is it so inconsistent? Do I need to clear my configuration registers?

The documentation is of little to no help either, all the documents say is use   and then reference another document which references another document and its all just one big run around.

If anyone has any suggestions please let me know. Thank you for taking the time to read and help! I really do appreciate it

  • Hi Stefan,

    Not sure why you having so much trouble.  According the SLAU550, the BSL for this device operates at 8MHz. I'm assuming the BSL configures its 9600 baud rate based on this so I would stick with using 8MHz?  Other than that you shouldn't have to do anything for the UART.  I see you are using 9600, which is correct.

    Do you have an oscilloscope or logic probe to capture the UART RX/TX signals and confirm they are running exactly at 9600 bps?

    If BSL scripter shows a message "Unknown ACK value", this usually indicates you are not connected to the BSL or you lost communication with the BSL.

  • Hi Dennis,

    Thanks for taking the time to respond and help out. 

    In past attempts I was running at 8Mhz, and still have an issue. I was under the impression that once you invoke BSL the BSL sets up the CLK and UART. However, that assumption (at least for the set up of the clock was wrong). One needs to set up the M_CLK to 8MHz before jumping to BSL either via hardware or software invocation. What clock source does the BSL use, it uses MCLK and I'm assuming that's set up to the DCO? This would make sense, since the BSL isn't aware of any XTALs. 

    Anyways, to answer your question about the UART being set up correctly, it is. I have attached a capture of my scope. One thing I did notice is that sometimes the FR5969 is not transmitting anything back (like its ACK) to the Scripter when it is in the BSL, and that is throwing the bad ack error.  What I have done is go to a RocketBoard with the FR5969 on it and I still run into the same issues. It's just not working. It's like something is not being set up correctly. I do go into BSL because the device doesn't respond to anything until reset. 

    Blue - RX

    Green - TX


    this oscope capture (above) was when i try writing the bad password to the device. No ACK. 

    The above oscope capture is when i try to write the correct password to the device. I get a not so perfect TX response. 

    Not sure if the BSL is setting itself up correctly? 

    Were you able to find anything regarding the other 3 error messages?

    Thanks,

    Stefan 

  • Hi Stefan,

    I haven't had much luck tracking down the error messages.  Let me try to set this up in HW and see if I can duplicate your issue.

  • Dennis,

    Thank you. So I seem to have narrowed down the issue to the MSP-FET. If just use a normal USB to UART FTDI cable the scripter seems to work on the second try when I go to upload code via UART and the BSL. I don't know what the MSP-FET does but it doesn't seem to work at all for BSL programming via software - for hardware invocation it works like a charm. To describe my new test up I have outlined the steps below. 

    1. I flash my test firmware to the board via CCS and the MSP-FET using Spy-bi-wire.

    2. Unplug the MSP-FET from my computer, plug in regular USB/UART FTDI cable and attach TX/RX to 2.0/2.1

    3. Run the scripter. Get a bad ACK (0xF7) on correct password

    4. Run the scripter again, get a good ACK (0x00) on correct password. and then it programs it.

    Do you know why I have to run the scripter twice in order for it to work on the second try? 

    As for the other error codes I managed to teach myself how to use the decode function on my OScope and was able to match the hex values to the error hex values listed in the documentation. 

  • I forgot to add my OScope screen captures for the half-solution I found

     

    Above: First attempt at running scripter - Bad ACK was 0xFC not 0xF7

    Above: Second attempt - Good ACK (need to calibrate my probe I know)

  • Hi Stefan,

    Not exactly sure why 2 attempts are needed. Between steps 2 and 3, do you cycle power or reset the MSP430?

  • Hey Dennis,

    No I do not. It is a very interesting quirk. 

**Attention** This is a public forum