TI MSP-EXP432P401R On Sale This Week

[Leuams]

If anyone is interested in experimenting with TI's MSP432P401R launchpad they are offering a deal this week on it:
http://www.ti.com/lsds/ti/store/engineers-week-deals.page?DCMP=EngineersWeek2016&HQS=Corp-corpgen-techtalent-engineersweek-thinkinn-20160222-store-deals-wwe

I just picked up 3 for the price of one. I have been wanting to try out different microcontrollers and this seems like a good enough excuse.

[dannyf]

Does the tool chain actually work on those boards?

[AlxDroidDev]

It's been at that price since last year, but with a different discount code: https://www.eevblog.com/forum/microcontrollers/msp432-launchpad-at-us$4-32/

Does the tool chain actually work on those boards?

Yes, but setting it up is a serious PITA, and there are several incompatibilities, including USB 3.0 ports.

The MSP342 works beautifully with the Energia IDE, ' though.

[dannyf]

The MSP342 works beautifully with the Energia IDE, ' though.

Does it work with CCS v6?

[AlxDroidDev]

Does it work with CCS v6?

Yes

[edavid]

Repost: https://www.eevblog.com/forum/microcontrollers/msp432-launchpad-at-us$4-32/

[dannyf]

"Yes"

Lucky that you don't have error 1063.

[AlxDroidDev]

"Yes"

Lucky that you don't have error 1063.

Many of the issues I had with CCS were reported in the original thread, but eventually it worked. I had to do a full erase of the MSP432 a few times.

[rsjsouza]

Just beware that an updated MSP432 component is messing up existing code:

https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/492141

I had seen the warning below in my projects before and it seems this update put it in full effect

"C:\ti\ccsv6\ccs_base\arm\include\msp432p401r.h", line 69: warning #1181-D: #warning directive: "MSP432 software will be updated to use CMSIS-Core in March 2016. This update will allow your MSP432 software to be CMSIS compliant, but require modification to your existing MSP432 code. A beta release is available if you want to start converting your code today. Refer to http://www.ti.com/MSP432CMSIS for detailed changes, conversion guide and background information."

[dannyf]

The non cmsis start up is not a big problem, as many of the earlier cortex m chips have vendor specific, non cmsis startup files. Porting code to a cmsis compliant version is easy.

The whole thing seems to be very half assed on the part of ti.

[AlxDroidDev]

The whole thing seems to be very half assed on the part of ti.

Agreed 10000%
The sheer lack of more then 2-3 examples for the MSP432 in CCS (at least the version available for download in January) denounces that TI is doing things half-assed (I can't find a better term for it!).

[dannyf]

There are tons of msp432 examples ready to be imported in ccsv6.

[newbrain]

There are tons of msp432 examples ready to be imported in ccsv6.

The whole thing seems to be very half assed on the part of ti.

This is a good synthesis.
I usually linger on the ST camp, and got a couple of Launchpads (at that price, how to resist?) for variety and fun.

Just compiled a couple of examples:
cs_hfxt_start.c contains this pearl:

Code: [Select]

MAP_SysTick_setPeriod(24000000);where they try to cram a 25bit value in a 24bit register...

The serial echo example works, but if you try to modify for something different, you notice they are programming a supposedly RS-232 like serial with MSB out first...after pulling some hair (in my case, a quite scarce resource...).

I'll have even more more fun than with the HAL, I'm sure!

[andyturk]

cs_hfxt_start.c contains this pearl:

Code: [Select]

MAP_SysTick_setPeriod(24000000);where they try to cram a 25bit value in a 24bit register...

What do you mean by a "25bit" value? The compiler will pass that as 32-bits.

And how do you know that SysTick_setPeriod() is implemented incorrectly?

[dannyf]

What do you mean by a "25bit" value? The compiler will pass that as 32-bits.

And how do you know that SysTick_setPeriod() is implemented incorrectly?

[newbrain]

cs_hfxt_start.c contains this pearl:

Code: [Select]

MAP_SysTick_setPeriod(24000000);where they try to cram a 25bit value in a 24bit register...

What do you mean by a "25bit" value? The compiler will pass that as 32-bits.

And how do you know that SysTick_setPeriod() is implemented incorrectly?

Sorry, my sarcasm meter is in repair, so I'm probably not getting a joke...

I must admit I was writing a bit in a hurry, and not having been exceedingly clear.
Anyhow, here's the long version:

• 24000000 is, as you correctly state, passed as a 32 bit value, no doubt.
• The binary representation has got its bit 24 set: at least 25 bits are needed: 0b1011011100011011000000000
• The ARM M4 systick reload value register STRVR is 32 bits wide, but only the low order 24 are actually used
• The SysTick_setPeriod() more or less simply writes its argument (-1, helpfully) in the above register*
• This gives an actual value of 0b1011011100011011000000000 == 7222784 equivalent to a period of ~0.15s at 48MHz
• I know because I checked the example and library code, after seeing a quite-not-0.5-seconds blink

*The SysTick_setPeriod(), I would say, is not to blame (there's even the expected assert, which must be explicitly enabled), the sloppy example code (as the serial one) is.

[Scrts]

cs_hfxt_start.c contains this pearl:

Code: [Select]

MAP_SysTick_setPeriod(24000000);where they try to cram a 25bit value in a 24bit register...

What do you mean by a "25bit" value? The compiler will pass that as 32-bits.

And how do you know that SysTick_setPeriod() is implemented incorrectly?

Good question.
I've googled a bit and found out this:
http://dev.ti.com/tirex/content/MSPware/MSPWare_2_30_00_49/driverlib/doc/MSP432P4xx/html/driverlib_html/rom__map_8h.html has

Code: [Select]

#define MAP_SysTick_setPeriod   SysTick_setPeriod
Then going deeper:

Code: [Select]

void SysTick_setPeriod ( uint32_t period )
It doesn't seem to be an issue?   

[andyturk]

Sorry, my sarcasm meter is in repair, so I'm probably not getting a joke...

Nah, I was just being persnickety.

... I know because I checked the example and library code, after seeing a quite-not-0.5-seconds blink.

Good!

Finding problems in TI's code is no surprise to me. I spent 18 months dealing with driverlib and Tiva C. 

I've never touched the new MSP, but I thought maybe they were doing something slightly more clever in SysTick_setPeriod() because that 24-bit register is usually called something with "reload" in the name. But if they're not scaling the input parameter to whatever SysTick is clocked by (sometimes a divider is involved), then yep, it's a bug.

[newbrain]

[...]
It doesn't seem to be an issue?

No, not really.
The TI Driver library is burned in internal MSP432 ROM, and the rom_map.h file is used to remap routines that were buggy in the ROM to the ones provided by the source code.

If the user includes the rom_map.h header file and uses the MAP_ prefix in front of the API, the header file will automatically use
preprocessor macros to decide whether to use a ROM or flash version of the API.

So, if you use MAP_xxxx you always get the (supposedly) correct xxxx.

The rom_map.h file you linked, though, is not mapping anything to the ROM, the one I use instead has:

Code: [Select]

#ifdef ROM_SysTick_setPeriod
#define MAP_SysTick_setPeriod                                                 \
        ROM_SysTick_setPeriod
#else
#define MAP_SysTick_setPeriod                                                 \
        SysTick_setPeriod
And ROM_SysTick_setPeriod is defined in rom.h:

Code: [Select]

#if defined(TARGET_IS_MSP432P4XX)
#define ROM_SysTick_setPeriod                                                 \
        ((void (*)(uint32_t period))ROM_SYSTICKTABLE[4])
#endif

Both rom.h and rom_map.h are included by driverlib.h .
So the actual routine called is the one in ROM (at least for my version of DriverLib).

Nah, I was just being persnickety.

I love learning new words! Persnickety is now officially in my vocabulary. Thanks!

Back to the soldering iron, before sleep takes its toll.

[rsjsouza]

The header file that maps the function to ROM does not seem to perform a verification of the parameters. The non-ROM version SysTick_setPeriod() does that.

void SysTick_setPeriod(uint32_t period)
{
    //
    // Check the arguments.
    //
    ASSERT((period > 0) && (period <= 16777216));

    //
    // Set the period of the SysTick counter.
    //
    SysTick->LOAD = period - 1;
}

[westfw]

Code: [Select]

MAP_SysTick_setPeriod(24000000);where they try to cram a 25bit value in a 24bit register..

Heh.  I ran into exactly the same bug in some Atmel sample code, only somewhat obscured:

Code: [Select]

    /*Configure system tick to generate periodic interrupts */
    SysTick_Config(system_gclk_gen_get_hz(GCLK_GENERATOR_0));It worked swell using the original default clock (8MHz internal), but not when I modified the clock initialization to support the documented 48MHz.
(demonstrating why I rather dislike this degree of ... abstraction.  Any ASSERT logic is long gone by the time you have compiled code, and the get_hz() function COMPUTES THE CLOCK RATE at runtime (taking a lot of code to do so!) so you can't see the error at compile time.)  Grr.)

And someone said something like "You'll want to use the vendor libraries to do stuff like initialize the clock, because doing it yourself would be complicated."  HAH!  Of the libraries I've looked at so far, none has done a good job of making clock setup easy.  For the Atmel, instead of having to read datasheets and write registers, "all you have to do is modify this file appropriately" (perfectly obvious!): (and then the clock init code that it sucks in is only about a kilobyte.  Sigh.)

Code: [Select]

:
/* System clock bus configuration */
#  define CONF_CLOCK_CPU_CLOCK_FAILURE_DETECT     false
#  define CONF_CLOCK_FLASH_WAIT_STATES            1
#  define CONF_CLOCK_CPU_DIVIDER                  SYSTEM_MAIN_CLOCK_DIV_1
#  define CONF_CLOCK_APBA_DIVIDER                 SYSTEM_MAIN_CLOCK_DIV_1
#  define CONF_CLOCK_APBB_DIVIDER                 SYSTEM_MAIN_CLOCK_DIV_1
#  define CONF_CLOCK_APBC_DIVIDER                 SYSTEM_MAIN_CLOCK_DIV_1

/* SYSTEM_CLOCK_SOURCE_OSC8M configuration - Internal 8MHz oscillator */
#  define CONF_CLOCK_OSC8M_PRESCALER              SYSTEM_OSC8M_DIV_1
#  define CONF_CLOCK_OSC8M_ON_DEMAND              true
#  define CONF_CLOCK_OSC8M_RUN_IN_STANDBY         false

/* SYSTEM_CLOCK_SOURCE_XOSC configuration - External clock/oscillator */
#  define CONF_CLOCK_XOSC_ENABLE                  false
#  define CONF_CLOCK_XOSC_EXTERNAL_CRYSTAL        SYSTEM_CLOCK_EXTERNAL_CRYSTAL
#  define CONF_CLOCK_XOSC_EXTERNAL_FREQUENCY      12000000UL
#  define CONF_CLOCK_XOSC_STARTUP_TIME            SYSTEM_XOSC_STARTUP_32768
#  define CONF_CLOCK_XOSC_AUTO_GAIN_CONTROL       true
#  define CONF_CLOCK_XOSC_ON_DEMAND               true
#  define CONF_CLOCK_XOSC_RUN_IN_STANDBY          false

/* SYSTEM_CLOCK_SOURCE_XOSC32K configuration - External 32KHz crystal/clock oscillator */
#  define CONF_CLOCK_XOSC32K_ENABLE               false
#  define CONF_CLOCK_XOSC32K_EXTERNAL_CRYSTAL     SYSTEM_CLOCK_EXTERNAL_CRYSTAL
#  define CONF_CLOCK_XOSC32K_STARTUP_TIME         SYSTEM_XOSC32K_STARTUP_65536
#  define CONF_CLOCK_XOSC32K_AUTO_AMPLITUDE_CONTROL  false
#  define CONF_CLOCK_XOSC32K_ENABLE_1KHZ_OUPUT    false
#  define CONF_CLOCK_XOSC32K_ENABLE_32KHZ_OUTPUT  true
#  define CONF_CLOCK_XOSC32K_ON_DEMAND            true
#  define CONF_CLOCK_XOSC32K_RUN_IN_STANDBY       false

/* SYSTEM_CLOCK_SOURCE_OSC32K configuration - Internal 32KHz oscillator */
#  define CONF_CLOCK_OSC32K_ENABLE                false
#  define CONF_CLOCK_OSC32K_STARTUP_TIME          SYSTEM_OSC32K_STARTUP_130
#  define CONF_CLOCK_OSC32K_ENABLE_1KHZ_OUTPUT    true
#  define CONF_CLOCK_OSC32K_ENABLE_32KHZ_OUTPUT   true
#  define CONF_CLOCK_OSC32K_ON_DEMAND             true
#  define CONF_CLOCK_OSC32K_RUN_IN_STANDBY        false

/* SYSTEM_CLOCK_SOURCE_DFLL configuration - Digital Frequency Locked Loop */
#  define CONF_CLOCK_DFLL_ENABLE                  false
#  define CONF_CLOCK_DFLL_LOOP_MODE               SYSTEM_CLOCK_DFLL_LOOP_MODE_CLOSED
#  define CONF_CLOCK_DFLL_ON_DEMAND               true

/* DFLL open loop mode configuration */
#  define CONF_CLOCK_DFLL_FINE_VALUE              (0xff / 4)

/* DFLL closed loop mode configuration */
#  define CONF_CLOCK_DFLL_SOURCE_GCLK_GENERATOR   GCLK_GENERATOR_1
#  define CONF_CLOCK_DFLL_MULTIPLY_FACTOR         (48000000 / 32768)
#  define CONF_CLOCK_DFLL_QUICK_LOCK              true
#  define CONF_CLOCK_DFLL_TRACK_AFTER_FINE_LOCK   true
#  define CONF_CLOCK_DFLL_KEEP_LOCK_ON_WAKEUP     true
#  define CONF_CLOCK_DFLL_ENABLE_CHILL_CYCLE      true
#  define CONF_CLOCK_DFLL_MAX_COARSE_STEP_SIZE    (0x1f / 4)
#  define CONF_CLOCK_DFLL_MAX_FINE_STEP_SIZE      (0xff / 4)

/* SYSTEM_CLOCK_SOURCE_DPLL configuration - Digital Phase-Locked Loop */
#  define CONF_CLOCK_DPLL_ENABLE                  false
#  define CONF_CLOCK_DPLL_ON_DEMAND               true
#  define CONF_CLOCK_DPLL_RUN_IN_STANDBY          false
#  define CONF_CLOCK_DPLL_LOCK_BYPASS             false
#  define CONF_CLOCK_DPLL_WAKE_UP_FAST            false
#  define CONF_CLOCK_DPLL_LOW_POWER_ENABLE        false

#  define CONF_CLOCK_DPLL_LOCK_TIME               SYSTEM_CLOCK_SOURCE_DPLL_LOCK_TIME_DEFAULT
#  define CONF_CLOCK_DPLL_REFERENCE_CLOCK         SYSTEM_CLOCK_SOURCE_DPLL_REFERENCE_CLOCK_XOSC32K
#  define CONF_CLOCK_DPLL_FILTER                  SYSTEM_CLOCK_SOURCE_DPLL_FILTER_DEFAULT

#  define CONF_CLOCK_DPLL_REFERENCE_FREQUENCY     32768
#  define CONF_CLOCK_DPLL_REFERENCE_DIVIDER       1
#  define CONF_CLOCK_DPLL_OUTPUT_FREQUENCY        48000000

/* DPLL GCLK reference configuration */
#  define CONF_CLOCK_DPLL_REFERENCE_GCLK_GENERATOR  GCLK_GENERATOR_1
/* DPLL GCLK lock timer configuration */
#  define CONF_CLOCK_DPLL_LOCK_GCLK_GENERATOR     GCLK_GENERATOR_1

/* Set this to true to configure the GCLK when running clocks_init. If set to
 * false, none of the GCLK generators will be configured in clocks_init(). */
#  define CONF_CLOCK_CONFIGURE_GCLK               true

/* Configure GCLK generator 0 (Main Clock) */
#  define CONF_CLOCK_GCLK_0_ENABLE                true
#  define CONF_CLOCK_GCLK_0_RUN_IN_STANDBY        false
#  define CONF_CLOCK_GCLK_0_CLOCK_SOURCE          SYSTEM_CLOCK_SOURCE_OSC8M
#  define CONF_CLOCK_GCLK_0_PRESCALER             1
#  define CONF_CLOCK_GCLK_0_OUTPUT_ENABLE         false

/* Configure GCLK generator 1 */
#  define CONF_CLOCK_GCLK_1_ENABLE                false
#  define CONF_CLOCK_GCLK_1_RUN_IN_STANDBY        false
#  define CONF_CLOCK_GCLK_1_CLOCK_SOURCE          SYSTEM_CLOCK_SOURCE_OSC32K
#  define CONF_CLOCK_GCLK_1_PRESCALER             1
#  define CONF_CLOCK_GCLK_1_OUTPUT_ENABLE         false

/* Configure GCLK generator 2 (RTC) */
#  define CONF_CLOCK_GCLK_2_ENABLE                false
#  define CONF_CLOCK_GCLK_2_RUN_IN_STANDBY        false
#  define CONF_CLOCK_GCLK_2_CLOCK_SOURCE          SYSTEM_CLOCK_SOURCE_OSC32K
#  define CONF_CLOCK_GCLK_2_PRESCALER             32
#  define CONF_CLOCK_GCLK_2_OUTPUT_ENABLE         false

/* Configure GCLK generator 3 */
#  define CONF_CLOCK_GCLK_3_ENABLE                false
#  define CONF_CLOCK_GCLK_3_RUN_IN_STANDBY        false
#  define CONF_CLOCK_GCLK_3_CLOCK_SOURCE          SYSTEM_CLOCK_SOURCE_OSC8M
#  define CONF_CLOCK_GCLK_3_PRESCALER             1
#  define CONF_CLOCK_GCLK_3_OUTPUT_ENABLE         false

/* Configure GCLK generator 4 */
#  define CONF_CLOCK_GCLK_4_ENABLE                false
#  define CONF_CLOCK_GCLK_4_RUN_IN_STANDBY        false
#  define CONF_CLOCK_GCLK_4_CLOCK_SOURCE          SYSTEM_CLOCK_SOURCE_OSC8M
#  define CONF_CLOCK_GCLK_4_PRESCALER             1
#  define CONF_CLOCK_GCLK_4_OUTPUT_ENABLE         false

/* Configure GCLK generator 5 */
#  define CONF_CLOCK_GCLK_5_ENABLE                false
#  define CONF_CLOCK_GCLK_5_RUN_IN_STANDBY        false
#  define CONF_CLOCK_GCLK_5_CLOCK_SOURCE          SYSTEM_CLOCK_SOURCE_OSC8M
#  define CONF_CLOCK_GCLK_5_PRESCALER             1
#  define CONF_CLOCK_GCLK_5_OUTPUT_ENABLE         false


[newbrain]

And someone said something like "You'll want to use the vendor libraries to do stuff like initialize the clock, because doing it yourself would be complicated."

I'm sure I've said something similar, but I'd like to think I'm not the only one...

With all you can say about (read: against) ST CubeMX, it at least gives you a nice graphical live representation of the clock chains, then you can decide to use the generated code or set the registers by yourself.
I still find that useful, given also the small and not so small differences between the various F0..F7 MCUs.

For the MSP432, I find the description of the various internal and external clocks quite murky in the reference manual (and the same goes for some aspects of the peripherals): maybe it's just me, but I prefer ST style.

[andyturk]

With all you can say about (read: against) ST CubeMX, it at least gives you a nice graphical live representation of the clock chains, then you can decide to use the generated code or set the registers by yourself.

That is one of the best parts of CubeMX, since getting those clock configs right is tricky, and stuff breaks in non-obvious ways if you get it wrong. I also like CubeMX for pin muxing because (on ST parts) that also affects DMA configuration. Without that assistance, it's easy to design a board that works electrically, but tacitly assigns the same DMA resources to more than one peripheral. DAMHIK.

TI's pinmux tool is pretty useful too, at least for the Tiva C parts. Presumably, they have something similar for MSP432. However, an annoyance was that TI didn't distribute CMSIS headers for Tiva C, forcing you to use their driverlib malarkey. Perhaps MSP432 will be better in that respect.

[poorchava]

I'm getting 'coupon code invalid'

[AlxDroidDev]

I'm getting 'coupon code invalid'

Try this:     432@432