• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 42 subscribers
  • Views 167 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.

LAUNCHXL-CC3235SF: Early in design, trying to learn what various FAT_FS setups are possible with this MCU?

Marc Yaxley
Expert 1105 points
Part Number: LAUNCHXL-CC3235SF
Other Parts Discussed in Thread: CC3235SF, CC3235S

I'm trying to understand what is possible for a file system on this part before we design our own board hardware.

Flash storage is:  Internal 1MB code space and either a 4MB SPI connected device or a 4MB FLASH_SPI connected device.

The 1MB internal Flash we will store our application code as normal.

We need a read/write file system and either of the other two would maybe work.

Question is: can FAT_FS be located on either of the other two methods of serial flash connection (SPI) for run time

read and write of files.  The dedicated FLASH_SPI lines that are used for external boot code load my question is

can we read/write a large section of this as a FAT_FS?

Of course the standard SPI pins can be assigned in the Pin-Confg tool I'm pretty sure this method is fine with

a file system.  I don't want to use those pins as our board is pin short, using the FLASH_SPI ones for R/W files

would be way better.  We don't need the SD card type of interface.

What's possible, I have looked through over 500 forum entries and not really seen a clear quick answer for this?

  • 0
    Guru 77475 points

    Hi Marc,

    SPI flash (sFlash) is mandatory for proper function of CC32xx devices. Access into sFlash is done via sl_ filesystem API calls using NWP (WiFi coprocessor inside SoC). You cannot manage sFlash by yourself using FatFs or other filesystem.

    For more details see SWRU455 chapter 8, serial flash guide and SimpleLink academy.

    Jan

  • 0 in reply to Jan D
    TI__Guru 63006 points

    The FatFS library provided in the SDK - is for the case you use an external flash that is connected to an SD interface on the host platform. This is in addition to the CC3235SF internal XiP Flash and the external (SPI) flash that is controlled and used by the NWP (which as Jan mentioned can be accessed by the application MCU through the sl_Fs API).

  • 0 in reply to Jan D
    Expert 1105 points

    Follow up question.  By "sFlash" are you referring to the Flash device that the MCU could boot from that is external to the MCU as such?  The lines for this are dedicated ones in the pin-manager that are called FLASH_SPI_x and are not changeable of course, is this known "sFlash"?  I've see that term in some of the forum questions.  The internal 1MB of flash has been refereed to as "XIP" for some reason.

    In the CC3235S MCU there is no internal Flash and it uses those dedicated pins for boot up loads.

    I will use the CC3235SF which has the 1MB internal Flash and I want to connect an additional Flash part to use for file storage, so which is best, use more SPI pins or use the dedicated ones that the boot load Flash part would have used?

  • 0 in reply to Kobi Leibovitch
    Expert 1105 points

    Ok, maybe we are getting closer to my understanding.  The boot up flash if used on those 4 pins that are dedicated for this are not directly usable by the main MCU application I hear.  So as I read it using API calls for the NWP which controls the Flash can I manage using files on that external flash by using this NWP API calls?  I know that some of that flash would be set aside for an OTA update purposes.

    I'm trying to know what the terms mean, XiP is internal and code. sFlash is what?  And if I used the standard SPI pins assignments I could connect any SPI interfaced Flash and use FAT_FS on it then?

  • 0 in reply to Marc Yaxley
    Guru 77475 points

    Hi,

    sFlash is SPI chip connected to FLASH_SPI_x pins of CC32xx QFN chip. Without sFlash CC32xx cannot operate. sFlash is used as storage for execution image, patches for NWP - called ServicaPack, configuration files for NWP, files for internal http server and user files. Access to user files is done via sl_ filesystem API from your code. sFlash is not intended for datalogging purpose due to limited write cycles of SPI flash.

    Advantage for "SF" devices is that allow execute bigger code (up to 1MB). After startup is code loaded into internal XIP flash using ROM bootloader from sFlash. "S" devices have only 256kB RAM (for code execution and variables, buffers, stack, heap).

    If you what to use 2nd storage you can connect then using SPI, I2C or SD card. Management of this storage will be up to you. Be aware that CC32xx have only one general purpose SPI interface.

    Because CC3235 is a 2.4+5GHz device, be aware that CC3235 QFN is very sensitive for proper PCB layout. Another option can be usage of MOD package, which is easier to use.

    Jan

  • 0 in reply to Marc Yaxley
    Expert 1105 points

    Ok, thanks, reading through section 8.3 of the NWP guide helps.  I see sFlash is the serial flash that can have boot code and a 'special file system' (not FAT_FS) files.  I don't need the FAT stuff, just using as an example.    So if I have an application that serves some web pages and collects some user inputs and upload of small config. file I can store all of this sort of activity in the sFlash device, correct?

    I just have to do this via. the APIs for the NWP which actually does the work as such.  The NWP in the CC3235SF MCU is in the same package but is similar if not the same API for designs with the separate NWP processor designs that communicate via. SPI or UART to the application MCU.

    I think I"m getting it and can make good H/W decisions for the design guys to do a schematic.

    I hadn't spent much time on the NWP side and it's doc's at this point, thought it was pretty much the WiFi side management only and I'd get to that when needed.  I'll read up in the NSP guide you pointed to as it does seem to be an essential part of this MCU.

  • 0 in reply to Marc Yaxley
    Guru 77475 points

    Hi,

    For such usage should be usage of sFlash fine.

    Jan

  • 0 in reply to Jan D
    Expert 1105 points

    Finally, "got-it" I say.  That write up Jan gave lays it out nicely for my understanding.  We do need files for logging purposes, not super high writing but none the less would wear the sFlash which has 100K cycles approx.  I can use an I2C connected device as we did on our previous design in this case.

    Thanks guys!