MSP432-DEBUGGERS: the launchpad 401R I've been using has been discontinued, need a development board to support production ASAP

Hi Robert,

What version of CCS are you using? You can try downloading previous versions using the link below. Those may have support for older devices.

https://software-dl.ti.com/ccs/esd/documents/ccs_downloads.html

Regards,

Evan

before I go down that rabbit hole, do you know if an older version of ccs will still work with the latest/last update to the launchpad's eeprom/flashed debugger?

I had an earlier version 6.2, and had to go directly to v10 because v9 wouldn't build when it was available.

I had an old project, and retried that, but the project won't build, with the error that it need to install energia but a compatible version  was no longer available, and that halted the build. I have no hope for getting an earlier version to run if older dependencies for older versions are no longer available.

I phoned TI cares and received ticket #CS1039490.  I pointed out that this was critical, the product is a production line for NASA.

My boss said he loved TI microprocessors until the tools went away.

robert schaefer said:

 I know my problem isn't your emergency but the 401R launchpad is no longer allowed to be used by CCS, I'm getting a "no longer supported" error message that I didn't get last week.

What is the exact error message?

Is it the same as reported in MSP432P401R: Error initializing flash programming: Your XMS432P401R material is no longer supported?

At the end of the referenced the suggestion is such an error could be caused by loading a bad program, and maybe performing a Factor Reset could recover the device.

MSP432-DEBUGGERS: MSP432 P401R LaunchPad (MSP-EXP432P401R) is dead after firmware update contains a link to a archived copy of slau575 which contains the description of the MSP432P factory reset procedure.

the message is:

Flash Programmer: Reading device TLV failed.

Error initializing flash programming: Your XMS432P401R material is no longer supported. We recommend moving to production-quality XMS432P401R/M by ordering samples at www.ti.com/product/MSP432P401R.

This level of specificity makes me believe that TI knows exactly what it did. We've got a product line and schedules to support. We have customers (NASA) we'll have to explain missed shipments to.

Once this is resolved by TI, for good or bad, we'll likely be moving away from TI microprocessors. The help line is 1-800-TI CARES. 

I'm not angry, I'm disappointed.

Hi Robert,

I'd like to help you resolve this issue as fast as possible. Are you using this device for a new design or are you supporting an existing design. We cannot provide support for new designs since we no longer sell MSP432P devices, but we will do our best to figure out any issues you are having with an existing design.

As far as "TI removing support for this device": I checked with my team and MSP432 should still be supported by the current version of CCS. However you mentioned in your post you are using and XMS432P device. This indicates this a pre-release device. How did you get these devices? Unfortunately it does appear that CCS is not supporting XMS432 devices anymore. You may have luck with older tool version.

Regards,

Evan

Hi,

We are supporting an existing design on a bespoke board that has not yet been released to the customer, it has taken years to develop and it seems the part went obsolete in the middle of development. In the history of development here, we 'locked in' first the 401R as a prototype bespoke board to show the part can be used, then went to the 4111 for the actual product. I am using a 401R launchpad to develop at my desk, then rebuilding and reloading as a 4111 in the product lab, with no problems until now. 

I am not using the XMS432P, I am using a launchpad 401R. The error message is reporting that it detected XMS432P, so I'm thinking the error message is wrong, alternately, during TI's production of launchpads, an XMS version escaped into the wild. Which do you think is more likely?  

bob s.

Thanks for clarifying the situation.

Can you read the top code marking on the device on the launchpad? If it is an XMS device it will say so. 

I think the next step will be to figure out a CCS version that will support your launchpad. Hopefully we can find a version that supports both your launchpad and your production device. Otherwise it will be awkward for you to use different tool environments for your different targets.

Going back to your original post: what triggered this issue? It sounds like you were able to develop for your products until something happened. What happened? Was it a tool upgrade? 

Evan

Hi,

Last Thursday it worked, Friday I was coding/compiling but not debugging, same for Monday and Tuesday, then yesterday, then inability to download/debug. No upgrade I remember between Thursday and Wednesday, but it is possible I forgot.

I'm at CCS v10.2, the last CCS that had its own directory was 6 but that was for a different project, there might have been a year or two between my last 432 and this 432 project, so I might have jumped directly from CCS v6 to CCS v10.0.

The launchpad marking is:MSP-EXP432P401R

Is the launchpad black? If so it is not going to be supported. See here: https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/853262/ccs-msp432p401r-composet-can-t-detect-the-black-msp432-launchpad

The launchpad marking is not import, but the top code marking of the device (on the package) is. What is the device top code marking?

Evan

robert schaefer said:

I am not using the XMS432P, I am using a launchpad 401R. The error message is reporting that it detected XMS432P, so I'm thinking the error message is wrong, alternately, during TI's production of launchpads, an XMS version escaped into the wild. Which do you think is more likely?

With CCS 11.2 under Linux started with a "red" MSP-EXP432P401R Rev 2.0 and CCS was able to successfully start a debug session for the launchpad. In the system_msp432p401r.c file had set the __SYSTEM_CLOCK to 48000000 (48 MHz).

As an experiment to create a "bad" program edited the SystemInit() to comment out the "Switches LDO VCORE0 to LDO VCORE1; mandatory for 48 MHz setting", "1 flash wait states (BANK0 VCORE1 max is 16 MHz, BANK1 VCORE1 max is 32 MHz)" and "Set Flash Bank read buffering" blocks:

    #elif (__SYSTEM_CLOCK == 48000000)                     // 48 MHz
    // Switches LDO VCORE0 to LDO VCORE1; mandatory for 48 MHz setting
    //while((PCM->CTL1 & PCM_CTL1_PMR_BUSY));
    //PCM->CTL0 = PCM_CTL0_KEY_VAL | PCM_CTL0_AMR_1;
    //while((PCM->CTL1 & PCM_CTL1_PMR_BUSY));

    // Switches LDO VCORE1 to DCDC VCORE1 if requested
    #if __REGULATOR
    while((PCM->CTL1 & PCM_CTL1_PMR_BUSY));
    PCM->CTL0 = PCM_CTL0_KEY_VAL | PCM_CTL0_AMR_5;
    while((PCM->CTL1 & PCM_CTL1_PMR_BUSY));
    #endif

    // 1 flash wait states (BANK0 VCORE1 max is 16 MHz, BANK1 VCORE1 max is 32 MHz)
    //FLCTL->BANK0_RDCTL = (FLCTL->BANK0_RDCTL & ~FLCTL_BANK0_RDCTL_WAIT_MASK) | FLCTL_BANK0_RDCTL_WAIT_1;
    //FLCTL->BANK1_RDCTL = (FLCTL->BANK1_RDCTL & ~FLCTL_BANK1_RDCTL_WAIT_MASK) | FLCTL_BANK1_RDCTL_WAIT_1;

    // DCO = 48 MHz; MCLK = source
    CS->KEY = CS_KEY_VAL;                                  // Unlock CS module for register access
    CS->CTL0 = CS_CTL0_DCORSEL_5;                          // Set DCO to 48MHz
    CS->CTL1 = (CS->CTL1 & ~(CS_CTL1_SELM_MASK | CS_CTL1_DIVM_MASK)) | CS_CTL1_SELM__DCOCLK;
	                                                       // Select MCLK as DCO source
    CS->KEY = 0;

    // Set Flash Bank read buffering
    //FLCTL->BANK0_RDCTL = FLCTL->BANK0_RDCTL | (FLCTL_BANK0_RDCTL_BUFD | FLCTL_BANK0_RDCTL_BUFI);
    //FLCTL->BANK1_RDCTL = FLCTL->BANK1_RDCTL | (FLCTL_BANK1_RDCTL_BUFD | FLCTL_BANK1_RDCTL_BUFI);
    #endif

After loading this program with a "bad" configuration any further attempt to start a debug session now fails with the error:

CORTEX_M4_0: * WARNING *: The connected device is not MSP432P401R
CORTEX_M4_0: GEL Output: Memory Map Initialization Complete
CORTEX_M4_0: GEL Output: Halting Watchdog Timer
CORTEX_M4_0: Flash Programmer: Reading device TLV failed.
CORTEX_M4_0: Error initializing flash programming: Your XMS432P401R material is no longer supported. We recommend you moving to production-quality MSP432P401R/M silicon by ordering samples at www.ti.com/product/MSP432P401R.
CORTEX_M4_0: JTAG Communication Error: (Error -261 @ 0x0) Invalid response was received from the XDS110. (Emulation package 9.7.0.00213) 

I tried the "Factory Reset Without Password" method in SLAU575K but that hasn't fixed the above error on trying to start a debug session.

The conclusion of the above is that it is possible to load a "bad" program to the MSP432P401R which causes CCS to fail to detect the device and report "Your XMS432P401R material is no longer supported". The "bad" program probably causes a device reset which the debugger is trying to attach. Not sure what i did which stopped the factory reset from working.

Even, I missed your reply, I'm jumping to trying Chester Gillon's reply below.

It's not the launchpad black, I switched from the black to the red when I got the errors saying the black is obsolete, many, many years ago.

the device top code marking of my "red" launchpad is 401R rev D.

Chester, I'm up to step 4. (steps 1 through 3 matched your directions)

There were several differences from what you said to do in step 4 and the options presented by my version of CCS

The github project was built with v11.2, I've got v10.2

I right clicked on the .ccmxl target configuration file to select "Launch Selected Configuration".
this option does not exist on my CCS.

I then selected debug and CCS restarted debug which allowed the ability to suspend.

I selected 0xE0044000 in disassembly, which was selectable, the memory tab was not available by default.

I used help to find memory monitor, which is not memory but a reasonable first step, but when I selected memory from the help panel, an empty panel appeared with the word "memory at the top that did not allow me to type into the panel.

Questions: 1. Any idea why my CCS "memory" tool (ubuntu linux) seems to be broken? 

                  2. I attempt to upgrade to v11.2, CCS says none are available (ubuntu linux). What is going on?

thanks,

 bob s.

robert schaefer said:

1. Any idea why my CCS "memory" tool (ubuntu linux) seems to be broken? 

You want the Memory Browser window - see 7.4.5. Memory Browser View in the CCS debug guide.

robert schaefer said:

2. I attempt to upgrade to v11.2, CCS says none are available (ubuntu linux). What is going on?

From memory, CCS doesn't always support incrementally updating an existing older version of CCS to the newly released version via the CCS Update Manager. See https://www.ti.com/tool/CCSTUDIO#downloads for download links.

thank you, I found the memory browser and am back at the point were I was stalled yesterday. I'll repost when I know more.

Yea!!! thank you all !!!