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: Unexpected NACK response from msp430f2274 during the BSL msp program download

Part Number: MSP430F2274
Other Parts Discussed in Thread: AM5746

In our design we use the msp430F2274 device, which we want to program every time the main CPU (AM5746) boots up. Thus, we run the msp430_bsl application on the main CPU (under Linux 5.4 OS), which we compile from the 'Sitara Linux Host for MSP430 UART BSL' folder provided by TI in the slaa760.zip file.

From the 'Sitara Linux Host for MSP430 UART BSL' folder we use the BSL application file-set provided in the UART_BSL_MSP430 sub-folder to compile the msp430_bsl application. For our initial test purpose of developing our custom msp430_bsl application we use a simple blinking LED msp430 program.

Originally, we have successfully tested our blinking LED msp430 program by downloading it to the msp430F2274 micro-controller via a JTAG programmer.

So, after we compile the msp430_bsl programming application we run manually it after the OS has booted and we observe the following: (refer to the main.c file)

  • The first attempt (line 168) in programming of the msp device always fails when trying to read the device ID (line 198).
  • This failure causes another attempt in executing the same code (line 168) and that time the programming succeeds!

An obvious question is: Why does this happen?

File 0_BSL_timing_overall.png contains the overall timing of the signals involved in the BSL programming, with references to the following files, providing a more detailed view of the overall timing diagram, which was collected by a logic analyzer:

  • File: 1_detail_bsl-entry_wrt-pwd_def.png
  • File: 2_bsl-entry_wrt-pwd_def_with_delayed_ack.png
  • File: 3_detail_delayed_ack_and_tx_data_block_nack.png
  • File: 4_tx_data_block_nack_rst_new_bsl_entry_with_success_seq.png

The Fist Attempt
------------------------
The signal sequence starts with a device reset (line 176), which is followed by the BSL entry sequence (line 185), which is followed by the HEADER (80) and ACK (90) characters exchange between the msp430_bsl application (MCU_BSL_RX) and the msp device (MCU_BSL_TX) signals.  In the further text this characters' exchange is marked as a SYNC event.

See 1_detail_bsl-entry_wrt-pwd_def.png for details.

Then the msp430_bsl application sends the 'RX password' command (line 187), to which the msp device responds with an ACK but only after a rather long time of ~450 ms!? (see 2_bsl-entry_wrt-pwd_def_with_delayed_ack.png). This is followed by a SYNC exchange.

Then the msp430_bsl application sends the 'TX data block command', trying to get the device ID.  However, at this point, the msp device responds with a DATA_NACK (A0), indicating an unsuccessful command execution. For details, see 3_detail_delayed_ack_and_tx_data_block_nack.png.

As the consequence of this failure, the msp430_bsl application then starts the second attempt of the msp device programming process.

The Second Attempt
-----------------------------
For details see 4_tx_data_block_nack_rst_new_bsl_entry_with_success_seq.png

Like in the first attempt, a new device reset is generated followed by the bsl entry sequence, which is followed by a SYNC event.

The msp430_bsl application sends the 'RX password' command again but this time the msp device responds with ACK with no delay, which is followed by a SYNC event as before.

Then the msp430_bsl application sends the 'TX data block command' again but this time the msp device responds correctly, by sending the device ID data!

From that point on, the remaining BSL programming sequence finishes correctly and the msp device starts properly executing its newly downloaded program.

Questions:

  • Is this is a normal behavior?
  • Could this behavior be avoided and have BSL programming done in only attempt?
  • What is the purpose of getting the device ID as it is not used in the code except for printing?
Attachments:
 - main.c
0552.main.c
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
/*
* Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the
* distribution.
*
* Neither the name of Texas Instruments Incorporated nor the names of
* its contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*/
//******************************************************************************
// Version history:
// 1.0 07/17 Initial version. (Nima Eskandari)
// 1.1 07/17 Added Comments. (Nima Eskandari)
//----------------------------------------------------------------------------
// Designed 2017 by Texas Instruments
//
// Nima Eskandari
// Texas Instruments Inc.
// August 2017
// Built with CCS Version: Code Composer Studio v7
//******************************************************************************
#include <stdio.h>
#include <stdbool.h>
#include <stddef.h>
#include <termios.h>
#include <time.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/types.h>
#include <string.h>
#include <gpiod.h>
#include <time.h>
#include "uart_if.h"
#include "bsl.h"
#include "config.h"
#include "gpiod_if.h"
#include "utils.h"
//*****************************************************************************
// MSP430 Image to use ********************************************************
//*****************************************************************************
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
- 0_BSL_timing_overall.png

 
 
- 1_detail_bsl-entry_wrt-pwd_def.png

 
- 2_bsl-entry_wrt-pwd_def_with_delayed_ack.png

 
 
- 3_detail_delayed_ack_and_tx_data_block_nack.png

 
 
- 4_tx_data_block_nack_rst_new_bsl_entry_with_success_seq.png
  • Hi,

    Thank you for the detail explanation. Please see this from SLAU319X:

    It is a normal operation. The reason why it operate like this is that:

    1. You already have code in it.

    2. In attempt one: Device check the password(you may send 32 byte 0xFFFF). It is not same as with the data saved in FFE0h to FFFFh

    3. Device do mass erase and the data saved in FFE0h to FFFFh to be all 0xFFFF.

    4. In attempt two: Device check the password(you may send 32 byte 0xFFFF). It is same as with the data saved in FFE0h to FFFFh

    5. Device response to other BSL command.

    Eason

  • Thank you for the explanation Eason!

  • Actually, I do have one question.

    When you say "Device do mass erase and the data saved in FFE0h to FFFFh to be all 0xFFFF.", do you mean that the msp430 device does mass erase on its own only because the password sent was incorrect?

    This would seem to be the case as the msp430_bsl application does not send the mass-erase command.

    Is the big delay in sending the ACK to the RX password due to the time required to mass-erase the device flash memory?

    Bud

  • Hi Bud,

    Sorry, I don't know the details of bootloader code. I'm not sure whether it will erase the code first then to send the ACK.

    If it takes about 1s, I think yes.

    Eason

**Attention** This is a public forum