• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 79 subscribers
  • Views 792 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

MSP430F5438A: Update firmware image - using a .bin file retrieved from i2c and burned into flash memory

MSP430F5438A: Update firmware image - using BSL over I2C

steve spaeth
Prodigy 21 points

Part Number: MSP430F5438A

Our design is using the MSP430F5438A and we are using Code Composer Studio (CCS) for the IDE. 

The design requires firmware updates over I2C.  We have decided to use the TI provided BSL code (downloaded as a zip file) which contains the necessary files to get started.

The design is using UCB0 P3.1 and P3.2.  Below are the settings used to define the PORT and PINS.

BSL_Device_File.h

...

/* Device Specific Definitions */
#define MASS_ERASE_DELAY 0x8000
#define INTERRUPT_VECTOR_START 0xFFE0
#define INTERRUPT_VECTOR_END 0xFFFF
#define SECURE_RAM_START 0x1C00


#define TX_PORT_SEL P3SEL
#define TX_PORT_DIR P3DIR
#define RX_PORT_SEL P3SEL
#define RX_PORT_DIR P3DIR
#define RXD BIT1 /* RXD on P3.1 */
#define TXD BIT2 /* TXD on P3.2 */
#define DCO_SPEED 8000000
#define ACLK_SPEED 32768

#define UCZNCTL1 UCB0CTL1
#define UCZNCTL0 UCB0CTL0
#define UCZNI2COA UCB0I2COA
#define UCZNIE UCB0IE
#define UCZIV UCB0IV
#define UCZRXBUF UCB0RXBUF
#define UCZTXBUF UCB0TXBUF


/* Device Specific Definitions for commands and bugs */
#define DO_NOT_CHECK_VPE
#define CLEAR_LOCKIO

#define PROGRAMMING_FUNCTIONS
/* #define MEMORY_READING_FUNCTIONS */
/* #define OTHER_FUNCTIONS */

#ifdef PROGRAMMING_FUNCTIONS
#define SUPPORTS_RX_PASSWORD
#define SUPPORTS_MASS_ERASE
#define SUPPORTS_TOGGLE_INFO
#define SUPPORTS_RX_DATA_BLOCK
#define SUPPORTS_CRC_CHECK
#define SUPPORTS_LOAD_PC
#endif

...

Below is the code from PI_init() and Assigned register values after executing the code. 

BSL I2C Registers

Using a JTAG, I can download the BSL and step through the code (CCS debugger) up to the function PI_receivePacket() in file BSL430_PT_USCIB_I2C.c where the code is waiting for an I2C Start Condition (checking for changes in UCZIV).

BSL430_PI_USCIB_I2C.c

char PI_receivePacket()
{
RX_StatusFlags = RX_PACKET_ONGOING;

while (RX_StatusFlags == RX_PACKET_ONGOING)
{
switch (UCZIV)
{
case I2C_START_CONDITION_RECEIVED:
transmitPoint = 0; /* Start Condition Received */
rxdataPointer = 0;
break;

...

We are invoking the BSL using the code provided in the documentation:

__disable_interrupt(); /* disable interrupts */
((void (*)())0x1000)(); /* jump to BSL */

I even added an LED to light up when the BSL has been invoked...

Do the registers and code segments above look correct?

The issue:

To test the design we are using another MSP430F5438A to communicate to the BSL slave above over I2c using slave address 0x48.  For some reason we never get a Start Condition.  

  • I have tried adding another LED to toggle when the start condition is received, but nothing happens.
  • I have tried using two computers with 2 JTAGs one for the master and one to debug the BSL code using a breakpoint in the switch statements START condition, but nothing happens.

Note:  Before the BSL is invoked the 2 microcontrollers communicate over I2C without issue sending messages back and forth.  One of the messages calls the code to invoke the BSL.

If the register settings and code shown above are correct, what are some things I can check/verify next? 

Once I can get the BSL to recognize the Start condition - the rest will just be getting the protocol worked out (password, etc.) 

  • 0
    TI__Mastermind 49692 points

    Hi Steve,

    The MSP430F5438A supports UART BSL by default. What code are you using for this I2C implementation? I didn't see a specific reference in your initial post.

  • 0 in reply to James Evans
    Prodigy 21 points

    I created it using the provided F5438A UART code and the provided F522x I2C code.

    These are both part of the zip file found here:  https://www.ti.com/tool/download/MSPBSL_CUSTOMBSL430

  • 0 in reply to steve spaeth
    TI__Mastermind 49692 points

    Thanks for sharing the source. That's helpful. Is there a chance that the code is waiting on a BSL entry signal from the host? I'm assuming that is checked after the reset is issued.

  • 0 in reply to James Evans
    Prodigy 21 points

    We know the BSL is invoked because the application code (in address 0x5c00) uses the 2 lines of code to jump to the BSL and during initial invocation an LED lights up when the BSL has been invoked... 

    I may not understand your question, "Is there a chance that the code is waiting on the BSL entry signal from the host?" because with the LED being illuminated on invocation, we are certain the the BSL is executing.  In addition, as mentioned above, JTAG was used to step through the code up to the point were it is waiting on the I2C start condition.

  • 0 in reply to steve spaeth
    TI__Mastermind 49692 points

    Thanks for clarifying. The PI_init() code seems to be configured properly. Since I2C communication works fine outside of the BSL, I assume that means you are using pullup resistors on the I2C lines between the devices.

    If the start condition is not received in your PI_receivePacket() function but I2C communication works fine between the two devices in the application code, then I would compare the clock and I2C module settings to make sure they match.

    Also, I would add code to turn on an LED in the I2C_START_CONDITION_RECEIVED case in the PI_receivePacket() function. I would do some testing without active debug sessions on both I2C host and I2C target. For the I2C target, I would add code to invoke the BSL when a button is pressed. Ideally, the I2C target code would then enter PI_receivePacket() and halt in the while() loop until the start condition is received. For the I2C host, I would add code to send the BSL commands after a button is pressed.

    If that doesn't work, then I would go back to running an active debug session on the I2C target to check the value of UCxIV, which should give you a hint about the issue.

    Also, be mindful there are several USCI errata for this device. See the device-specific erratasheet for more details.

  • 0 in reply to James Evans
    Prodigy 21 points

    Thanks for some additional ideas to resolve the issue; as soon as the issue is resolved, I will post what the issue is for the community.

**Attention** This is a public forum