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.

LAUNCHCC3220MODASF: Serial FLASH programming tool - "Could not verify a connection to target device"

Part Number: LAUNCHCC3220MODASF
Other Parts Discussed in Thread: UNIFLASH, CC3220SF, CC3220MOD

I have included the SFLASH header from the LP design in a custom board and haven't had any luck programming the module with an OTS SPI Host adapter. We're currently using Uniflash to program our board with the UART RX, TX, CC_RESET and GND lines brought out, however I would like to get the SFLASH gang programming method functional before moving to production.

My OTS SPI Host Adapter is the TotalPhase Cheetah, as recommended in a separate post. I am using the Total Phase Flash Center software to load a bin file and connect to target using a TC-2050-NL header wired to the Total Phase split cable.

One issue I see is that the SPI Flash used in the CC3220MODASF (Macronix MX25R3235F) is not listed as an available target, I've tried the MX25L3235E and MX25U3235F instead. R is the wide range, L and U are 3.3V and 1.8V versions. Does TI have an XML config that can be loaded into a programming tool? Should one of the listed targets work?

I was able to program the bin file onto the SPI FLASH test board (STMicro M25P32) supplied by TotalPhase. However, when I connect my custom board or the LP board SFLASH lines (MOSI, MISO, SCLK, SPI_CS and GND) to the Cheetah host adapter (and CC_RESET pulled low on board), it shows a "Could not verify a connection to target device" error. I'm following the production line guide (SWRA568), but haven't been able to get a connection to the CC3220MODASF. Is there an OTS cable that works directly with the LP SFLASH header and a SPI Host Adapter?

I also noticed an error (I believe) in the CC3220MOD datasheet. The FLASH_SPI_MISO pin 13 is shown as type 'input', however the schematic lib shows it as an output. Vice versa with FLASH_SPI_MOSI pin 17. The module flash chip (MX25R3235F) is a slave to the CC3220SF chip and any SPI Host adapter should be the master (backed up by the CLK and CS lines being inputs as well). The schematic component from the ref design shows 13 as output and 17 as input.

I've swapped MISO and MOSI to see if this solves the problem and haven't be able to get the target to be recognized. Any help would be appreciated.

Thanks,

Andrew

  • Hi Andrew
    We don't have an XML for this part for this, but go with the flash device that works at 3.3V. When I did it, the exact part number wasn't available either. Make sure VBAT_RESET isnt pulled up as well.

    -Aaron
  • Hi Aaron,

    thanks for your reply. I am testing the programming tool on a launchpad (WCS028) and figured out what the issue was. Using an incorrect flash device setting as target in the Flash Center software will cause the "Could not verify target..." error. When connecting to target, the software needs to read the correct RDID values.

    Sadly this also blocks the user from reading the flash chip or doing anything else, so I wasted a few hours trying to debug the hardware when there was only a software bug. To get past this, I used a Saleae logic analyzer and checked the bus during target read.

    This showed a correct read of the ID and response, so hardware was fine. Since I was still getting a target error, I went in and added the MX25R3235F to the XML file (Macronix SPI Flash.xml in the parts folder). After setting the RDID to the right values, I was able to connect without any issue.

    I still don't understand why the SFLASH header on the Launchpad has that specific pinout, it doesn't appear to match any tag connect or total phase cables. It's as if a male to male header was used to mirror pins 9/10, 7/8, etc. for connecting a TC-2050 to the Cheetah directly.

    Best,

    Andrew

  • Andrew,

    I'm just looking into this as well and seem perplexed as well as to why the LaunchPad pinout is different than what would be needed to interface the Cheetah directly using a TC-2050. Thanks for figuring all this out.

    So there is no way through the Cheetah to pull the CC_RESET low other than doing it directly on the board?
  • I see that the Cheetah has two ground pins, it would probably work to connect one to your board ground and the other to the reset pin (with an appropriate resistor of course). I can't think of a reason for that not to work.