• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 40 subscribers
  • Views 465 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.

CC3220SF: The same application erases internal flash if downloaded in production-mode

Boris Erakhtin
Intellectual 460 points
Part Number: CC3220SF
Other Parts Discussed in Thread: UNIFLASH, CC3200,

Hello Everyone!

I face the strange issue, that I guess can not be explainde by bootflow chapter of Reference Manual.

The sequence of my actions:

1. I download dev-mode image via uniflash to extenral flash with mcuflashimg.bin created out of IAR binary,

the application reads data from some address in Flash and blinks diode, if data is the same as expected by app;

2. I use Uniflash to download some data to some address via SWD, (for example to the first bank 0x01070000 or to the second bank 0x01080000);

3. If I download correct data, diode blinks, if incorrect - does not, so the functional truly works;

4. Next I download prod-mode image with the same mcuflashimg.bin from the same IAR binary, and I compared mcuflashimg.bin from dev- and prod-modes, the are equal.

That means that their SHA-1 should be the same? And ROM-bootloader should not detect new mcuflashimg.bin and shoud not erase internal flash and upload new one from external.

5. After downloading prod-mode, app runs, but diode doesnt blink, so that means internal flash was erased and written again;

So my question is why internal flash erased, if mcuflashbin.img are equal in both modes?

Also why mcuflashbin.img size is about IAR binary size when I download it to some folder from Uniflash (78 KB in my case)? I guess it should be 1024 KB as written in Uniflash?

My goal is to write some special data to internal Flash, while debug-interfaces are enabled, then disable them by dowloading prod-mode image, but internal flash data I've written should be saved. 


Regards,

Boris

  • 0
    TI__Mastermind 22935 points

    Hi Boris,

    In production mode the debug interface is disabled and at startup the boot loader writes the external image to internal flash if they are different. Therefore the behavior you're seeing is expected.

    Jesu

  • 0 in reply to Jesu
    Intellectual 460 points

    Why are they different?

    Both mcuflashimg.bin in dev and prod modes are made from the same IAR binary. For both dummy-root-ca-cert and dummy-root-ca-cert-key are used.

    I even set Max File Size of mcuflashimg.bin 512 KB, not 1024 KB, and try to download data to 0x01080000, but the result is the same.

  • 0 in reply to Boris Erakhtin
    TI__Mastermind 22935 points

    To ensure system integrity, the SimpleLink Wi-Fi device applies an image-based programming methodology. Development mode exposes features for easier development without compromising on security. The following functionality is available:

    • File-by-file access is permitted from the ImageCreator tool
    • File list can be accessed from the ImageCreator tool
    • JTAG interface is enabled for debugging

    Production mode is appropriate for mass production and enables multiple devices to be programmed with the same image. The JTAG interface is blocked in this mode, so a CC32xx LaunchPad cannot be used with the Code Composer Studio debug tool when it is flashed with a production image. 

    In production mode you cannot change (upload/download) separate files without whole image upload.

    http://dev.ti.com/tirex/explore/content/simplelink_academy_cc32xxsdk_3_10_01_00/modules/wifi/wifi_imagecreator/wifi_imagecreator.html#development-vs-production-mode

    Jesu

  • 0 in reply to Jesu
    Intellectual 460 points

    Hello Jesu!

    Thanks for your reply.

    I am really confused about this issue. I see the same behaviour, if I upload dev-mode image, write data to 0x01080000 by Uniflash via SWD, next I upload the same dev-image again, and data I wrote by SWD is erased either.

    As I thought, according to the bootflow, ROM-bootloader counts SHA-1 of internal flash application using "Image size" placed in 0x01000004, compares it with SHA-1 from mcuflashimg.bin, if they are not equal, it leads to mass internal erase, and dowloading application from external to internal.

    My first question is: am I wrong about this SHA-1 mechanism?

    One more strange thing:

    1. Upload dev-mode image without mcuflashimg.bin;

    2. Enable SF_DEBUG-header in IAR and upload app from IDE to Internal flash;

    3. Write data to 0x01080000 by Uniflash SWD;

    4. Check data from 0x01080000 by application;

    5. Upload the same dev-mode image without mcuflashimg.bin again;

    6. Application is not erased, it is expected;

    7. Data from 0x01080000 is not erased too and successfully checked by application.

    So my second question is: WHY this thing works with an empty dev-mode app and doesnt work with dev-images with identical mcuflashbin.img?

    Regards, Boris

  • 0 in reply to Boris Erakhtin
    TI__Mastermind 22935 points

    Boris,

    The bootloader compares the signature from the on chip image to the one programmed to the flash which is calculated at the time of programming the device. If the signatures are different, then it leads to mass internal erase and the external image gets programmed like you said. 

    Could you share where you found information on SF_DEBUG for the CC3200? I would like to verify its setup and behavior is the same as the CC3220.

    EDIT:

    The question above may seem silly but I'm having trouble locating where SF_DEBUG is mentioned in the context of the CC3200. I'm curious how you came across it.

    Could you also help me understand what you're trying to do? It seems to me like you're trying to inject code via debug interface and trying to find a way to trick our bootloader from overwriting the internal flash when it realizes a change.

    Jesu

  • 0 in reply to Jesu
    Intellectual 460 points

    Hello Jesu,

    I misunderstand the question about CC3200, because I have never used it, I work only with CC3220SF. As I recall, CC3200 doenst have internal flash, so debug header can not be used there.

    I am trying to develop a secondary bootloader(the primary one is yours ROM one). The concept of bootloader in project I work in is well established, there are some reuirements for everything to be stored in internal flash of mcu, and this flash should be locked, so I tried to adapt CC3220SF for it.

    I wanted this secondary bootloader to be stored on external flash as mcuflashbin.img, and nothing more ever been placed to external flash (I mean the actual application and some files).

    My plan was:

    1. Upload secondary-booltoader dev-image to external flash;

    2. Write some data to internal flash via debug interface (it was not erased afer reset);

    3. Upload secondary-bootloader prod-image to lock the flash. I thought that if hashes of internal code and code from external-image are equal, the primary bootloader will not erase inernal, uploaded at step 2 data will be safe, and debug interfaces will be disabled.

    It seems like it is not possible, so I gave up this idea and started developping my own bootloader with buffering files on external flash, copying them to internal and then erasing friom external (this mechanism works okay).

    So I guess this thread should be closed.

    P,S Also at the moment I try to find out how to jump correctly from secondary bootloader to the application placed in memory at this thread https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/813143

    Regards, Boris

  • 0 in reply to Boris Erakhtin
    TI__Mastermind 22935 points

    Hi Boris,

    CC3220 definitely explains that. For a moment I thought you were using CC3200 - that's why I got mixed up and was wondering how you managed to use SF_DEBUG.

    Do you mind sharing why you wish to create your own bootloader?

    Jesu