• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 1 answer
  • Subscribers 41 subscribers
  • Views 341 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

CC3220S: gang program

CC3220MODA: SPI Gang image with playground certificates does not start

MJ
Intellectual 950 points
Part Number: CC3220MODA
Other Parts Discussed in Thread: UNIFLASH, CC3220SF

Dear TI,

I am using the CC3220MODASF chip on my custom PCB. I am trying to flash the device directly using the SPI interface to the Macronix serial flash.

According to my SPI flasher, the image is succesfully written to the Flash memory. However, the application never starts running.
My feeling is that the image is never succesfully unpacked by the MCU, however I don't know how to verify that.

Procedure within Uniflash 6.1 :
1. Using "Simple mode": Upload latest service pack and application MCU image.
2. Go to "Advanced mode" and check following settings:

- Image mode = Production
- Capacity = 4MB
- Use device MAC Address = ON

3. Trusted Root-Certificate Catalog:

- Source file: certcatalogPlayGround.lst
- Signature Source file: certcatalogPlayGround.lst.signed_gen2.bin

4. Go to "Burn" window, and click "Create Image" and then "Save BIN" and "Save HEX".

5. Finally I load this image into SPI Flasher (J-Link Ultra+). Although the transfer of the image seems to be correct, the application never boots.

Couple of extra notes:

1) The image can be succesfully programmed using the UART interface (with correct SOP jumpers set to 010).

2) I am using playground certificates since I don't have a Code signing certificate yet (planning to buy one soon)

3) The SPI flasher can succesfully detect the Flash memory (Macronix MX25L3273F) and verification of the image is also successfull.

4) I have tried both .hex and .bin file formats

Is there something that I am missing? I can't find the reason why it is not working except for the fact that the image unpacking might be invalid.

Best regards,
MJ

certcatalogPlayGround.lst.signed_gen2.bin

  • 0
    Guru 73255 points

    Hi,

    Certificates from playground are supported for a development mode only. For a production mode you need to use certificate which you obtain from known CA.

    Jan

  • 0 in reply to Jan D
    Intellectual 950 points

    I get your point, but I am able to use "Production mode" with playground certificates when programming with the Uniflash UART method.

    So why would there be difference between flashing with SPI or UART flashing in that case? I haven't read anything about that.

    Could you elaborate that a bit more?

    MJ

  • 0 in reply to MJ
    Guru 73255 points

    Hi,

    Hmm... that is interesting. I tested this my myself and it looks and programming by UART via Uniflash works. I supposed that this should not be functional according my previous tests. I have done test with .ucf file generated by Uniflash and this works as well.

    I don't understand what is going on here. Please wait for input from other users.

    Jan

  • 0 in reply to Jan D
    Intellectual 950 points

    Because I am using/overwriting the Trusted Root-Certificate catalog with the "certcatalogPlayGround" files the CC3220 should accept the playground certificates because their root CA is included in this catalog (and therefore allowing you to use the production mode).

    However, (as I already said before) I am not sure why writing the same image with UART would be different then a gang image with SPI.

    MJ

  • 0 in reply to MJ
    TI__Mastermind 22935 points

    Hi MJ,

    I am reviewing this thread. Please give me time to get back to you.

    Jesu

  • 0 in reply to MJ
    TI__Mastermind 22935 points

    Hi MJ,

    I will have to check with our bootloader expert on this. To make sure I understand, you are basically creating an image and you are saying the device boots fine when you program this image to the flash via UART but the device does not boot when you program the image via SPI? 

    Jesu

  • 0 in reply to Jesu
    Intellectual 950 points

    Hi Jesu,

    Thanks for your reply. Yes that is basically what is happening.

    Looking forward to your reply.

    - MJ

  • 0 in reply to MJ
    TI__Mastermind 22935 points

    Hi MJ,

    You may be experiencing a HW issue. Could you go thru this checklist and make sure everything is in order? 

    Can you verify what module pins you're using for SPI programming, plus SOP and reset pin positions? Please also have verify the custom board with the MOD tab of the hardware design checklist.

    Jesu

  • 0 in reply to Jesu
    Intellectual 950 points

    Dear Jesu,

    I verified that I followed all the guidelines. Only one that I am missing is the 270 Ohm pull-up Resistor on the SOP ports, however I doubt that this would make a difference because I copied this from the CC3220SF datasheet (non-MOD version) recommended application schematic (Section 6.1.1).

    I also presume that it would probably impact the UART flashing only (but UART already works fine).

    When I am connecting my SPI flasher to SPI port, I can succesfully connect:

    Furthermore I can also program and verify that the image is programmed using the tool:

    Programming and verifying target (248998 bytes, 3 ranges) ...
 - Reading affected sectors ...
  - Target memory read successfully. (393216 bytes, 3 ranges)
 - Erasing affected sectors ...
  - Erase operation completed successfully
 - Programming target (248998 bytes, 3 ranges) ...
  - Target programmed successfully
 - Verifying target (248998 bytes, 3 ranges) ...
  - All loaded bytes verified OK!
 - Target programmed and verified successfully. - Completed after 11.126 sec

    I have a few questions to verify:

    1. Does it make a difference what the configuration of the SOP pins are for SPI flashing? My default is 000 (all pulled down)

    2. Is there a way (e.g. checking a register or something) to check why image is not booted?

    Best regards,

    MJ

  • 0 in reply to MJ
    TI__Mastermind 22935 points

    Hi MJ,

    1. I'm verifying this with the team. I will get back to you. 

    2. I don't think there is a way to check this. 

    Can you read the contents of the flash after you write the image? 

    Jesu

  • 0 in reply to Jesu
    Intellectual 950 points

    Hi Jesu,

    Thanks for checking it with the team.

    I can read the contents of the flash as well. Verifying both manually (by eye) and with the flasher tool show that the content is correctly flashed.

    One thing I could maybe add that would help with finding the issue; When I do the following steps:

    1. Flash device with Uniflash using UART

    Device status is:

    2. Flash device with SPI flasher

    Then the device status is:

    So the difference seems to be with the filesystem. I don't know why this could be invalided by flashing it with the Uniflash image.

    Hope it helps..

    - MJ

  • 0 in reply to MJ
    Intellectual 950 points

    Hi Jesu,

    I might have found the solution.. the filesystem error triggered me, so I started digging into all the documentation about it in Technical reference manual and  Programmers Guide for example.

    The procedure I should follow is mentioned in Section 8.12.1.2.3. "External Tool Programming" of the CC3220 Programmers Guide.
    From that guide:

    The external programming steps are:

    1. Program the SFLASH with the third-party programming tool.
    Important: The entire SFLASH should be erased before programming the image. The extraction
    process considers that the SFLASH is erased, except to the programming image storage.
    2. Assemble the SFLASH to the device.
    3. For a nonsecure image:
    a. For the CC32xx devices: set the SOP lines to 000.
    b. Power-on-reset (POR) the device.
    c. The image-extracting process is started automatically by the device.
    4. For a secure image (secure image can be created for the CC31xx, CC32xxS, and CC32xxSF) :
    a. Set the SOP lines to UART-programming mode (010 or 100).
    b. Set the encryption key using the Image Creator tool (after setting the key, it resets the device). The
    device extracting process starts automatically. Setting the encryption key is done by the Image
    Creator tool using the UART interface.
    c. For the CC32xx device: set the SOP lines to 000
    d. POR the device.
    NOTE: If the device was POR during the extracting process (after setting the SOP lines to 000 in
    Step 3.a. or 4.c.), the process continues and the device automatically triggers an additional
    hibernate-reset.

    My SPI tool automatically erased the sections that I was overwriting, but I don't think the tool was overwriting all of the sectors.

    I will double check later today, and come back to you as well. But the previous attempt seemed succesful.

    -MJ

  • 0 in reply to MJ
    TI__Mastermind 22935 points

    Hi MJ.

    Good find. So much documentation everywhere you forget where things are. Sorry I didn't catch this sooner. I also asked the team about this and they are confident this is your issue. Let us know how it goes. 

    Jesu

  • 0 in reply to Jesu
    Intellectual 950 points

    Dear Jesu,

    I tried many things now, and I think I can conclude the following things:

    1. I need to specifically erase the whole chip. Just overwriting the parts that you need is not sufficient (at least when using .hex files)

    2. My VBAT_RESET was connected to a jumper to VBAT. Without shorting this jumper, the SPI flasher does not work. So it always needs to be connected to VBAT

    3. I specifically needs to need to close the SPI connection from the debugger before plugging out the connector.

    If I do these things and follow the instructions, then the transfer is successfull consistently. The previous reference to Programmers Guide was of course from the Network Processor.

    I have one question remaining about the "Secure Image":

    - Is there way to flash this "Secure image" using the SPI interface? It seems that UART is the only option according to the programmers guide.

    Best regards,

    MJ.

  • 0 in reply to MJ
    TI__Mastermind 22935 points

    Hi MJ,

    Is there way to flash this "Secure image" using the SPI interface? It seems that UART is the only option according to the programmers guide.

    I'm assuming you are referring to section 8.12.1.2.3 in the programmer's guide. I think you misunderstood the steps. If you notice, in step 1 you already program the image to the flash. What changes is the extraction of that image once it is programmed and that depends on whether or not the image is encrypted. You can choose to program the image over UART to the flash or directly to the flash (regardless of encryption). However, if the image is encrypted you are required to send the key over UART. so the device can proceed to decrypt and extract the encrypted image. This is what step 4 is explaining how to do. 

    Jesu

  • 0 in reply to Jesu
    Intellectual 950 points

    Hi Jesu,

    Thanks for the explanation. That answers my question indeed.

    MJ