This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Basic Wifi with mod - S2 overwrites program space?

Other Parts Discussed in Thread: MSP-EXP430FR5739, MSP430FR5739

TIA for any help.  I'm new to this chip and toolset (IAR).

I'm using CC3000EM with MSP-EXP430FR5739.  I'd like to just transmit packets at various rates.  I started with the Basic Wifi Application code and changed main like is done in here: http://processors.wiki.ti.com/index.php/CC3000_Transmitter_Testing_Using_RAW_Socket

I've also handled the S1 button press to toggle different standards and rates. I also removed the UART handling.

As you know if you've used this hardware, the S2 button grounds the WLAN Enable line to the CC3000.  No problem, I don't need it.  If you push it,  program gets hung waiting for interrupts that'll never occur.  That's fine.

The strange thing is that if I press it, my program gets hosed .  Even a reset or power cycle will not work.  I have to download new code to get it to work again.

I assume somehow this is causing a wayward write into FRAM?  Is this something that's easy to do?  Not even sure how to begin debugging this one.  I guess I'll try to dump new and hosed images?

I can paste code it it'll help. Thanks.

  • NIcholas Schmidt said:

    TIA for any help.  I'm new to this chip and toolset (IAR).

    I'm using CC3000EM with MSP-EXP430FR5739.  I'd like to just transmit packets at various rates.  I started with the Basic Wifi Application code and changed main like is done in here: http://processors.wiki.ti.com/index.php/CC3000_Transmitter_Testing_Using_RAW_Socket

    I've also handled the S1 button press to toggle different standards and rates. I also removed the UART handling.

    As you know if you've used this hardware, the S2 button grounds the WLAN Enable line to the CC3000.  No problem, I don't need it.  If you push it,  program gets hung waiting for interrupts that'll never occur.  That's fine.

    The strange thing is that if I press it, my program gets hosed .  Even a reset or power cycle will not work.  I have to download new code to get it to work again.

    I assume somehow this is causing a wayward write into FRAM?  Is this something that's easy to do?  Not even sure how to begin debugging this one.  I guess I'll try to dump new and hosed images?

    I can paste code it it'll help. Thanks.

    Hi Nicholas,

    You should never press the S2 button when the CC3000EM board is plugged in and you are running the Basic WiFi application. This button will force P4.1 to ground, while it is being configured as an output and set to high by the MSP430FR5739 MSU. This could really damage the MCU, since you are definitely exceeding the maximum current allowed by shorting a high pin to ground.

  • Thanks Ivor,

    I can see now that this is the case. Seems TI should not recommend these two together when pressing a button could damage the MPU.  I intend to use this combo for demonstrating my product.  I see no other solution but to remove the button.

  • NIcholas Schmidt said:

    Thanks Ivor,

    I can see now that this is the case. Seems TI should not recommend these two together when pressing a button could damage the MPU.  I intend to use this combo for demonstrating my product.  I see no other solution but to remove the button.

    Yes, you are right. The designers of the CC3000EM board should have never used P4.1 for VBAT_SW_EN. This port was intended as a user input by the FRAM Experimenter's board designers.

    If you don't want to get rid of the S2 button there is something else you can do, if you are willing to loose the ability to reset the CC3000 through software. Take a look at the schematics of the CC3000EM board. You will find that if you remove the R5 jumper, VBAT_SW_EN will still be pulled to high by the R7 pull up resistor, provided that J3 is kept closed. Then you can go ahead and modify the basic WiFi application not to configure P4.1 as an output and use it as an input for something else. If you do this, the only way to reset the CC3000 will be by cutting power to the entire board.

    On the other hand the CC3000 firmware has many bugs and require frequent resets, so being able to reset it through software might become important for you in the future. In my device I have to reset it all the time because of two separate bugs in the CC3000 firmware.