JRDavisUF

I had the same problem, take a look at this:
 

OK, I think I get it now.  I new the rom_map.h header selected the hardware or software version, but I really didn't look into what it was doing.  I was assuming it determined whether or not my rom could support it.  Turns out, one must include the rom header before the rom_map header.  If I do that (or replace MAP_ with ROM_), I don't need any delays to get it to work correctly....So I think Clavier is spot on.
The flip side is that the rom version is significantly slower than the software versions.  So I guess the price one is paying for a reduced code size, is speed?  I guess I get that.
                                                      9/10 bytes              66 bytes
pyCrc                                             13us                         13us
driverlib software Crc                     11us                          27us
rom Crc                                          16us                          74us

Thanks for the ideas.  Energia uses the WDT for other purposes, as such I didn't put it in my code.  However, I just stuck it in and that doesn't help.  I did try getting rid of the MAP_ stuff and that didn't help either.  I also noticed that the example defined the returned crc value as volatile, so I changed that, but it didn't help either.
I missed the 1-clock cycle note.  As such, I changed my 1 microsecond delay to a 1 cycle delay and the code works fine.  I'm guessing that must be the issue. 

Thanks for the ideas.  Energia uses the WDT for other purposes, as such I didn't put it in my code.  However, I just stuck it in and that doesn't help.  I did try getting rid of the MAP_ stuff and that didn't help either.  I also noticed that the example defined the returned crc value as volatile, so I changed that, but it didn't help either.
I missed the 1-clock cycle note.  As such, I changed my 1 microsecond delay to a 1 cycle delay and the code works fine.  I'm guessing that must be the issue. 

FWIW, I did figure out why my RTC clock accuracy was so bad.  By default, the RTC clock sources the internal 32k crystal, not the external LFXT as BCLK.  As such, to get it to work:
1) Define frequency of LFXT to 32k:   MAP_CS_setExternalClockSourceFrequency(32768, 48000000); // LF, HF
(why energia doesn't do this already, I don't know.  I see how starting it might consume power unnecessarily, but why not set the value atleast???)
This step might not be needed, but since I wanted to query my clock speeds later, I added it.
2) Turn on LFXT (I loop on this since it doesn't always take):  bool status = MAP_CS_startLFXTWithTimeout(CS_LFXT_DRIVE3, 10);
3) Tell the RTC to use LFXT:  MAP_CS_initClockSignal(CS_BCLK,CS_LFXTCLK_SELECT,CS_CLOCK_DIVIDER_1);
With my msp432 launchpad, this gives me about 5ppm  (testing every 15s for about 2 weeks).
Hope this helps anyone else who might have had issues...
jrd
PS  Of course, you probably don't need to use the MAP_ versions...but I figured why not
PPS  This is how I was getting my actual clock speeds...ie, why I added step 1.
    // Get the values
    uint32_t aclk   = MAP_CS_getACLK();
    uint32_t mclk   = MAP_CS_getMCLK();
    uint32_t smclk  = MAP_CS_getSMCLK();
    uint32_t hsmclk = MAP_CS_getHSMCLK();
    uint32_t bclk   = MAP_CS_getBCLK();