• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 345 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C1294NCPDT: TM4C, TI-RTOS, FATFS Query

richard payne
Genius 4640 points
Part Number: TM4C1294NCPDT

I'm working on FATFS demo code for LaunchXL TM4C1294 where I made a botch SDCard card with soldered wire to the DIL header (see picture). It worked fine.

I now studying the code and do changes to be integrated into other projects (RTOS). I just starting to read how to append data to the filename every 100mSec. 

I managed to track it down in the code library and identified FATFS which is 0.11a version which is 2015 release. The most recent is now 0.14a. I note in the changelog (R0.12a) that there is an append feature added so I'm looking to upgrade to R014a. 

R0.12a (July 10, 2016)
....
Added a file open method FA_OPEN_APPEND. An f_lseek() following f_open() is no longer needed.
Fixed compilation fails at some configurations, _USE_FASTSEEK and _USE_FORWARD.

....

Grasping some straws, Is there any warning or issue I need to be aware of while doing these changes from R0.11a to R0.14a?, would there be any side effects to be aware of?

I also note the ramdisc.c is 512 byte, what does this mean, can it be populated until nearly full and then do append to the filename or discrete append to the filename?

What the maximum SPI clock to be used. I hear many issues, why demo use 400KHz?

Thanks. 

  • 0
    TI__Guru*** 134975 points

    Hello Richard,

    The FATFS code provided in TivaWare is a third party resource so our support ability is pretty limited as our expertise is with TM4C peripherals. That said, I would not expect there to be any 'side effects' of making those changes, I think it would be more a matter of due diligence to make sure that all the changes are applied properly both to the source code and the application code. 

    richard payne said:
    I also note the ramdisc.c is 512 byte, what does this mean

    I could not find this file in TivaWare - was that a mistaken name or maybe it was a variable?

    richard payne said:
    What the maximum SPI clock to be used. I hear many issues, why demo use 400KHz?

    I am not really sure why 400KHz is used but my first guess is that it would help with poor SPI routing on EVMs and such. I would recommend that if you are in a demo on EVM hardware phase to stick with what works speed wise and then if you get a PCB built with good SPI routing, you can try and push the pace. A lot of what I saw for SD cards not working at MHz range was people saying traces probably impacted that.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Genius 4640 points

    The 512 is page size in SDCARD and hence recommended to read/write 512 byte page rather than discrete data for speed and relibaility.

    The 400KHz is done by TI firmware to meet SDCARD protocol when first mounted then it switches to 15MHz. It is a strange implementation in TI firmware but it works this way. 

    I check the quality of the signal due to routing in the EVAL board and it is acceptable but see below. 

    Now I have other issues which is not related to FATFS: The bitrate setting within SDSPI.c is 12.5MHz but I measured 15MHz SCLK on the SPI. I changed the setting to 8MHz with 8000000 as it remains 15MHz. It seems to be ignored. 

     

    (1) Where is the code within TI library that set 15MHz?

    (2) Why it not responding to change to 8MHz (I did clean and complies, no luck). 

    (3) How to find out what peripheral clock setting to SPI block within the RTOS code. 

    Thanks

  • 0 in reply to richard payne
    TI__Guru*** 134975 points

    Hi Richard,

    I am out of office until Wednesday, but Charles will be back on Monday. Maybe he can help look into this. This question is too detailed for me to dig into while out.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to richard payne
    TI__Guru*** 134975 points

    Hi Richard,

    richard payne said:
    (1) Where is the code within TI library that set 15MHz?

    So what is happening is not that the TI library is setting 15 MHz, but rather the TM4C129x cannot do 12.5MHz for the SPI clock when running at 120MHz. The SPI clock is derived from the system clock and needs integer divisors, so 120MHz/8 = 15MHz. What I am not clear about however is why it is going to 15MHz and not 13.333 MHz. I have been trying to follow through the source code to figure this out but I'm not having any better luck tracking down where the actual configuration is happening myself.

    richard payne said:
    (2) Why it not responding to change to 8MHz (I did clean and complies, no luck). 

    Are you using this API to get the parameters?

    SDSPI_Params_init(&sdspiParams);

    richard payne said:
    (3) How to find out what peripheral clock setting to SPI block within the RTOS code. 

    Still working on this as alluded to above...

    Best Regards,

    Ralph Jacobi

  • 0 in reply to richard payne
    TI__Guru*** 134975 points

    Hi Richard,

    The configuration is happening in the SDSPITiva_open function inside of SDSPITiva.c. However, I am not able to understand why the SPI bus is then going to 15 MHz. If I follow through all the parameter passing and all the configurations even in TivaWare, it doesn't make sense to me.

    Regarding the default settings, I want to try some tests outside of TI-RTOS environment using only TivaWare driverlib calls to make sure there isn't anything unexpected happening with that, but my home lab setup isn't equipped to measure 15 MHz signals. I can try and look into that further next week when back in the office.

    That said, you should definitely be able to drop the frequency down to 8 MHz by using SDSPI_Params_init. If that is not working, can you post your code for that? Let's focus on this element because the 12.5 MHz v 15 MHz element is unlikely to be driverlib related. I suspect there is something else going on that we haven't figure out yet...

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Genius 4640 points

    I have success with MSC-Host (to MemStick) and SDCARD via TI demo code under RTOS as well as alternating USB between CDC-Device and MSC-Device. Later on MSC-Device would be considered but there no MSC-Device demo code in RTOS. I know others in this forum has been asking for this. Is there good material to read on how to mutate the RTOS based code (perhaps CDC-Device) into (MSC-Device), especially the way DMA and SPI bus is attached?. I have done some MSC-Device on NXP 10 years ago (which is not possible under composite with CDC because of an unreported internal bug within the die, so the project was scrapped, the NXP library is very complex and steep). 

    I also found the library <USBMSCFatFs> which actually allow FATFS to handle data transfer to MSC-Device, very interesting since it describes operating under the TI-RTOS. I have not yet studied the code but it would be interesting. 

    Please do keep in touch about what you find with SPI. I will try out the SDSPI_Params_init(&sdspiParams) and code to enforce the SPI clock change next week.

  • 0 in reply to richard payne
    TI__Guru*** 134975 points

    Hi Richard,

    Unfortunately documentation about how to implement other USB types is not really something offered across both TivaWare or TI-RTOS. There is a lot that goes into the different architectures so it isn't something easily boiled down.

    Also MSC device is a pretty unusual use case, I don't know if I heard that one before. I'm guessing the idea is to use the TM4C as an in between for an SD card and the USB host? Or maybe external memory to make the TM4C a 'memory controller' of sorts? In any case, that kind of atypical application would have been outside of our usual scope anyways versus something like Host CDC that is more requested.

    From everything I was seeing, SDSPI_Params_init is what is used to actually load the parameters that then are used by SDSPITiva_open so in theory that could be the solution. Look forward to hearing your results next week as well, thanks for bearing with me while I was out!

    Best Regards,

    Ralph Jacobi

  • 0 in reply to richard payne
    TI__Guru*** 134975 points

    Hi Richard,

    The best and worst part of being a long-time support engineer for these devices is you get to learn so much about them, you end up forgetting things you learned in the past at times and have to re-learn them. Slight smile

    As usual, the devil is in the details.

    From the SSI module bit rate generation section of the device datasheet:

    • The clock is first divided by an even prescale value CPSDVSR from 2 to 254, which is programmed in the SSI Clock Prescale (SSICPSR) register (see page 1252).

    So effectively, the SSI clock starts being divided down from 60 MHz.

    After that, then the following applies:

    • The clock is further divided by a value from 1 to 256, which is 1 + SCR, where SCR is the value programmed in the SSI Control 0 (SSICR0) register (see page 1245).

    So setting SCR = 0 would equate in the 60MHz SSI clock output which is the maximum for the device.

    The trick here is that since we are now starting from 60 MHz - neither 12.5MHz or 13.333MHz are possible. So the SSI module goes up to the higher bitrate when trying 12.5 MHz which is 60 MHz/4 = 15 MHz. Hence what you are seeing. 

    The next value would be 60 MHz/5 = 12 MHz. It is worth noting 8 MHz won't be able to be generated either - you can get either 8.57 MHz or 7.5 MHz instead.

    Hopefully that clarifies the SSI clock output options for TM4C129x devices!

    Best Regards,
    Ralph Jacobi