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.

CC3230SF: Can I use GPIO11-14 for external SPI Flash on CC3235SF if I control SPI timing carefully?

Part Number: CC3230SF
Other Parts Discussed in Thread: CC3235SF, , SYSCONFIG

Tool/software:

Hello,

I am using CC3235SF in my custom PCB.
In my design, external SPI Flash is connected to:
CLK : GPIO11
MOSI : GPIO12
MISO :GPIO13
CS : GPIO14

I know that these GPIOs are also used by the internal serial Flash of CC3235SF

However, in my application:

White check mark I use UART for flashing and OTA update — not SPI.
 White check mark I want to use GPIO11-14 to communicate with my external SPI Flash only after my MQTT publish, during a short window.
 White check mark I plan to bitbang the SPI manually via GPIO driver → not using hardware SPI.

My question is:

Point right Is it possible to temporarily control GPIO11-14 safely for short periods (after boot, after publish), assuming I release them immediately after?
 Point right Or is there a risk that ROM bootloader or NWP or internal file system will access those pins at any time, causing conflicts?
 Point right Is there any safe way to coordinate this or should I rewire to other GPIOs?

Thank you very much!

 

  • Hi,

    It seems there is at your side misunderstanding of pin numbers.

    NWP flash is connected to pins: 

    • FLASH_SPI_CLK (pin11 of QFN)
    • FLASH_SPI_DOUT (pin12 of QFN)
    • FLASH_SPI_DIN (pin13 of QFN)
    • FLASH_SPI_CS (pin14 of QFN)

    These pins are directly controlled by NWP, and user control is not supported. There is a technical way how to access sFlash directly from application code, but this is not documented behaviour and from this reason this is not supported by TI.

    GPIO11-14 are mapped to pins 2-5 of QFN. That means these pins are not same.

    Jan

  • Hi Jan,

    Thanks for the clarification regarding the NWP-controlled SPI lines.

    Just to confirm: when using sl_FsOpen(), sl_FsWrite(), and sl_FsRead() APIs on the CC3230SF, does this file system API store data in the external sFlash connected to the NWP by default (i.e., on the SPI flash via pins 11–14)?

    If so, is it correct that we do not need to manually control or configure those SPI pins from the application layer, and instead all file I/O is abstracted by the NWP?

    Also, are there any specific configurations or constraints I should be aware of when ensuring that my JSON sensor data is stored and retrieved consistently from this external flash?

    Thanks again for your guidance.

    Best regards,
    zunnur

  • Hi,

    Yes, using sl_ filesystem APIs you can write user data into sFlash memory. To be able write content into sFlast you need to have enabled NWP (by sl_Start() API). No other configuration with SPI for memory is needed.

    But be aware that sl_ filesystem API is not intended for dataloging purpose. Often writing into sFlash will kill flash memory soon (memory have limited write cycles). Although they exist tricks to allow write into sFlash more often (simulating of wear-leveling like - using big flash chip, create many small files at beginning and manually cycling between them) is recommanded to use another storage for dataloging purpose. For more details see serial flash guide.

    Jan

  • Hi Jan,

    Thanks again for the clarification.

    Just to follow up — is there any way to store data in external memory (not the internal sFlash controlled by the NWP)?
    If so, could you kindly guide me on:

    1. What functions or APIs are available to use for accessing external memory (e.g., external SPI flash or SD card), and

    2. Is there any official documentation or example projects related to this use case?

    My goal is to log sensor JSON data more frequently, and I’d like to avoid wearing out the internal serial flash.

    Appreciate your support as always.

    Best regards,
    Zunnur

  • Hi Zunnur,

    If you connect your own memory (e.g. NOR flash, EEPROM, FRAM, SD card) management of this memory will be up to you. At SDK examples you can find some usage of FatFs. But if this fit to you use-case is up to your decision. Or you can use other libraries like LittleFS, LevelX, etc. If you want write often many data, you will need library with support wear leveling or manage it by yourself. You are programmer, this is up to you.

    Jan

  • Hi Jan,

    Thanks again for the explanation on the internal sFlash limitations.

    Just to check — I’m currently using SimpleLink SDK 7.10.00.13, and I’ve tried searching for example projects that show how to store JSON string data into an external SPI flash memory, but I haven’t found anything specific.


    Is there any working example in the SDK (or elsewhere) that demonstrates how to write/read to an external flash memory (not the internal sFlash) using SPI 

    Would appreciate it if you could point me to the right direction or documentation.

    Best regards,
    Zunnur

  • Hi Zunnur,

    See SDK non-RTOS SDK examples: \examples\nortos\CC3235SF_LAUNCHXL\drivers\fatsd\ and \examples\nortos\CC3235SF_LAUNCHXL\drivers\fatsdraw\

    Side note: I think your task is not about "blind" implementation of some examples. You need to understand how NOR flash works, how works wear levelling and took into account how this is implanted at library. Without this knowledge you can create unreliable product.

    Jan

  • Hi Jan,

    Thanks for the clarification earlier. Actually, the reason I asked for an example is because in my current project schematic, the SPI interface is routed to specific pins:

    • SPI_CLK → Pin 11

    • SPI_DOUT → Pin 12

    • SPI_DIN → Pin 13

    • SPI_CS → Pin 14




        

    Connection From MCU:



    Connection from NORFlash:

    However, when I checked these pins in SysConfig, they show up as Fixed (N/A) and cannot be selected or configured, which blocks me from assigning them to my CONFIG_SPI_0 instance.

    So I was hoping to find an example that shows how these pins are initialized/used internally—maybe without needing SysConfig—or if there’s a specific workaround when pins are fixed like this. I'm using the MX25R3235FM1IL0 NOR Flash, and I just want to make sure the SPI bus can be correctly mapped and used.

    As you suggested, I looked into the SDK path:

    examples/nortos/CC3235SF_LAUNCHXL/drivers/fatsdraw/

    and found the following files (screenshot attached). I’m not entirely sure how they handle flash communication or whether the fixed pin issue is managed outside of SysConfig in these examples.

    Would appreciate your guidance on how to proceed if my board has fixed flash pins and I want to use them directly.

    Best regards,
    Zunnur

  • Hi Zunnur,

    I am sorry but I don't understand point of your comment.

    As I said before, sFlash conencted to pin FLASH_SPI_ (pins 11 - 14) is storage dedicated for NWP (WiFi compressor). This storage is controlled by NWP not your code. You cannot access this storage directly from your code. You can utilise this storage only using sl_ filesystem APIs. Because this storage is not directly controlled by your code, you are not allowed to set anything at Sysconfig related this this FLASH_SPI_  pins.

    Jan