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

Are you waiting for the SD card to power up? I don't have my books here, but I seem to recall it could take 100 msec or so.

Running with the JTAG, the SD card has plenty of time to start up while the debugger is doing its things.

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

Hi Bruce,

I even tried adding delay of 100 ms after powering up the SD and before performing any functions related to SD card.
Still the result is the same.

Vikram

One major difference of course, is that there is a long delay while it sits at the first line of main().

Have you tried putting a delay there?

Is there a difference in optimisation level? Make sure that all variables shared between interrupts and non-interrupts are marked volatile.

Sorry I did not get what you meant by first line of main()?
Do you mean to say that when I execute in debug mode, the compiler adds a long delay at the first line of main() and so I should add a long delay at first line of main() if I want to execute in run mode without debugger?

The optimization is kept to "Off" as of now.

What I am not able to understand that executing the firmware in run mode using the watchdog timer approach does not create this issue but using the RTC approach to wake up the controller is causing the issue.

What difference doe s it makes in terms of waking up the unit and impacting the sd card FatFs functionality if I use RTC as against to Watchdog Timer?

The reason I cannot use Watchdog since it does not allow the deep sleep mode which is only possible if RTC is used.

Vikram

Exactly. Put a delay as the first line of main in your program. A true engineer would set it to the length of time he takes to click the continue button. 8^).

Hi Keith,

This solution does not work I even tried adding a delay of 3 seconds but still the situation is same.
Can someone please answer why this issue does not arise when I use the Watchdog approach but arises only when RTC approach is used to wake up the device?

Vikram

Ok I will try that Amit.
Thank you for the response.

Just to confirm does it means there is issue with the previous version of SDK ?

Vikram

Hello Vikram,

It could be an issue in the previous versions as Power Drivers were added and functionality of the SDK was improved.

Hi Amit,
the sample firmware file that you sent does it opens a new file after unit wakes up to write to it?
Because i don't see any where in the firmware it opens a new file to write to it.
I tried the concept by installing new CCSv8 and SDK 2.10 but after wake up from RTC even though the UART wakes up still no new file is written in sd card infact sd card fails to open new fiel

The function does not open a new file after unit wakes from sleep mode and returns FR_DSK_ERR

With the new CCS v8 and SDK 2.10 still when the unit wakes up after sleep mode, and firmware tries to open the new file using f_open it fails stating FR_DSK_ERR

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

Hello Vikram,

The firmware I attached was tested with an SD Card. The only difference I see from your code is the fact that there is a power up sequence for the LDO to the SD Card which I do not have (and I had clearly highlighted that in my post). For simplicity, I will merge this post with the existing post where I provided the code.

        /* 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,

While debugging an additional information i found probably might be handy for you to get to a solution is as below.
In the Run mode, when I execute without having the JTAG cable connected i.e. through battery supply, the firmware crashes and throws and exception. this is not observed when executed in debug mode using JTAG connector.

I found that the exception is thrown when the firmware tries to open a file to write the data into it.
f_open function calls, find_volume function.
find_volume in the ff.c file calls below lines
#if FF_FS_REENTRANT
if (!lock_fs(fs)) return FR_TIMEOUT; /* Lock the volume */
#endif

And it is the lock_fs function which calls the "ff_req_grant" and we are getting an exception after lock_fs.

So we are not able to understand why a Run mode behave differently than Debug mode in respect to lock_fs.

Please provide your input.

Vikram

Hello Vikram,

The NVS_write function you refer to here is the NVS Storage on the MCU and not the SD Card? Is that correct?

Secondly, if you do not shut down the LDO for the SD Card does it work in RUN mode?

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

Hello Vikram,

First things first. Can you add timing delay between LDO power Up and SD Card access to ensure that power is stablilized before access. Simplest way would be to tart with a 2 sec delay and reduce it till there is an error. Then check the power ramp w.r.t to the SD Card access on a scope.

Okay I will do that and test it and let u know
thank you

Hi Amit I added 2 seconds of delay between waking up of device and opening the SDFatFs handle which is just before the opening of file. Still I get the same error

Hello Vikram,

Can you make sure that the file handle is closed and only then the LDO for the SD Card is powered down?

Hi Amit,

Yes I confirmed that the file handle is closed before I shut down the LDO for SD card.

Hello Vikram,

So what is the shortest time between the LDO powered up and the SD Card access that works. I know you have tested 2 sec, but what we want to ascertain is that is it a function of power up time or is there something on the IO which may be causing an issue!

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

Hello Vikram

Yes, that is what I would like to test first. The Opening of the SD Handle does not have an access to the SD Card. Since I do not have an equivalent setup, the debug needs to make sure that we can ascertain if there is anything to do with the power down-up sequence.

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

Amit some additional information that I found may be useful as below.

In my code, which has two thread running based on priority.
In one thread, I open a file and into this file the data received from the uPulser is written for example file V0000000.txt.
Once the data is written I close the file. this file is approximately 67 kB.
So when I close the file I see the dir_ptr changing to 0.

Next in the same thread I am compressing the data in that file to create a new compressed file.
for that, I first open the file V0000000.txt (so the dir_ptr changes to the address which is required) read chunk of data from that file into a buffer and close the file (the dir_ptr changes to 0).
Then I compress the chunk of data which results in another buffer of data.
Now in order to create the compressed file, I create new file say C0000000.txt and open that file and write the data from compressed buffer into the file and close the file.But when the file is closed the ptr for dir_ptr for this file C0000000.txt does not change to 0 but instead stays as it is.

The above process is repeated until entire 67kB of data is compressed and it results in approx 37kB of compressed file.

I am not sure if this is something that you can pls look into.
Am i doing something wrong in the process?
Vikram

Hello Vikram,

I am not sure about what the dir_ptr is? If it is something from the FAT File System, then it could be a third party component, that you may need to check at the FAT File System site; to see if there is a known issue.

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.

Hello Vikram

Were you able to reproduce the issue with the fatsdraw example? If, yes then debug is possible at our end.

Yes even with fatfsraw example if i turn off the LDO and turn it back on after waking up from sleep it was not able to write a new file and returns FR_DSK_ERR

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

Hello Vikram,

I am using the SDK version 2.10 (which is the current).

I had tried that even. The reason why I sent both 1.40 and 1.60 is because the issue starting arising since I had moved to SDK 1.60 and the same issue continues in 2.10.
Also you mentioned that you are using the FA_OPEN_APPEND mode but in the ff.h file I don't see the macro for FA_OPEN_APPEND. I see that the FA_OPEN_APPEND macro is only in ff.h which is installed in SDK 2.10.
And one more query the fatfsraw.c file that you sent I see that you don't enable and disable the Chip Select line (CS) to select the SD card. I mean in my firmware I am using same SPI lines (SPIB0) to communicate with SD card and another MCU and both are on the same board.
The way I grant access to each of them is using the CS line (P8.0 for SD card & P5.0 for another MCU).
Will this be causing issue?

Hello Vikram,

Yes, I am no longer using FA_OPEN_APPEND anymore since I wanted to control the append of data to the read file by moving the file pointer. The enable/disable of the SD CS is handled by the SD Card driver.

const SDSPI_HWAttrs sdspiHWAttrs[MSP_EXP432P401R_SDCOUNT] = {
{
.spiIndex = MSP_EXP432P401R_SPIB0,
.spiCsGpioIndex = MSP_EXP432P401R_SDSPI_CS
}
};

where MSP_EXP432P401R_SDSPI_CS is mapped in the GPIO_PinConfig gpioPinConfigs[]