strange crashing of the MSP430

george clarkson

Other Parts Discussed in Thread: CC430F5137

I'm using the cc430f5137 and recently I have been experiencing some strange behaviour, I'm not sure how long the issue has been around for as it only occurs when the micro is not connected to the debugger.

When running correctly the micro rushes through the initialization and goes to sleep waking up on interrupts, however when it isn't connected to the debugger about half the time it gets stuck in the initialization, by toggling pins I have Isolated the section of code when the code appears to be hanging.

by toggling a pin both before and after each of the functions in the initialization I determined the problem was in my initRadio function, the fist section appears to work fine;

    PMMCTL0_H = 0xA5;
    PMMCTL0_L |= PMMHPMRE_L;
    PMMCTL0_H = 0x00;
    PMAPPWD = 0x02D52;                        // Get write-access to port mapping regs
    PMAPCTL = PMAPRECFG;                      // Allow reconfiguration during runtime
    P3MAP6=PM_NONE;
    P1MAP1=PM_RFGDO2;
    P1MAP0=PM_RFGDO1;
    PMAPPWD = 0;                              // Lock port mapping registers
    P1DIR |= BIT0 | BIT1;
    P1SEL |= BIT0 | BIT1; // PA_DRV & ~RX_TX
    RF1AIFCTL1|=RFERRIE;

toggling the pin after this still worked when the micro was hanging which would suggest the code is getting past that part however the next section of code appears to be where the micro is hanging as the pin fails to toggle after it. the code is simply filling the rfsettings struct with values that are then sent to the RF core.

  if (operating_mode == MODE1)
	{
	rfSettings.deviatn = DeviceFactoryConfiguration.RFConfig.Mode1_Config.DEVIATN_DATA.fullreg;
	rfSettings.mdmcfg0 = DeviceFactoryConfiguration.RFConfig.Mode1_Config.MDMCFG_DATA0.fullreg;
	rfSettings.mdmcfg1 = DeviceFactoryConfiguration.RFConfig.Mode1_Config.MDMCFG_DATA1.fullreg;
	rfSettings.mdmcfg2 = DeviceFactoryConfiguration.RFConfig.Mode1_Config.MDMCFG_DATA2.fullreg;
	rfSettings.mdmcfg3 = DeviceFactoryConfiguration.RFConfig.Mode1_Config.MDMCFG_DATA3.fullreg;
	rfSettings.mdmcfg4 = DeviceFactoryConfiguration.RFConfig.Mode1_Config.MDMCFG_DATA4.fullreg;
	rfSettings.sync_msb = RF_SYNC_BYTE1_Mode1;					// High part of sync
	rfSettings.sync_lsb = RF_SYNC_BYTE2_Mode1;					// Low part of sync
	switch (DeviceUserConfiguration.freq_channel)
	    {
	case FREQ_A:
	    {
	    rfSettings.freq0 = DeviceFactoryConfiguration.RFConfig.Mode1FreqData.FREQA.FREQ_0;
	    rfSettings.freq1 = DeviceFactoryConfiguration.RFConfig.Mode1FreqData.FREQA.FREQ_1;
	    rfSettings.freq2 = DeviceFactoryConfiguration.RFConfig.Mode1FreqData.FREQA.FREQ_2;
	    break;
	    }
	case FREQ_B:
	    {
	    rfSettings.freq0 = DeviceFactoryConfiguration.RFConfig.Mode1FreqData.FREQB.FREQ_0;
	    rfSettings.freq1 = DeviceFactoryConfiguration.RFConfig.Mode1FreqData.FREQB.FREQ_1;
	    rfSettings.freq2 = DeviceFactoryConfiguration.RFConfig.Mode1FreqData.FREQB.FREQ_2;
	    break;
	    }
	case FREQ_C:
	    {
	    rfSettings.freq0 = DeviceFactoryConfiguration.RFConfig.Mode1FreqData.FREQC.FREQ_0;
	    rfSettings.freq1 = DeviceFactoryConfiguration.RFConfig.Mode1FreqData.FREQC.FREQ_1;
	    rfSettings.freq2 = DeviceFactoryConfiguration.RFConfig.Mode1FreqData.FREQC.FREQ_2;
	    break;
	    }

	    }
	}
    else
	{

	switch (DeviceUserConfiguration.rf_data_type)
	    {
	case MODE2:
	    {
	    rfSettings.deviatn = DeviceFactoryConfiguration.RFConfig.MODE2_Config.DEVIATN_DATA.fullreg;
	    rfSettings.mdmcfg0 = DeviceFactoryConfiguration.RFConfig.MODE2_Config.MDMCFG_DATA0.fullreg;
	    rfSettings.mdmcfg1 = DeviceFactoryConfiguration.RFConfig.MODE2_Config.MDMCFG_DATA1.fullreg;
	    rfSettings.mdmcfg2 = DeviceFactoryConfiguration.RFConfig.MODE2_Config.MDMCFG_DATA2.fullreg;
	    rfSettings.mdmcfg3 = DeviceFactoryConfiguration.RFConfig.MODE2_Config.MDMCFG_DATA3.fullreg;
	    rfSettings.mdmcfg4 = DeviceFactoryConfiguration.RFConfig.MODE2_Config.MDMCFG_DATA4.fullreg;
	    rfSettings.freq0 = DeviceFactoryConfiguration.RFConfig.MODE2FreqData.FREQ_0;
	    rfSettings.freq1 = DeviceFactoryConfiguration.RFConfig.MODE2FreqData.FREQ_1;
	    rfSettings.freq2 = DeviceFactoryConfiguration.RFConfig.MODE2FreqData.FREQ_2;
	    rfSettings.sync_msb = RF_SYNC_BYTE1_MODE2;
	    rfSettings.sync_lsb = RF_SYNC_BYTE2_MODE2;
	    break;
	    }
	case MODE3:
	    {

	    rfSettings.deviatn = DeviceFactoryConfiguration.RFConfig.MODE3_Config.DEVIATN_DATA.fullreg;
	    rfSettings.mdmcfg0 = DeviceFactoryConfiguration.RFConfig.MODE3_Config.MDMCFG_DATA0.fullreg;
	    rfSettings.mdmcfg1 = DeviceFactoryConfiguration.RFConfig.MODE3_Config.MDMCFG_DATA1.fullreg;
	    rfSettings.mdmcfg2 = DeviceFactoryConfiguration.RFConfig.MODE3_Config.MDMCFG_DATA2.fullreg;
	    rfSettings.mdmcfg3 = DeviceFactoryConfiguration.RFConfig.MODE3_Config.MDMCFG_DATA3.fullreg;
	    rfSettings.mdmcfg4 = DeviceFactoryConfiguration.RFConfig.MODE3_Config.MDMCFG_DATA4.fullreg;
	    rfSettings.freq0 = DeviceFactoryConfiguration.RFConfig.MODE3FreqData.FREQ_0;
	    rfSettings.freq1 = DeviceFactoryConfiguration.RFConfig.MODE3FreqData.FREQ_1;
	    rfSettings.freq2 = DeviceFactoryConfiguration.RFConfig.MODE3FreqData.FREQ_2;
	    rfSettings.sync_msb = RF_SYNC_BYTE1_MODE3;
	    rfSettings.sync_lsb = RF_SYNC_BYTE2_MODE4;
	    break;
	    }
          default:
            {
               break;
            }
	    }
}

I don't really see why this would be failing, it seems pretty simple code as such I'm wondering if it could be something else, I've check the ¬reset (HIGH) and test(LOW) pins and both are as I would expect, I can see anything obvious in the errata, does anyone have any suggestion as to what might be causing the micro to hang in that section of the code sometimes?

**************************************************EDIT*****************************************************************

further testing suggests that the problem is with the ¬RESET pin, it is connected via a pullup to VCC so it should be high however If a switch is added to hold it low upon power up and then flicked high the device will never boot equally if the device has successfully booted and the reset pin is toggled the device will also hang.

over 11 years ago

0 Leo Bosch over 11 years ago

Guru 23000 points

It sounds like your stack is overflowing. Check your stack and increase the size if necessary.

0 Ilmars over 11 years ago

Guru 46710 points

george clarkson said:
RESET pin, it is connected via a pullup to VCC

Please describe your reset circuit in complete details. Reset circuit is #1 in popularity list of start-up problems.

0 george clarkson over 11 years ago in reply to Leo Bosch

Intellectual 830 points

if it was stack I would expect it to break when the debugger was attached and I wouldn't expect it to hang at the same point half the time and the other half work perfectly. however I check it anyway and no improvment

0 george clarkson over 11 years ago in reply to Ilmars

Intellectual 830 points

a basic diagram of the reset circuit is shown below, I have added an additional switch to connect to ground during testing to allow for resetting of the micro and make it a bit easier but under normal circumstances that won't be there

0 Brian Boorman over 11 years ago in reply to george clarkson

Guru 25210 points

george clarkson said:

Put the capacitor on the other side of the resistor, next to the device reset pin. Also, I believe the recommended values are ~47K and 2.2nF

0 george clarkson over 11 years ago in reply to Brian Boorman

Intellectual 830 points

changing the values doesn't appear to have helped

0 Ilmars over 11 years ago in reply to george clarkson

Guru 46710 points

george clarkson said:
changing the values doesn't appear to have helped

As Brian already told: you don't have reset circuit capacitor at all! Besides decoupling capacitor between VCC and GND you must have reset capacitor, between RST pin and GND.

0 george clarkson over 11 years ago in reply to Ilmars

Intellectual 830 points

I did move the capacitor which had no effect, however i do believe that the MSP430 actually has an internal RC circuit, and as I'm using 2 wire programming I would need to be careful how much capacitance I put on the line as the RST pin is being used as a clock signal.

0 Ilmars over 11 years ago in reply to george clarkson

Guru 46710 points

george clarkson said:
i do believe that the MSP430 actually has an internal RC circuit

R-circuit but not RC circuit.

george clarkson said:
as I'm using 2 wire programming I would need to be careful how much capacitance I put on the line as the RST pin is being used as a clock signal.

Brian told you:

Brian Boorman said:
Also, I believe the recommended values are ~47K and 2.2nF

0 Brian Boorman over 11 years ago in reply to Ilmars

Guru 25210 points

Ilmars said:

Brian told you:

Also, I believe the recommended values are ~47K and 2.2nF

[/quote]

Page 21, Figure 2-3 in the MSP430 Hardware User's Guide shows how to connect for Spy-By-Wire.

0 george clarkson over 11 years ago in reply to Brian Boorman

Intellectual 830 points

maybe I wasn't clear, the end result of what I change the circuit to is shown in the image. this didn't seem to fix the problem.

0 Ilmars over 11 years ago in reply to george clarkson

Guru 46710 points

george clarkson said:
I change the circuit to is shown in the image. this didn't seem to fix the

For testing purposes solder 100n cap in place of 2.2n to see that problem indeed is not reset-release-timing-related.

Also test with dumb-simple led blinking code running at default vcore and cpu clock is good idea. If LED blinker works but your code crashes, then it's additional info to think about

0 george clarkson over 11 years ago in reply to Ilmars

Intellectual 830 points

I will try that however, based on new evidence I think the problem is code related, I altered my initialization routine, as I realised that the function it was getting stuck in wasn't actually needed at that point, as it was called later on anyway. As I was already there I decided to remove it, doing so gave an interesting result, the code ran for about 6 seconds at which point that function is called and the code crashed. Playing around further I decided the first section (see op) would be better at the start so I moved that back to the beginning. running again caused the code to crash during the beggining steps again. This would suggest that the problem is being caused by code not hardware and that the section of code that may be causeing the problem is:

    PMMCTL0_H = 0xA5;
    PMMCTL0_L |= PMMHPMRE_L;
    PMMCTL0_H = 0x00;
    PMAPPWD = 0x02D52;                        // Get write-access to port mapping regs
    PMAPCTL = PMAPRECFG;                      // Allow reconfiguration during runtime
    P3MAP6=PM_NONE;
    P1MAP1=PM_RFGDO2;
    P1MAP0=PM_RFGDO1;
    PMAPPWD = 0;                              // Lock port mapping registers
    P1DIR |= BIT0 | BIT1;
    P1SEL |= BIT0 | BIT1; // PA_DRV & ~RX_TX
    RF1AIFCTL1|=RFERRIE;

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

strange crashing of the MSP430