CC3235MODASF: How to use the internal memory

O.H

Part Number: CC3235MODASF
Other Parts Discussed in Thread: CC3235MODSF, CC3235MODS, UNIFLASH

Hi experts,

My customer is considering using both CC3235MODS and CC3235MODSF to avoid supply side risks.

Q1: Is the following correct about how to use the built-in Flash in the two devices?
CC3235MODS・・・Stores application image in 4Mbyte sFlash. extracts to SRAM and then executes the image.
CC3235MODSF・・・Stores application image in a 4 Mbyte sFlash, copies it to a 1 Mbyte XIP Flash, and then executes the image. Or, extract to SRAM and then execute the image.

Q2: Can I use the same method to write the application image in these two?
Am I correct in understanding that we can write to the sFlash built into both of them in the same way through Uniflash?

Q3: Is it possible to identify these two types of devices when communicating from the outside?
It seems that there is no Device Descriptors (TLV) area in ROM.

Q4: If SPI Flash is used externally, is it correct to recognize that SPI Flash is not allocated to the memory map?

We are inexperienced with CC32xxMOD products, so we would appreciate your help.

Best regards,
O.H

over 3 years ago

0 Jan D over 3 years ago

Guru 75975 points

Hi,

Answers to your questions:

Q1:

CC3235MODS ... correct

CC3235MODSF ... ROM bootloader copy content from SPI flash into XIP flash. There are ways how to execute code from RAM, but it will be wasting of resources only.

Q2:

Yes that is correct. Development workflow is same for S and SF devices.

Q3:

There may to be some ways how to determine between S and SF device. But from application standpoint this is not important.

Q4:

Yes. SPI flash (internal sFlash) is not part of MCU address space. Access for user files is via sl_ filesystem API only. Direct access from application MCU is not supported.

Jan

0 O.H over 3 years ago in reply to Jan D

Genius 5665 points

Hi,

Thank you for your quick answer. I understood most of what you said.

Jan D said:
Q3:

There may to be some ways how to determine between S and SF device. But from application standpoint this is not important.

As for the device, since there is no function or data to determine the model number, does that mean I need to do something in the application image? (It is assumed that the product structure is such that the marking cannot be checked.)

Best regards,
O.H

0 Jan D over 3 years ago in reply to O.H

Guru 75975 points

Hi,

Why you need to determine type of device? Do you need this for production (manufacturing) purpose or something else?

In case you want execute code from XIP flash or RAM, code need to be linked with different addresses. Code linked for execution from XIP flash, cannot work from RAM and vice verse. From this reason it make sense prepare two Uniflash images. One for execution from RAM another for execution XIP flash. You can create image which will work for execution from RAM. This image will work at S and SF devices. But at SF device you will lost biggest advantage of SF (execution from XIP which allow to create bigger code).

Jan

0 Kobi Leibovitch over 3 years ago in reply to Jan D

TI__Guru 63006 points

check the following code to identify the device type.

It is used in our OTA examples, where we check if the MCU image name fits the device (sys/mcuimg.bin or sys/mcuflashimg.bin)

    int rc;
    SlDeviceVersion_t ver;
    uint8_t configOpt = SL_DEVICE_GENERAL_VERSION;
    uint16_t len = sizeof(SlDeviceVersion_t);

    rc = sl_DeviceGet(SL_DEVICE_GENERAL,&configOpt,&len,(uint8_t *)(&ver));
    if(rc == 0)
    {
        localDevType = ver.ChipId & 0xFF;
        /* Update deviceType to 323XX or 3220X */
        if((HWREG(GPRCM_BASE + GPRCM_O_GPRCM_DIEID_READ_REG4) >> 24) & 0x02)
        {
            localDevType |= (0x01 << 8); // This marks CC323x
        }
    }
    
    #define IS_FLASH_DEVICE()       (localDevType & 0x001) /* Identify SF device */
    #define IS_CC323X_DEVICE()      (localDevType & 0x100) /* Identify R3 device */

Wi-Fi

Wi-Fi forum

CC3235MODASF: How to use the internal memory