SIMPLELINK-MSP432-SDK: Use of RTC and Watchdog Together in same firmware

Hello Vikram,

I have asked my colleague who has more knowledge on this topic to reply. Please give him a day to reply.

Thanks,
Sai

Thank you Sai.
I will wait for the response.

Vikram

Hi Chris,

I will look at the approach of driver library as you have mentioned.

The only reason I have to reset the system is because that is what is mentioned in the third party fatfs webpage.

FR_DISK_ERR

The lower layer, disk_read, disk_write or disk_ioctl function, reported that an unrecoverable hard error occured.

Note that if once this error occured at any operation to an open file, the file object is aborted and any operations to the file except for close will be rejected.

Since this issue occurs when the MCU tries to open the already compressed file in the SD card to send to another device on board I even tried to come out of this loop when such error occurs and let the unit go into deep sleep mode where I am making all GPIO line as output and low.

This even makes the SPI lines to output and low and once the device wakes up before any operation I reconfigure the line related to SPIB0 to the SPI functionality.

But even this approach does not allow to open the new file to write even data into it.

The option of reading entire content of the file in the SD card and then compressing is not feasible is not possible because the size of file that is generated is 67kB and it is not possible to compress entire 67KB in one go due to memory constraints.

So what i do is I open the file take 512 bytes from that and compress it and create another file. This continues until entire file is compressed.

This creates around 39 kB of file.

Once this is done only then I open the connection of SPI to the another MCU to transfer the data again chunk by by (170 bytes at a time as that is the max due to another devices limitation)

Vikram

Also I am not 100% aware about using the ResetCtl concept. Is there any example that I can refer to?

Vikram

In the resource explorer:

dev.ti.com/.../

Chris

Thank you Chris for the link.

I have gone through this option but isn't this for Non RTOS whereas my software is based on RTOS?

So will this matter or I have to simply use the "MAP_ResetCtl_initiateHardReset" API as I don't have any external source to initiate hard reset?

Vikram

Additionally, I tried the MAP_ResetCtl_InitiateHardReset API, but even after resetting it does not get rid of the FR_DSK_ERR issue.
I though that if the unit is reset everything would resume from the main program where I initialize the SPI and SDSPI both.
So, why would this happen?

Vikram

Vikram,
Previously, you mentioned that by resetting the board you could get rid of the FR_DSK_ERR. Is it possible that the error is not coming from the MSP432 and from the SD card?

What devices are impacted when you reset the board?
Do you have any way to reset other devices (via GPIO) from the MSP432?

Regards,
Chris

Hi Chris,

You are that earlier if I reset the board manually it would get rid of the error.
I am not sure how to verify if the issue comes from the SD card and not from MSP432. Since, I have tried different make of SD cards but got the same results.
I am trying to concept on the simple fatfsraw example in which I am turning off the LDO before unit goes into sleep and then turn on the LDO after unit wakes up, rather than keeping the SD card always powered up.
At present since the example I am trying is simple fatfsraw it don't have any other devices to check.

You may be right about the fact that it might be the issue of SD card because if I keep the LDO always on this issue is not arising.

But this leads to the fact that even in camera's we use SD cards and and the camera is never kept always on. You turn off the camera after using it so it means that SD card does not have any power supplied and only once camera is turned on, sd card gets power so than how come that works and not in my case since I am also providing power to SD card through LDO which is turned on and off whenever required.

I am not sure how to find the root cause and how to overcome with a solution.

Vikram

Vikram,
Since you are not seeing the issue when the LDO is always on, it sounds like you have isolated the issue to the transition between states. I would look at the SPI lines during the transition to see if there is some contention on the lines. Perhaps it is a question of the power up/down sequence between the devices.

Chris

Hi Chris,

What do you mean by contention on the SPI lines?

The challenge is the I can't even put lines on the Logic analyzer since the traces are under the SD card which gets mounted in the SD card reader on board.

Is there any way that I can check that in software or checking the registers?

Vikram

Vikram,

   I have not been able to locate any additional information for error checking outside of the two bits found in the status register.

Chris