• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 98 subscribers
  • Views 2882 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RTOS migration: fatfs "hard error occured..." every 32 seconds

Isaac Abbott
Intellectual 805 points
Other Parts Discussed in Thread: F28M36P63C2

I recently migrated from TI-RTOS 1.10.0.23 to 1.20.0.28 and a new problem manifested itself.

I have been using the FatFS module quite successfully and error-free in RTOS 1.10.

When I switched to RTOS 1.20, I started noticing occasional f_open errors. I wrote a test application that simply attempts to write to the SD Card 10x/second (open-write function attached), and discovered that every 32 seconds there is a 1/2 second period of time when the file is inaccessible. (My test problem is always successful 315 times, and then fails 5 times, and then successful 315 times and then fails 5 times, etc).

During this period of time the f_open function returns 1: A hard error occurred in the low level disk I/O layer.

I reverted back to RTOS 1.10 and the problem went away.

1882.2146.SaveParameters.txt

  • 0
    Intellectual 805 points

    I am using the F28M36P63C2 with TI Arm Compiler 5.1.3

  • 0
    TI__Mastermind 20480 points

    Isaac,

    this is very weird. I took a quick look at the driver and not much has changed, at least nothing that should affect the performance.

    Are you using the nonInstrumented SDSPI library, if not can you see the same error with it?

    I'm trying to determine where in f_open (within the FatFs module) you could be getting a "FR_DISK_ERR" return code.

    Can you describe your setup and post your .cfg file so I can reproduce this problem?

  • 0 in reply to Tom Kopriva
    Intellectual 805 points

    Tom,

    Thanks for your response. Yes, this seems strange to me, too. Unfortunately for debugging, we are running a full system, using many different components of RTOS and/or MWare drivers: USB, EMAC, I2C, SPI, EPI, GPIO, DMA, IPC. It is also a multi-threaded system. It could be a change in one of the other modules that is causing the funny behavior. 

    Our system is using the C28 to collect and process data. The processed data is passed to the M3 for packetization and transmission to the PC (USB or Ethernet). The M3's primary role is communications, but it also takes care of other tasks like storing parameters and logging items to SD card, temperature readings, LED manipulation, and a few other GPIO.

    Probably the next step is to strip everything out of the system except SDSPI and see if the problem persists. If it goes away we can add things back in until it shows up again. 

    I did verify that this is time-related issue (not number of read/writes to SD card), by altering number of times I attempt an f_open/f_write each minute.

    What next steps do you suggest? What other information should I provide?

    0842.main.cfg

  • 0 in reply to Isaac Abbott
    Intellectual 805 points

    I have attached an example project for the ControlCard that demonstrates the failures. I stripped almost everything out of it except for 1 task and the SDSPI module.

    Isaac

    4478.FailedSaveProject.zip

  • 0 in reply to Isaac Abbott
    TI__Mastermind 20480 points

    Isaac,

    thanks for the test case! I'm seeing the failures too and will look into what's going on here. I'll get back to you!

  • 0 in reply to Tom Kopriva
    TI__Mastermind 20480 points

    Isaac,

    turns out it's a bug that I introduced when I worked on the timeout protection in the driver. This will be fixed in the next release of TI-RTOS, but here's the fix you'll need if you want to move to TI-RTOS 1.20. Thanks again for the test case, I'll be adding it to our regressions.

    Replace the attached SDSPITiva.c into C:\ti\tirtos_1_20_00_28\packages\ti\drivers\sdspi\ and rebuild TI-RTOS drivers.

    c:\ti\tirtos_1_20_00_28>..\xdctools_3_25_04_88\gmake.exe -f tirtos.mak drivers

    2352.SDSPITiva.c

  • 0 in reply to Tom Kopriva
    Intellectual 805 points

    That's great, Tom. Thanks for the quick response.

    I rebuilt the TI-RTOS drivers using newer compilers: c2000_6.2.4, arm_5.1.4, and msp430_4.2.3 (by changing tirtos.mak file) just like you suggested.

    I also noticed that a newer version of TI-RTOS (1.21.00.09) has been released. Does this bugfix apply to it as well.

    ~Isaac

  • 0 in reply to Isaac Abbott
    TI__Mastermind 20480 points

    Isaac Abbott said:
    I also noticed that a newer version of TI-RTOS (1.21.00.09) has been released. Does this bugfix apply to it as well.

    Probably not. I'd use this fix for now until our next patch or major release (mid-end March).