MSP432 CMSIS Software Update

Hi there,

Having an issue with this update. I downloaded and completed the CMSIS update program. However, starting CCS after this update leads to a lock-up while it is trying to update the CCS components related to this change. See attached picture. I'm running Windows 10.

It submitted a bug report, I think the reference was #17387.

Also, why does it install to /ti/msp by default? Previous versions of the mspware went into /ti/msp430. Doesn't having these conflicting versions co-exist cause some sort of problem?

I have applied the MSP432 CMSIS Update on 23 computers. Out of these 23, two of them do not work, one of them runs Windows7, the other Windows8.1.

For the updates that did not work, they went without any error or warning messages. Also the two dialog boxes that asked for confirmation for update did not show up. The old startup files are still used when a new project is created and the new register definitions are not recognized. The update was applied to CCS, Keil, and MSPWare.

I copied the whole Keil installation folder from a Win7 computer that works to the Win7 computer that did not work. That fixed the problem for Keil MSP432 CMSIS Update.

I copied the whole C:\ti\ccs6\ folder from a Win7 computer that works to the Win7 computer that did not work. That fixed the problem for CCS MSP432 CMSIS Update.

Hi Alexander,
thank you for reporting the issue to us! We are looking into the issue and will let you know once there is any update. We appreciate your patience with the delay due to the holiday season.
Regards,
~Dung

P.S.: regarding ti/msp, moving forward (starting with CCSv6.2 or later) all content for msp (msp430 & msp432) such as mspware will be installed to ti/msp. For the time being, some hooks are put in place to allow CCS to search for MSPWare content in both ti/msp & ti/msp430 folders.

Using the v3.10.00 Beta I get two additional warnings from gcc (with -Wall -Wextra).

1. The Timer32-functions has an argument of type uint32_t which should be either TIMER32_0_BASE or TIMER32_1_BASE. These preprocessor constants are defined in timer32.h as follows: 

#define TIMER32_0_BASE   TIMER32_1
#define TIMER32_1_BASE   TIMER32_2

TIMER32_1/_2 are defined in msp432p401r.h as 

#define TIMER32_1                        ((Timer32_Type *) TIMER32_BASE)
#define TIMER32_2                        ((Timer32_Type *) (TIMER32_BASE + 0x00020))

So they are of type Timer32_Type * resulting in the following warning: 

MSP432_DriverLib/inc/msp432p401r.h:1328:42: warning: passing argument 1 of 'Timer32_startTimer' makes integer from pointer without a cast
 #define TIMER32_2                        ((Timer32_Type *) (TIMER32_BASE + 0x00020))
                                          ^
MSP432_DriverLib/driverlib/MSP432P4xx/timer32.h:71:26: note: in expansion of macro 'TIMER32_2'
 #define TIMER32_1_BASE   TIMER32_2

Because these permanent warnings are quite annoying, I think this should be fixed, for example in timer32.h with 

#define TIMER32_0_BASE   (uint32_t) TIMER32_1
#define TIMER32_1_BASE   (uint32_t) TIMER32_2

if I'm not mistaking. 

2. I'm not sure if this one is correct (don't think so) 

/** \brief  Set FPSCR

    This function assigns the given value to the Floating Point Status/Control register.

    \param [in]    fpscr  Floating Point Status/Control value to set
 */
__attribute__( ( always_inline ) ) __STATIC_INLINE void __set_FPSCR(uint32_t fpscr)
{
#if (__FPU_PRESENT == 1U) && (__FPU_USED == 1U)
  /* Empty asm statement works as a scheduling barrier */
  __ASM volatile ("");
//  __ASM volatile ("VMSR fpscr, %0" : : "r" (fpscr) : "vfpcc");          // ARMCC_V6: needs to be checked
  __ASM volatile ("");
#endif
}

but it results in almost every file in 

MSP432_DriverLib/inc/CMSIS/cmsis_gcc.h: In function '__set_FPSCR':
MSP432_DriverLib/inc/CMSIS/cmsis_gcc.h:343:78: warning: unused parameter 'fpscr' [-Wunused-parameter]
 __attribute__( ( always_inline ) ) __STATIC_INLINE void __set_FPSCR(uint32_t fpscr)

Bug in driverlib/gpio.c line 58:

#define OFS_LIB_P2IE    ((uint32_t)&P2->IE - (uint32_t)P2)

That's wrongly resulting in 0x1b.

One line above 

#define OFS_LIB_P1IE    ((uint32_t)&P1->IE - (uint32_t)P1)

is correctly calculated to 0x1a.

Driverlib v2.08.00 was correct with OFS_P1IE and OFS_P2IE both 0x1a.

BTW, I'm not sure why there is a distinction. These both constants are only used in "GPIO_getEnabledInterruptStatus" where OFS_PAIE is sufficient for all cases. 

Hi user138497234,

thank you for finding the bugs and providing the suggestions. We have confirmed and fixed the following:

1. Warning for using TIMER32_0_BASE/ TIMER32_1_BASE

- Change

 #define TIMER32_0_BASE   TIMER32_1   

  To:

#define TIMER32_0_BASE              (uint32_t)TIMER32_1

2.          #define OFS_LIB_P2IE    ((uint32_t)&P2->IE - (uint32_t)P2)  is wrong offset

- Change

#define OFS_LIB_P2IE    ((uint32_t)&P2->IE - (uint32_t)P2)  

 to:

 #define OFS_LIB_P2IE    ((uint32_t)&P1->IE - (uint32_t)P1)  

We are still looking into the warnings in cmsis_gcc.h

Regards,

Dung

Hi user138497234,

regarding the unused parameter warnings for "fpscr".

This is a valid warning, when compiling with gcc and the FPU is not used. Nevertheless in a newer versions of the cmsis_gcc.h file this and a couple of other warnings are suppressed by the following code at the begin of the header file:

/* ignore some GCC warnings */
#if defined ( __GNUC__ )
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wsign-conversion"
#pragma GCC diagnostic ignored "-Wconversion"
#pragma GCC diagnostic ignored "-Wunused-parameter"
#endif

In the CCS version you are using we still deliver version 4.20 of the header from CMSIS pack 4.4.0. In the meanwhile CMSIS has been updated to 4.5.0 by ARM and we are planning to ship the new headers with one of the next CCS releases. Ths will include cmsis_gcc.h in version 4.30 and the warnings won't be showed anymore.

For the moment just add the above code to cmsis_gcc.h in ccs_base\arm\include\CMSIS.

Regards,

Thorsten

Thanks for confirmation!

Thorsten Stauber said:

This is a valid warning, when compiling with gcc and the FPU is not used. Nevertheless in a newer versions of the cmsis_gcc.h file this and a couple of other warnings are suppressed by the following code at the begin of the header file:

But I am using the FPU and that was the point I'm not sure about, because only one asm-statement does something that does make sense is commented out.