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.

CCS/MSP432P401R: MSP432 100-pin to 64-pin transition

Part Number: MSP432P401R

Tool/software: Code Composer Studio

Hi,

We have encountered a strange issue programming a custom board based on the 64-pin MSP432P401RIRGCR. Initial development of the firmware was completed on the 100-pin MSP432 launchpad with no issues. After receiving proto boards, we confirmed the boards were functional by programming them using CCS with a standard TI example: gpio_toggle_output_MSP_EXP432P401R_nortos_gcc

However, after we booted our custom firmware running TI-RTOS onto the proto boards, we have seemingly bricked the micro and are unable to factory reset the devices.

The sequence of steps that led to the failure were:

1. Custom firmware was loaded via CCS debug option

2. After successfully being programmed, standard resume / terminate options in CCS pop up as normal, indicating program is ready to run.

3. After selecting resume, we get the error shown below in the console after a few seconds

At this point the board cannot be factory reset by the standard procedure. Once you select the Target Configuration (Launch selected configuration) -> show all cores and then select "Connect", you get the following error:

However, when you test the JTAG connection via target configuration, the JTAG integrity test succeeds which means the XDS110 still sees the MSP432.

As far as I am aware, there are no special steps required within the project to port the firmware from a 100-pin to a 64-pin MSP432. Is this correct? Both the launchpad and the MSP432P401RIRGCR have the same amount of Flash and RAM.

I have also attached our MSP_EXP432P401R.c/MSP_EXP432P401R.h files which maps the hardware on the custom board to our hardware abstracted firmware.

7178.MSP_EXP432P401R.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) 2015-2018, Texas Instruments Incorporated
* All rights reserved.
*
* 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.
*/
/*
* ======== MSP_EXP432P401R.c ========
* This file is responsible for setting up the board specific items for the
* MSP_EXP432P401R board.
*/
#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
#ifndef DeviceFamily_MSP432P401x
#define DeviceFamily_MSP432P401x
#endif
#include <ti/devices/DeviceFamily.h>
#include <ti/drivers/Power.h>
#include <ti/drivers/power/PowerMSP432.h>
#include <ti/devices/msp432p4xx/inc/msp.h>
#include <ti/devices/msp432p4xx/driverlib/rom.h>
#include <ti/devices/msp432p4xx/driverlib/rom_map.h>
#include <ti/devices/msp432p4xx/driverlib/adc14.h>
#include <ti/devices/msp432p4xx/driverlib/dma.h>
#include <ti/devices/msp432p4xx/driverlib/gpio.h>
#include <ti/devices/msp432p4xx/driverlib/i2c.h>
#include <ti/devices/msp432p4xx/driverlib/interrupt.h>
#include <ti/devices/msp432p4xx/driverlib/pmap.h>
#include <ti/devices/msp432p4xx/driverlib/ref_a.h>
#include <ti/devices/msp432p4xx/driverlib/spi.h>
#include <ti/devices/msp432p4xx/driverlib/timer_a.h>
#include <ti/devices/msp432p4xx/driverlib/timer32.h>
#include <ti/devices/msp432p4xx/driverlib/uart.h>
#include <ti/devices/msp432p4xx/driverlib/wdt_a.h>
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1258.MSP_EXP432P401R.h

So far, we have encountered the same bricked board failure mode with 2 proto-boards. Our schematic is based on a previous custom designed board we made with the 100-pin micro and can be provided via IM.

Please let me know if you have any suggestions how to proceed?

Thanks,

Robert

  • Hello Robert,

    Apologize for the delay! I will look into this and try to get back by end of tomorrow.

    Thanks,

    Sai

  • Additional information:

    Just attempted to run TI-RTOS example: timerled_MSP_EXP432P401R_tirtos_ccs

    This program bricked the board as described above.

  • Hi Robert,

    What version SDK and CCS are you using?

    Could you also share the board.h source file?

    Exactly which TI drivers are you using in your application?

    BR,

    Seong

  • Hi Seong,

    SDK:  simplelink_msp432p4_sdk_3_10_00_08

    CCS:  Version: 9.0.0.00018

    I have attached a simplified version of the timerled_MSP_EXP432P401R_tirtos_ccs project which contains the Board.h file you requested. When programming the board with this simple example, I set some breakpoints while testing a new board and our custom board did not make it past line 64 in main_tirtos.c which pinpoints the error to Power_init():

    Board_init();

    The following error occurred:

    CORTEX_M4_0: GEL Output: Memory Map Initialization Complete
    CORTEX_M4_0: GEL Output: Halting Watchdog Timer
    CORTEX_M4_0: WARNING   : On MSP432P401R hitting a breakpoint cannot be detected by the debugger when the device is in low power mode.
                             Click the pause button during debug to check if the device is held at the breakpoint.
    CORTEX_M4_0: JTAG Communication Error: (Error -613 @ 0x0) The target indicates that it is busy.  Either try the SWD request  again, or abort the transaction. (Emulation package 8.1.0.00005) 
    CORTEX_M4_0: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging
    

    Screenshot also attached:

    Board.h:

    #ifndef __BOARD_H
    #define __BOARD_H
    
    #define Board_MSP_EXP432P401R
    
    #ifdef __cplusplus
    extern "C" {
    #endif
    
    #include <ti/drivers/Board.h>
    
    #define Board_initGeneral()     Board_init()  /* deprecated */
    
    #include "MSP_EXP432P401R.h"
    
    #define Board_GPIO_LED_ON           MSP_EXP432P401R_GPIO_LED_ON
    #define Board_GPIO_LED_OFF          MSP_EXP432P401R_GPIO_LED_OFF
    #define Board_GPIO_LED0             MSP_EXP432P401R_GPIO_LED1
    #define Board_TIMER0                MSP_EXP432P401R_TIMER_T32_0
    
    
    #ifdef __cplusplus
    }
    #endif
    
    #endif /* __BOARD_H */
    

    At this point the custom board is bricked and cannot be programmed or factory reset.

    Regards,

    Robert

    timerled_MSP_EXP432P401R_tirtos_ccs.zip

  • Robert,

    BR,

    Seong

  • Robert,

    Thank you for sharing the schematic. While some boards can get away with not having a pull resistor, it is always good practice to have a pulldown resistor on the JTAG TCK pin as per ARM guidelines. This is so that at power up, it does not create a fake TCK pulse. 

    Also, see this additional related thread: https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/508198

    BR,

    Seong

  • Hi Seong,

    Thank you for reviewing the schematic. I  added the pull down resistor on JTAG TCK pin and that did not work.

    • We are currently populating a board without any additional peripherals to minimize any potential issues from other components
    • We have attempted all override methods as described in section 5.8.6 without success - however, the XDS110 can still see the MSP432 as described in my first post and also shown again below
    • The threads you linked do not provide any new untested information.

    Regarding the link you sent:

    MSP432 Error Factory Reset - MSP low-power microcontroller forum - MSP low-power microcontrollers - TI...

    e2e.ti.com
    hi guys, I got really silly with my launchpad. I couldn't connect to my 2 MSP432 launchpads anymore. I tried the reset of the firmware with the xdsdfu tool that

    After step 7, we are still able to successfully run Test Connection (in both JTAG/SWD Modes)

    At step 8 (Connect only to the Non-Debuggable Devices > DAP) we get the following error after selecting Connect Target

    This is strange because the XDS110 can see the MSP432 JTAG but cannot program the board.


    I am under the impression that this is a TI-RTOS issues since the board bricks upon running the Power_init() function.

    Best,

    Robert

  • Robert,

    Thank you for the update. I'm not sure if this is a TI-RTOS issue as I can't think of anything that TI-RTOS does that would cause this. I've reached out to the tools team regarding this issue and will get back to you as soon as I hear back from them. 

    BR,

    Seong

  • Robert,

    From the subject matter expert:

    Eons ago a version of the SimplelInk software was bricking the MSP432 launchpads due to a missing “retain” keyword that failed to properly program the reset vector. Given the software seems to load and run for the first time, this is consistent with the behaviour of yore, where the first load did not necessarily go through the complete cold reset of the device.

    The solution at the time was to issue a mass erase on the MSP432. Check:

    https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/460430/1663082#1663082

    Hope this helps,

    Seong

  • Within the TI-RTOS sample project (timerled_MSP_EXP432P401R_tirtos_ccs) there is no reference to --retain=interruptVectors or #pragma RETAIN(interruptVectors) in the project (grep'd through the project folder). Regardless, the project runs on the MSP432 launchpad without an issues, so I do not see how this could be causing the problem.

    The paradox in the issue is that the gpio_toggle_output_MSP_EXP432P401R_nortos_ccs project works on our custom board but the timerled_MSP_EXP432P401R_tirtos_ccs does not, which indicates an issue with the software. However, both sample projects run on the MSP432 launchpad, which indicates an issue with hardware.

  • Robert,

    I am looking at one of the timerled_MSP_EXP432P401R_tirtos_ccs's peripheral configuration source files, MSP_EXP432P401R.c. Within GPIO_PinConfig gpioPinConfigs[], I see that this SDK example configures GPIOs including P6.0 and P4.1, which are not available on the 64 pin RGC package. This is because the SDK was developed to be used with the MSP-EXP432P401 LaunchPad.

    The gpio_toggle_output_MSP_EXP432P401R_nortos_ccs project probably works with your custom board, because it only configures and uses P1.0, which is available on all MSP432P401 variants.

    Try modifying the timerled_MSP_EXP432P401R_tirtos_ccs's GPIO configuration in MSP_EXP432P401R.c, MSP_EXP432P401R.h, and Board.h according to the pins available on the RGC package. Or simply use our Pin Mux Tool.

    BR,

    Seong

  • If you look at my post from Sep 30, 2019 8:31 PM, I attached a modified timerled_MSP_EXP432P401R_tirtos_ccs project where I eliminated all references to the pins which are only available on the 100-pin package. This did not prevent the boards from being bricked.

  • Robert,

    We just released a new SDK (v3.30), that includes our new SysConfig pin configuration tool. Try using this to generate source code that is compatible with the 64-pin package type.

    One issue we currently have with the CCS version of SysConfig is that you are not able to choose the package type. The work around is to use the desktop version where you are able to choose the package type. You can download it here

    After downloading the latest SDK and Sysconfig (desktop version), try following these steps

    1) Go through the SysConfig Basics lab on SimpleLink Academy to learn how to use the tool. 

    2) Import the new timerled project to your CCS workspace from the latest SDK. Open timerled.syscfg. 

    3) Start the desktop version of Sysconfig, choose your device+package type and click start. This will open the sysconfig interface identical to the one you see on CCS. 

    4) Configure the pins on the desktop version as you see for the timerled project on CCS.

    5) Save your pin configuration on the desktop version, generating a new syscfg file. Import this to your timerled project on CCS.

    6) Delete the default syscfg file or simply exclude it from the build.

    Hope this helps,

    Seong

  • Hi Seong,

     

    Thank you for the recommendation. I went ahead and downloaded the newest SDK and tested the new SysConfig Tool; very intuitive and useful. However, after bricking another 64-pin board with the correct configuration I decided to program an older custom MSP432 board in production which yielded some interesting results.

    1. MSP432P401R Launchpad (100 pin)
      1. GPIO (nortos) - runs
      2. timer_led (rtos) - runs
    2. In production MSP432 Board (100 pin)
      1. GPIO (nortos) – runs
      2. timer_led (rtos) - bricks
    3. Custom new board (64 pin)
      1. GPIO (nortos) – runs
      2. timer_led (rtos) – bricks

    As evident from the results above, our board design (old and new) can handle the nortos variant of the sample firmware but bricks when RTOS firmware is loaded onto the device. Our schematic is based off the MSP432 launchpad. Any idea why this may be happening? We will complete a board design review in the coming days and get back to you shortly.

     

    Thanks,

    Robert

  • Hi Seong,

    We completed a design review of schematic with no major findings.

    I uploaded a video here, https://youtu.be/LimjTNj35RY, which clearly demonstrates the issue within Power_init(). I stepped through the timerled_MSP_EXP432P401R_tirtos_ccs (MSP432 SDK ver 3.30) sample on our older 100-pin MSP432 custom board which has a nearly identical schematic to our new board and demonstrates the same issue.

    The board bricks upon the execution of (line 6585 in driverlib.c)

                    PCM->rCTL0.r = (PCM_KEY | PCM_AM_LF_VCORE0
                            | (regValue & ~(PCMKEY_M | AMR_M)));

    What hardware/software issue could be causing this malfunction? Seem like it may pertain to the low drop-out voltage regulator.

    Thanks,

    Robert

  • Problem solved. The examples switch from LDO to DC-DC regulator by enabling pre-configured Performance Levels. Without a DC-DC regulator circuit this caused the issues highlighted above. Reverting to LDO solved the problem.

    Thanks,

    Robert

**Attention** This is a public forum