Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by madvoid

  1. Hi All,

    I am currently building a datalogger with an MSP430FR5969, and I have run into a bug that has completely stumped me. I will try to explain the problem clearly. The main code I am referring to can be found on Github here.

    My datalogging code follows a specific flow. After the MSP430 is turned on and the watchdog timer is turned off, the uC will wait for the user to press a button, signifying the logging period. The data logger will then read the time from a real time clock, and then set the RTC alarm for the next even 10 second value (10, 20, 30, etc.) and go to sleep. When the 10 second value arrives, the RTC wakes the uC from sleep, the uC takes some readings, sets the RTC alarm to fire at 10 seconds from now, and goes back to sleep. This process repeats until the user tells it to stop. I wrote all of this before adding any code for the SD card so I can make sure the general flow of the program is correct. The code snippet below, shows the very first iteration of this process.

    MLX90615Sleep();                      // Put MLX to sleep
    DS3231GetCurrentTime();               // Get current time
    DS3231ClearAlarm1Bits();              // Clear alarm bits
    DS3231SetAlarm1Round10Sec();          // Set alarm for nearest 10 second value-ish
    DS3231TurnAlarm1On();                 // Turn on alarm
    i2cSetReset();                        // Reset I2C so LPM is achieved
    __bis_SR_register(LPM0_bits);         // Enter LPM0
    P4OUT |= BIT6;            // Red LED debug
    DS3231GetCurrentTime();               // Get current time. Should meet (seconds % 10 == 0) cond. at this point
    DS3231SetAlarm1Plus10Sec();           // Set alarm for +10 sec
    P1OUT &= ~BIT0;                       // Turn off green light
    P4OUT &= ~BIT6;           // Red LED debug
    P1IES |= BIT1;                        // Enable interrupts for P1.1 Button
    P1IE |= BIT1;
    i2cSetReset();                        // Reset I2C so LPM is achieved

    The code above works just fine when the SD card code isn't added. However, as soon as I add the SD Card initialization code (see here), the uC will get stuck in whatever line comes right after __bis_SR_register(LPM0_bits) line above. I have tried several different lines after that line, and it will always get stuck there which makes me think that the microcontroller cannot exit low power mode.


    Here is my thought process when debugging:

    • My first thought is that the RTC is failing to wake the microcontroller from sleep. I have the uC to wake up on a falling edge, and the RTC drives the line low when the alarm fires so I thought that there might be a communication problem. Attached are two screenshots from my logic analyzer of the interrupt signal when it is working and not working. As you can see, in the working code the RTC drives the line low at once at the beginning and again at regular intervals, while in the not working code the line gets driven low but never comes up again. This makes me believe that the program is hanging in the interrupt, because I tell the RTC to bring the line back up after I exit LPM (which happens in the interrupt). It also shows that the signal that would wake the uC up (high to low transition) does happen.
    • I don't think this is a hardware problem because the thing that causes the bug is simply adding a few lines of code.
    • The SD card is using the eUSCIA module, while all the I2C sensors are on the eUSCIB module - I would think it's unlikely that my SD card code messes up the sensor communication. In addition, I have tried my real time clock alongside my SD card in other code and it seems to work fine.
    • The I2C communication is identical before the uC goes into sleep mode (other than the times read from the RTC of course). The comparison from logic analyzer can be seen here if you are curious.
    • The other thing I thought could be the problem is a stack overflow. I increased the stack size in CCS but that didn't change anything. I don't know how to change the stack size from the linker file, especially for a FRAM product. Is it possible that this is due to the stack size? If so, what can I do to increase the stack size? The MSP430FR5969 has a lot of room in FRAM and 2kB in SRAM.
    • The SD card and the sensors I'm currently using all work independently of each other.
    • I am using FatFS and the only platform specific code in it is the diskio.c file. As far as I can tell, the code doesn't use any interrupts (is it possible to use interrupts without a handler?) but it does turn them on and off (see here). However, since it restores it to the same state, would that really affect anything?

    I apologize for the wall of text but I'm at a loss and I wanted to provide as much detail as possible. I'd be happy to provide more code or detail, or answer any questions that people have if I can.

    Slightly unrelated, but people are free to use my sensor code for the FR5969 if they want. I've gotten the BMP180, SHT21, DS3231, and the MLX90615 working. It can be found here.

    Thanks in advance for any help!

    - NG 



  2. Hi Greeeg,


    That did the trick! Thank you very much, I don't know if I would have caught that in a million years! Quick question to help me understand your fix: Does setting the UCSWRST bit reset the USCI module, even if it has already been set?


    To anyone else reading this thread, I've updated the code in my Github which means the links in my original reply to Greeeg now point to the correct version.


    Thanks again!


    - NG 

  3. Hi greeeg,


    Thank you for your quick reply! I'll explain what my problem is below, you may have some insight into what is going wrong.


    A few months ago I got FatFS working on the TI Tiva launchpad thanks to code that I found online. Now that I switched to the MSP430FR5969, I thought I would go through and change the SPI drivers as you said. All the platform specific code should be in diskio.c, visible here. I also wrote the main function which mounts the SD Card and attempts to open a text file and append some text to it. You can view it here.


    My problem is this: The main function will mount the SD Card just fine. However, when I try to open the file using f_open, the code hangs via the following path: f_open -> find_volume -> disk_initialize -> send_cmd -> wait_ready -> rcvr_spi. In rcvr_spi(), the code hangs on line 110:

    while(!(UCA1IFG & UCRXIFG));    // Wait for RX buffer

    Since it was having trouble simply receiving, I thought the issue might be hardware. However, the card works fine when plugged into my computer, and it is also the same card I used when testing with the Tiva launchpad. I also double checked my connections, which are as follows:

    SPI_SOMI: P2.6
    SPI_SIMO: P2.5
    SPI_CLK: P2.4
    SPI_CS: P3.4

    These should connect the SD card to USCIA1 on the MSP430FR5969. Do you think there is a problem with sending the initial clock train that should put it into SPI mode? That was the one thing I could think of but I'm not sure.


    Thanks again for your help, I appreciate it greatly!


    - NG 

  4. Hi All,


    I'm attempting to get an SD card working with the MSP430FR5969 (launchpad) and FatFS but I'm having a difficult time. Two questions:


    1. Is it possible to get FatFS working with the MSP430? When I did a search of these forums I mostly saw PetitFat being used with MSP430s. Ultimately, PetitFat would be okay but I would prefer FatFS.

    2. Has anyone gotten either PetitFat or FatFS working with the MSP430FR5969? If so, would you be willing to share your code or knowledge regarding it?


    Thank you in advance for any help,


  5. @@bobnova & zborgerd


    Thank you for your reply! To answer both of your questions at once, I did try to update the EZ-FET firmware on the Launchpad by first pulling the libmsp430.so from energy, and then running mspdebug --allow-fw-update tilib. I even ran it three times as outlined here but each time it did not work, and did not let me upload.


    I may try to compile the MSP Debug Stack for mac, but I do not know how successful I will be.


    Thanks again!

  6. Hi all,


    I've been lurking for a while but I finally joined up! I recently received the MSP430FR5969 FRAM Launchpad with EnergyTrace, and I'm trying to upload code to it with OS X 10.9.4 and mspdebug. I am successfully able to upload code to the standard Launchpad with the MSP430G2553 but I cannot upload to the FRAM Launchpad. Looking at this makes me think that a work around has not been found yet, is this true? Or has someone gotten the new FRAM Launchpads working with OS X?


    Thanks in advance for any help!

  • Create New...