Jump to content
43oh

msp430-fr4xx2xx


Recommended Posts

So now that msp430-elf is robust enough to be usable, I'm updating BSP430 one last time before taking on a job where I'll be working Nordic chips. I figured I'd add the EXP430FR4133 since it's the first launchpad that mspgcc can't support.

 

All went swimmingly until I tried to compile the nop bootstrap application, and things blew up in the clock configuration. "Wonderful," I thought, "TI's gone and made a third version of the CS peripheral, subtly incompatible with the original FR57xx CS and the revised FR58xx CS_A."

 

Nope. It's not subtly incompatible. They've taken the UCS module from the F5xx/6xx chips, rearranged and resized some of the bitfields, and called it a CS module. That's wholesale incompatible, and is pretty much a last straw for me and MSP430. (Understand: I wouldn't care if they had called it a CS4 module or a UCS_A module. But using the same distinguishing __MSP430_HAS_CS__ preprocessor symbol for fundamentally different peripherals is just unacceptable.)

 

"Completely different but mostly the same." -- Joy

 

(Bonus points to anybody who knows where that quote comes from.)

Link to post
Share on other sites

Thanks for the heads up.

 

For anyone making a cross device library would checking for the device family be enough to differentiate the modules?

It would be if the msp430fr4133.h header didn't contain:

#define __MSP430_HAS_MSP430XV2_CPU__  /* Definition to show that it has MSP430XV2 CPU */
#define __MSP430FR5XX_6XX_FAMILY__
I expect that to change in the future (__MSP430FR2XX_4XX_FAMILY__) but getting things right the first time seems to be a difficulty for TI, and us cross-device library folks can't assume the external headers are updated the way TI can within CCS.

 

For CS I look for presence of SELA which is a single-bit in the 4xx version and multi-bit (SELA0, SELA1, SELA2) in the other variants. For eUSCI I'm still figuring but it'll be some check on something like UCSSEL__MODCLK versus UCSSEL__ACLK.

Link to post
Share on other sites

It gets better. This device has an ADC. Here are the conditionals that identify the specific flavor of ADC on all previous MSP430s:

#define HAVE_REF (defined(__MSP430_HAS_REF__)           \
                  || defined(__MSP430_HAS_REF_A__))

#define HAVE_ADC10 (defined(__MSP430_HAS_ADC10__)       \
                    || defined(__MSP430_HAS_ADC10_A__)  \
                    || defined(__MSP430_HAS_ADC10_B__))

#define HAVE_ADC12 (defined(__MSP430_HAS_ADC12__)               \
                    || defined(__MSP430_HAS_ADC12_PLUS__)       \
                    || defined(__MSP430_HAS_ADC12_B__))
How is this new ADC identified in the device headers? 

#define __MSP430_HAS_ADC__             /* Definition to show that Module is available */
Which ADC is it? Surprise: it's the ADC10_B from the old FR57xx line, except that the internal temperature sensor is on channel 12 not channel 10 and it doesn't have an internal voltage sensor.
Link to post
Share on other sites

Which ADC is it? Surprise: it's the ADC10_B from the old FR57xx line, except that the internal temperature sensor is on channel 12 not channel 10 and it doesn't have an internal voltage sensor.

And all the constants and register names in the headers have prefix ADC (e.g. ADCSHT_0) instead of ADC10 (e.g. ADC10SHT_0) used in all the other ADC10 peripherals on all the other MSP430s. So we get to #define aliases for everything.
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...