MSP430FR50431: does not start from Power On after flashing in CCS

Hi Christian,

This may be a software issue, we can try some known good software though just to ensure its not something hardware side. 

Can you try programming the basic GPIO toggle example? https://dev.ti.com/tirex/explore/node?node=A__AJw-FZ9Zq1Pz7N.L6mcIJw__msp430ware__IOGqZri__LATEST

You may need to change the GPIO if P1.0 is not a good choice for your board.

What I'd like to see is if your device behaves as we expect (toggles the GPIO), after reset when that code is running. 

Best Regards,
Brandon Fisher

Good news, its firmware indeed, bad news, no idea why:  Here is my main loop ( as I mentioned I am using FR4047 zo measure USS). The commented line makes the difference. uncomment and it still runs when loaded by CCS but not when power on.  

int main(void) {

  volatile USS_message_code code;

  USS_calibration_hspll_results testResults;

  USS_Algorithms_Results_fixed_point algResultsFixedPoint;

  WDTCTL = WDTPW | WDTHOLD;               // Stop WDT

  P3OUT &= ~BIT1;                         // Clear P1.0 output latch for a defined power-on state

  P3DIR |= BIT1;                          // Set P1.0 to output direction

  PM5CTL0 &= ~LOCKLPM5;                   // Disable the GPIO power-on default high-impedance mode

  USS_registerHSPLLInterruptCallback(USS_HSPLL_Interrupt_PLLUNLOCK, &handlePllUnlockEvent);

  code = USS_configureUltrasonicMeasurement(&gUssSWConfig);

  disableApplicationInterrupts(); //no IRQs during HSPLL

  code = USS_verifyHSPLLFrequency(&gUssSWConfig, &testResults); 

  enableApplicationInterrupts();

  gUssSWConfig.algorithmsConfig->clockRelativeError = _IQ27div((int32_t)(testResults.actualTestCount -

         testResults.expectedResult),testResults.expectedResult);

  code = USS_initAlgorithms(&gUssSWConfig);

  USS_configAppTimerPeriod(&gUssSWConfig, 32768); // 32768 = 1 sec

  code = USS_startLowPowerUltrasonicCapture(&gUssSWConfig);

//  code = USS_runAlgorithmsFixedPoint(&gUssSWConfig,&algResultsFixedPoint);

  while(1)

  {

      P3OUT ^= BIT1;                      // Toggle LED

      __delay_cycles(5000000);

  }

}

Hi Christian,

Your code looks okay to me, it seems to follow the same general flow as our example. 

The API guide entry for USS_runAlgorithms does mention that it expects a contiguous section of LEARAM to be available that matches the sampleSize setting for gUssSWConfig. Can you share your linker (<device>.cmd) file? 

Best Regards,
Brandon Fisher

Hello Brandon,

I am not a speciclist in linker files. I just use the standard one provided by the MSP430FR6047 example. Here is is; lnk_msp430fr6047.cmd

Best Regards

Christian

Hi Christian,

This looks like the default linker file for the EVM430-FR6047, but you are building and running for the MSP430FR50431 correct? You should use the linker either for the MSP430FR50431, or at least the one for MSP430FR6043 (I've attached it to this post below). 

Please give that a try and let me know.

Additionally, does the code continue to run and operate properly if you leave the debugger physically connected when you are trying to run the code independently and issue a reset? 

How are you supplying power to the board? 

Best Regards,
Brandon Fisher

lnk_msp430fr6043.cmd

Sorry, I picked the wrong one. My target is indeed MSP430FR5043IRGCT and the linker command file is lnk_msp430fr5043.cmd (from the lib example). Not sure if the linker flags make the problem (e.g. the map file ?): Actually I did not touch this too from the example and here it is:

-vmspx --data_model=large -O3 --use_hw_mpy=F5 --advice:power="none" --advice:hw_config=all --define=USS_PULSE_MODE=0 --define=__MSP430FR5043__ --define=_MPU_ENABLE --printf_support=minimal --diag_warning=225 --diag_wrap=off --display_error_number --large_memory_model --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 -z -m"FR6047_USSSWLib_ESP32.map" --heap_size=160 --stack_size=512 --cinit_hold_wdt=on -i"/Applications/ti/ccs/ccs/ccs_base/msp430/include" -i"/Applications/ti/ccs/ccs/ccs_base/msp430/lib/5xx_6xx_FRxx" -i"/Applications/ti/ccs/ccs/ccs_base/msp430/lib/FR59xx" -i"/Applications/ti/ccs/ccs/tools/compiler/ti-cgt-msp430_21.6.0.LTS/lib" -i"/Applications/ti/ccs/ccs/tools/compiler/ti-cgt-msp430_21.6.0.LTS/include" --priority --reread_libs --define=_MPU_ENABLE --diag_wrap=off --display_error_number --warn_sections --xml_link_info="FR6047_USSSWLib_ESP32_linkInfo.xml" --use_hw_mpy=F5 --rom_model

BR
Christian

Christian,

That linker should be fine if you are using the correct default one. 

If you run in free run mode does the code still hang with that function enabled? To do this launch a debug session, and go to Run->Free Run in CCS. I'm wondering if this is something timing related here since it seems like your code is correctly running to main when that function is removed. 

Best Regards,
Brandon Fisher

I did. It runs fine in free mode, still runs after hardware reset, does not run anymore after repower. Unfortunately the "hang" is in the closed source code, otherwise easy to debug. Also, I put a few __delay_cycles right before startLowPowerUltrasonicCapture and before the critical lib function call - same result.

Hi Christian,

So it seems pretty certain that the code is hanging somewhere in the runAlgorithms function. Troubleshooting it may be tricky since, as you noted, this is available only in compiled library form. Does your code still hang if you try to use the non-fixed point version of the USS_runAlgorithms function?

USS_runAlgorithms(&gUssSWConfig,&algResults);

Exactly the same result! If you wish I can send you the whole project as .zip file if you tell me how.

Hi Christian,

I will send you an E2E Friend request, please accept, and then you can send me the project via Private message with the project that way. 

Best Regards,
Brandon Fisher

Ok I will send you the code. So here is what I did as well. I applied the very same code on the EVM430-FR6047 using the very same  FET430UIF and here it works. The only difference I see is the target FR6047 versus FR5043 for my hardware.  So for testing, you will need hardware with FR5043 to replicate.

Thank you Christian,

I have sent you another message regarding accessing these files. Will take a look at these once I can download them. 

Best Regards,
Brandon Fisher

Hi Christian,

Thanks for sharing your code. I had to ask around a bit on this, but it appears that the USS example code does need some updates to work with the MSP430FR5043. Please see the attached .zip file. The PDF and difference reports summarize the recommended changes. The biggest one is that new linker file. 

Best Regards,
Brandon Fisher

/cfs-file/__key/communityserver-discussions-components-files/166/1614.MSP430FR5043_5F00_SW_5F00_Changes.zip