• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 39 subscribers
  • Views 754 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3220: Uniflash does not recognize the FLASH chip

Art Gerritsen
Prodigy 140 points

Part Number: CC3220

Hi,

Some time ago I posted a question on the forum about a FLASH chip that should work with the CC3220 but for some reason is not recognized by UNIFLASH.

original thread: https://e2e.ti.com/support/wireless_connectivity/simplelink_wifi_cc31xx_cc32xx/f/968/p/625630/2326989#2326989 

I tested the SST26VF016B  again today but it still does not work. 

I tried a new project but the FLASH is not recognized:

I also am not able to set the formatted size to something valid. If I try to program the device the following error is shown:

Remaining question from previous thread:

"

I know that there are differences in the JEDEC ID for both chips but the size that is returned is for both the same 3 bytes. The App note states: "Command 0x9F (read the device ID [JEDEC]). Procedure: SEND 0x9F, READ 3 bytes". However I think it is a bit more complex than that. I think that UNIFLASH uses the JEDEC ID to determine the size of the flash because that can be returned in the third byte of the JEDEC ID. 

S25FL116K JEDEC return format:

9Fh(3) Manufacturer ID = 01h Device Type = 40h Capacity = 15h(this is excepted by UNIFLASH)

ISSI IS25LQ016B

Device ID (ID7-ID0)    Memory Type     Capacity (ID15-ID0)  (this is excepted by UNIFLASH)

14h                                   40                           15h

SST26VF016B JEDEC return format:

                Product Manufacturer ID (Byte 1) Device Type (Byte 2) Device ID (Byte 3) (this is not excepted by UNIFLASH

SST26VF016         BFH                                      26H                           01H

As you can see in the examples above it seems like UNIFLASH uses the 3rd byte to determine flash size.

"

I would like to know:

- Is the JEDEC ID used to determine flash size?

- What does the programming error mean?

Kind Regards,

AG

  • 0
    TI__Expert 8255 points

    Hi Art,

    If you are unable to set the formatted size to something valid, then this issue may be related to the block protection registers.

    I need to look into this to see if the CC3220 has any logic accounting for block protection registers.

  • 0 in reply to Austin Tanner
    Prodigy 140 points

    Hi Austin,

    From the previous thread:

    "I also found that the SST26VF016B  protects all blocks by default at startup.

    quote from datasheet: "the device is write-protected by default after a power-on reset cycle. A Global Block-Protection Unlock command offers a single command cycle that unlocks the entire memory array for faster manufacturing throughput."

    "

    Could that be a problem for the CC3220S/UNIFLASH?

    AG

  • 0 in reply to Art Gerritsen
    TI__Expert 8255 points
    Hi Art,

    Yes, it is a compatibility issue between the CC3220 and the SST26VF016B serial flash. The unlock sequence required for the serial flash device is not implemented in the NWP ROM code.

    This prevents this serial flash from being paired with the CC3220.
  • 0 in reply to Austin Tanner
    Prodigy 140 points

    Hi Austin,

    Thanks for the answer.

    Is there any change that this will be supported in the future ?

    If not maybe the swra515a.pdf document with the FLASH requirements need to be updated with this information because based on the information in that document this chip should work.

    Kind regards,

    AG

  • 0 in reply to Art Gerritsen
    TI__Expert 8255 points

    Hi Art,

    Currently, there is not a plan to support this serial flash with additional block protection registers.

    Regarding the swra515a.pdf document, the Supported Flash Types (section 1.2) outlines the commands that are required. I think this section implies that block protection registers are not supported--although it could be more specific.

    I'll take a look at adding this explicitly to help clarify the confusion.