SIMPLELINK-MSP432-SDK: Firmware executes fine in Debug mode but not in Run mode

Hi Bruce,

Thank you for replying.

Yes every time the RTC wakes up the device, before it sends signal to uPulser to take a shot, I am waking up the SD card using and a LDO which is enabled using GPIO.

How do I find that the SD card is getting enough time or not ( as you mentioned 100 msec or so) while I execute the firmware in run mode?

Please give some suggestion.

Also why is the USART operation interrupted if the SD card is not able to do its functionality? Does it crashes the firmware if SD card cannot function?

And why would this not happen in watchdog based application and only happens when i use the RTC based approach?

Vikram

FatFs example based on new SDK.zipI am also attaching the code for your reference probably you might be able to find why the SD card would give FR_DSK_ERR when unit wakes up after sleep and tries to create a new file.

Thank you

Vikram

        /* In debug mode meaning having the JTAG cable connected if I execute this function works fine and opens SD card.
         * It takes a shot and saves onto the file  every time the unit wakes up. Wake up time is 2 minutes for now to test.
         * But if I run the firmware as it is straight from the power switch without having the JTAG connector, it fails at this point.
         * You can verify based on the LED toggling part below.
         * */
        //logFile = "/log/testShot.txt";
        //sprintf(logFile, "/log/testShot.txt");
        //sprintf(logFile, "/log/testShot.txt");
        //fresult_log = f_open(&dst, logFile, FA_CREATE_ALWAYS|FA_WRITE);
        fresult_log = f_open(&dst, logFile, FA_OPEN_ALWAYS|FA_WRITE);
        if (fresult_log != FR_OK)
        {
            for(msdump = 0;msdump<3;msdump++)
            {
                GPIO_toggle(Fogwise_Board_LED_D2);
                usleep(250000);
            }
            System_printf("Error opening \"%s\"\n", logFile);
            System_flush();
        }
        else
        {
            for(msdump = 0;msdump<3;msdump++)
            {
                GPIO_toggle(Fogwise_Board_LED_D1);
                usleep(250000);
            }
        }
        probeRunMSAG();
        for(dump = 0;dump<6;dump++)
        {
            GPIO_toggle(Fogwise_Board_LED_D1);
            sleep(1);
        }
        /* Now say in order to verify weather UART works even in run mode I comment out the statements related to sdcardFileOpenWrite(logFile).
         * Doing so in the debug mode it runs the probeRunMSAG(); function completely and then toggles the led as above and closes the handle
         * as below.
         * But if i run it directly from power switch without the JTAG connector. it will toggle the LED as above but crashes while closing the
         * SDFatFs_close handle.
         * */

Pulser_radio based on SDK2.10 working.zip

Hi Amit,

I tried the solution that you provided and also installed new the SDK 2.10 and CCS version.

Ok now if I keep the LDO1 always( this is teh one that powers the SD card) then even after wake up new files are created and data is written to it.

But if  I turn off the LDO and again turn it on before opening a new file or opening the SDFatFS handle it does not create new file and gives FR_DSK_ERR.

I have verified that the GPIO functions as expected still new file is not created.

Secondly, as I have mentioned in this post that my firmware works fine in the Debug mode but not in the run mode.

I am also using the NVS concept to store the data in NVS flash so that if in case the unit power cycles it has its previous information.

For some reason, the NVS_write function is creating an issue in the Run mode and not in the Debug mode.

I confirmed this by uncommenting NVS_write function I have called and then executed the firmwaer in Debug and Run mode seperately.

And the surprising this is that the file opening part i.e. new file opening for writing is called before even this NVS_write function is called still we are not able to understand why would a later function impact something that is done before it.

I will attach the code for your reference if you can see through the flow if something that i am doing with the RTOS implementation incorrectly and let me know would be great.

Hope to get response from you for some troubleshooting atleast.

Once again thank you for all your support.

Thank you

Vikram

Hi Amit,

thank you for response.

Yes the NVS_write function is related to MCU and not to SD card.

In Run mode if i don't shut down the LDO then yes it writes new file everytime.

Vikram

Hi Amit,

So what do you suggest me trying?

Should I try and increase the time between LDO powered up and SD card access function and see at what time does it not fail? Or is there something else I can try if you suggest?

Also I believe as per the documentation that opening a SDFatFs handle is not related to SD card access fucntion. Is it correct?

Because even if there is no SD card in the SD card reader slot still the opening of the SDFatFs handle is successful.

Thank you

Vikram

Hi Amit,

I tried adding further delay of 5 seconds and still the situation remain the same.

Checking the register values I found that for some reason the value of the GPIO that is used as SD card CS P8_0 turns to high as soon as the sdFatFs handle is opened successfully.

Should not this remain low since the CS line for SD card is active low?

Adding the delay is not making any difference

Also I have debug the firmware and noted down the status of the elements of the FIL structure before and after opening the file.

I have done that with and without the LDO being turned off.

And the situation shows before and after the sleep mode wake up stats.

Please find the excel sheet attached.

I am not sure how to explain in words but I see that the value of the elements don't change when I try to open the file after wake up (if LDO was turned off in sleep mode)

Hope to hear soon from you.SD card element values while ldo is off and on.xlsx

Vikram

Hi Amit,

Yes you are rignt it is the third party component.

I tried to look into the Fat File system site but did not get any feedback.

Since TI has the demo firmware which is based on fatsdraw which uses third_party/fatffs library I though you might be aware about it.

Hi Amit,

Thank you for the reply.

Ok I will try with the append mode too to just check it.

The point that surprises me is that even the watchdog  based firmware is not able to open the file and returns FR_DSK_ERR. In the watchdog based code, I am not evening putting the unit into deep sleep it is only in sleep mode.

And the same firmware works with version 1.40 of SDK but not with version 1.60.

I will attach bot the version of firmware and you can see that there is no difference except the SDFatFs driver related functions those are used.

watchdog based for 1.40.zipwatchdog based for 1.60.zip

I will try the append option and see and check for the current supplied to the SD card once LDO turns on after waking up from sleep.

Vikram