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.

TI-RTOS FatSD example not working on MSP430F6736

Other Parts Discussed in Thread: MSP430F5529, MSP430F6736, MSP430F6736A, MSPWARE

Hi,

I have updated TI_RTOS FatFs examples given for MSP430F5529 launchpad to work in MSP430F6736. But only the "FatSD Raw" example works properly. In the "FatSD" example the RTOS get fails at "fopen" function. After the function TI_RTOS is doing nothing in the logger  view. I have used CCS6.1.0 compiler version TIv15.12.1.LTS, XDCtools version 3.32.0.06_core and TI-RTOS for MSP43x  version 2.16.0.08.

  • Are you using the external SD Boosterpack or something else?
  • Hi Todd,

    This is a custom board, with MSP430F6736A MCU and a microSD Card reader on it connected over SPI.

    The following are tested as working:
    1. FatFS in normal C (no RTOS whatsoever);
    2. Raw FatFS with TI-RTOS as used in the "FatFS Raw" example given for MSP430F5529 MCU.

    This doesn't work:
    1. FatFS using POSIX style "fopen" as mentioned in "FatFS" example for MSP430F5529 MCU.
    This one seems to hang at fopen, although SDSPI_open is successful (pointer isn't null after open).

    Since absolutely everything else is same (same board files, same RTOS config and same amount of stack/heap, etc), is there something else that we need to take care of too, in order to use the FatFS component in the style of "fopen", etc?

    Regards,
    Nirmal
  • Did you make any changes to the SDSPI driver, namely changing the sector size (SD_SECTOR_SIZE) ? I've seen this type of problem when the sector size is below 512. Note: 512 is the minimal support value: elm-chan.org/.../appnote.html

    Did you try different SD cards? We seen issues on a different device with a handful of SD cards. I doubt that is it since the raw works.

    You mentioned FatFS in normal C w/o an RTOS....is this the same FatFS that is in TI-RTOS or a different one?

    Todd
  • One other point...the stack size will not be the same. The fopen call uses more than the raw. Can you check in RTOS Object Viewer's (ROV) BIOS->Scan for Errors to see if any stacks are blown (or other issues are present)?

    Todd
  • Did this get resolved?

    Todd
  • Hi Todd,

    We tried with increased stack size, but still the problem exists. Changing the SD_SECTOR_SIZE will require recompilation of RTOS itself, so we are not considering it yet. I am attaching the screenshot of ROV that we got when it hangs. Please let me know whether these errors related to our problem.

  • Hi,
    I'm sorry. I forgot to mention about the stacksize used. Earlier the stack size used was 768 and now we doubled it.
  • Can you increase the ROV window since to get the complete message? It looks like there is some problem with the semaphores. Can you go to Semaphore view. Are these your semaphores or the kernels?

    Also, can you answer these previous questions:
    Did you try different SD cards? We seen issues on a different device with a handful of SD cards. I doubt that is it since the raw works.

    You mentioned FatFS in normal C w/o an RTOS....is this the same FatFS that is in TI-RTOS or a different one?
  • Hi Todd,

    I'm answering this as a co-worker.

    We will get back with expanded ROV messages soon.

    To answer your other queries:

    1. Yes, we have tried 3 different SD Cards, just in case, although the fact that only one configuration isn't working, shows that the issue shouldn't be hardware;

    2. FatFS w/o RTOS was adapted from another TI example - "MSPWare_3_30_00_18/examples/boards/MSP-EXP430F5529/MSP-EXP430F5529_UE_Demo_Software/Firmware/Source/FatFS". We understand that adapting the original FatFS from scratch may be error prone to start with, and hence, started everything based on working examples provided by TI.

    Thanks a lot for your help so far. We will get back with the expanded ROV messages.

  • Hi Todd,

    Sorry for the delay.

    Attaching the expanded ROV message herewith. I think this is sufficient.

  • Hi Todd,
    We havn't used any semaphores. Those are Kernel's semaphores only.
  • Sorry, this fell of my radar. This looks like memory corruption. What does ROV look like before you do the fopen?

    Todd