LAUNCHXL-CC3235SF: Where the code is stored in CC3235MODAS and CC3235MODASF

Part Number: LAUNCHXL-CC3235SF
Other Parts Discussed in Thread: CC3235MODAS, CC3235MODASF

Dear TIers,

I have understood from the datasheet of this module that the difference between CC3235MODAS and CC3235MODASF is that CC3235MODASF has  a user-dedicated 1MB of executable flash in addition to the 256KB of RAM.

1) For what this flash memory can be used? is it to contain the code loaded to the target? 

2) In order to maintain my code after HW RESET or Switching off the board, where I should put my code? is it in this flash memory? by default my code is not saved in the chip so I always have to build and load it from CCS.

Hope that my question is clear.

Best Regards,

Brahim

  • Hi Brahim,

    To answer your questions:

    1. Yes, the flash memory is meant to contain your code. By default the CC32xx memory map files will instruct the linker to place all code into the executable flash memory space automatically.

    In addition to code storage, you can use this executable flash as persistent storage, though by default there isn't any space allocated for that purpose. This can be useful for some applications where you need to store some data on the order of a few hundred KBs for immediate use in your program and thus cannot rely on the slower file system storage provided on the external serial flash. The executable flash can be read word-addressed arbitrarily, much like RAM, though erases are by sector so you'll need to carefully review the documentation to ensure that it will fit your needs if you want to use it as persistent data storage.

    2. In order to store your code persistently, you must still flash it to the external flash, most commonly using the UART bootloader with instructions here:

    https://dev.ti.com/tirex/explore/node?node=AIAEL8ziVI8bmN94gWII8w__fc2e6sr__LATEST

    https://dev.ti.com/tirex/explore/node?node=ABEoqU9o3snoxDcmIpW0EA__fc2e6sr__LATEST

    When in development mode, there is a debug option you can use to bypass this bootloader requirement for the code to be loaded from the external flash. See this post for details:

    https://e2e.ti.com/support/wireless-connectivity/wifi/f/wi-fi-forum/588229/cc3220sf-launchxl-network_terminal-project-debug-issue/2160853#2160853

    With those debug flags set, any code you load through JTAG in CCS to the internal flash will be kept across reset, as the bootloader will not perform its usual integrity check + comparison to the external flash.

    Let me know if you need more clarification or have further questions on the internal executable flash of the CC3235.

    Regards,
    Michael

  • Hi Michael,

    Thank you for your reply, it helps a lot.

    I am still confused if the external flash is mandatory or not. I understood that we can use the internal flash to save the code and keep it there after reset or switching-off the board, so no need to use external flash. Please confirm.

    Is there any docs explaining how to set those flags ( __SF_DEBUG__ and --retain ulDebugHeader )? otherwise, could you please tell me where to do it in my project?

    Best Regards,

    Brahim

  • Hi,

    Yes, the external serial flash is mandatory. It is used not only for storing the MCU binary, but also for storing the networking stack config as well as the servicepack for the network processor core. Thus even though the MCU binary is copied to the internal flash during runtime, there still remains a need for the external serial flash.

    The use of the debug header is described in section 21.10 of the TRM: https://www.ti.com/lit/swru464

    You can take the general instructions provided to generate the debug header manually yourself, but it is simpler to follow the instructions provided in the E2E post previously linked to get CCS to generate this header for you.

    Do note that this header is meant for debug use, as a method to prevent the need for flashing the serial flash for testing your code on a persistent basis. It is not a method to keep your code in the internal flash for production use, as it relies on the device being set in development mode.

    Regards,

    Michael