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.

CCS/CC3220SF-LAUNCHXL: How do I download/debug code -- preferably using only USB connection, else any method?

Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: CC3220SF, CC3200, UNIFLASH, CC3220S, CC3120

Tool/software: Code Composer Studio

Subject: How to debug code on CC3220SF LaunchPad through CCS7 with only USB connection?

In recent months, I developed data collection code using CCS6 on the CC3200 LaunchPad board with only USB connection.
As I recall, I had to go into DeviceManager and set the baud rate to 921000, then downloaded into RAM directly from CCS with SOP2 jumper installed for execution/debugging.
I also successfully used UniFlash 3.41, then removed SOP2 to run independently of CCS, even on battery power.

I'm now advancing to CC3220 (to have access to more RAM for data collection) and am starting out with a CC3220SF LaunchPad board, CCS7, SDK 1.3, etc.
using the "portable" demo app using FreeRTOS (for testing/familiarization).

Everything builds perfectly, but I'm not able to download and debug.

I see the target config was set to "Texas Instruments XDS110 USB Debug Probe," resulting in:

Error connecting to the target:
(Error -1170 @ 0x0)
Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK).
(Emulation package 6.0.576.0)

This happens in both the case where I have SOP1 jumpered (as I received the board) or SOP2 jumpered.

Device Manager shows both COM3 and COM4 as being "XDS110" and only offers baud rates up to 128000.

So I changed the target conf to "Stellaris In-Circuit Debug Interface," resulting in:

Error connecting to the target:
Frequency is out of range.

Again, I tried with SOP1 jumpered and then with SOP2 jumpered.

I also purchased a TI XDS110 debugger for $99, but I see frequent claims that there is an XDS110 emulator on the board.

So how does one now debug?

Do I need to use UniFlash (v4.1) on every debug cycle? That would waste time and require more typing vs. debugging basic logic first directly from CCS.

Or, do I need to use the external XDS110 debugger, while still keeping the USB connection? That would consume an extra USB port on the laptop, which only has 3 such ports..

Regardless of whether I need to use UniFlash for debugging now, is there a comprehensive UniFlash v4 User Manual? All I find is a short "Quick Guide."

Should I be debugging first using a CC3220S, not SF?

  • Hi Ralph,

    Please see - e2e.ti.com/.../2131099

    Jan
  • After several days of pseudo-randomly trying things, what I've been able to get to work is this:

    I can command UniFlash 4.1 to "import" the OOB_SF_freertos ZIP file found in the SDK 1.3 at this path:

    ti/ simplelink_cc32xx_sdk_1_30_01_03/ examples/ rtos/ CC3220SF_LAUNCHXL/ demos/ out_of_box/ uniflash

    If I specify Development Mode when flashing that, I end up with something where CCS can download (via USB) the "portable" project for debugging. I understand that this only puts the portable code into SRAM for execution, which is fine for debugging. If I leave it at Production Mode, I get the DAP error mentioned in my initial post.

    I have not, however, been able to create a UniFlash 4.1 project from scratch. I get a variety of errors often related to certificates and the like.

    Surely this is all adequately explained in the full UniFlash 4.1 User Guide. Where is that document to be found?

  • Hi Ralph,

    User guide for image creator is available at product webpage ( www.ti.com/.../technicaldocuments ). Have you read this documentation? Also is available step-by step video - www.youtube.com/watch

    In production mode is JTAG disabled. This is due to security reasons.

    Jan
  • Jan,

    OK, that helps.

    Now, I can complete the "Program Image" process without error, but ONLY if I do not specify mcubootinfo.bin or mcuflashimg.bin.

    So;

    1. Where do I find mcubootinfo.bin. I searched the SDK unsuccessfully for it.

    2. When doing Action "Select MCU image," where do I get "generated_signature.bin?" Have I missed a step that is supposed to create this file from portable_SF_freertos.BIN? Interestingly, I do not find such a file in the OOB_SF_freertos demo app, despite it showing such a file on the Properties screen for its BIN file.

  • Jan,

    Also, document SWRU469 (UniFlash CC3120 and CC3220 SimpleLink Wi-Fi and Internet-on-a-chip Solutioin ImageCreator and Programming Tool User's Guide) section 5.8.1 (Secure Signed User Files) on page 12 says:

    "For secure signed files, the Image Creator must receive a signed certificate and the file signature. For more information regarding how to retrieve a signed certificate and how to create a file signature, refer to the secure file system chapter in the user manual (search for the sl_FsClose () function)."

    To what "user manual" document is this statement referring?
  • Jan,

    OK, so I read Chapter 8 ("File System") in document swru455a ("CC3120, CC3220 SimpleLink™ Wi-Fi® and Internet of Things Network Processor Programmer's Guide") to which you linked. It's all very interesting stuff, but it still doesn't answer my questions (1) or (2) above.
  • Hello Ralph,

    re: 1) /sys/mcubootinfo.bin

    This is a file that is read by the bootloader. It is a binary file containing some boot info parameters/flags, one of which is a timeout value that is loaded into the watchdog timer. If the watchdog expires before the newly programmed application has confirmed that the files have been upgraded correctly, then the device will reboot and roll-back the pending file commits to the previous version.

    In the OOB application, this binary file is configured for a timeout of 16 (2*8) seconds. You could re-use this file if this is appropriate timeout for your system or re-create as desired.

    FYI : The definition of this structure is provided in the filesystem section of the programmers guide. (www.ti.com/.../swru455a.pdf)

    re: 2) 'generated_signature.bin'

    'generated_signature.bin' is an internal file as part of uniflash project that represents a signature that was created previously when uploading and signing a file. The process for signing is described above and shown in the link.

    Hope that helps,
    ~roger

  • Roger,

    OK, so I see in section 8.9.6 how to programmatically create a file mcubootinfo.bin.
    If, however, a suitable file (8-second timeout twice) already exists in the OOB demo app, I prefer to use it. But where is the file? I've searched the entire SDK tree again and do not find it.

    Ralph
  • Hello Ralph,

    Easiest way is to download it from one of the existing projects that contains this file, e.g. one of the OOB_* uniflash projects.  You can use the 'Get File' option in uniflash user-files view to retrieve it.

    Hope that helps,

    ~roger

  • Roger,

    I successfully 'GetFile'd the mcubootinfo.bin file from the OOB project.

    I'm still not following the certificate stuff. In so many cases I've found, TI's documentation contains errors and/or omits requires steps. In the case of document SWRU461 (Figure 3-14 and preceding text), when I specify Private Key File Name and browse to dummy-trusted-cert-key, the drop-down box for Certificate File Name does not offer dummy-trusted-cert, so how was the screen shot in Figure 3-14 created?

    I ran across this thread from May 10:

    e2e.ti.com/.../594542 cycle clarifications

    and followed the arrayent dev kit instructions it references, which specify dummy-root-ca instead of dummy-trusted. THIS WAS SUCCESSFUL, just as it was for the originator of that thread.

    I don't know squat about certificates. What's the difference between dummy-trusted and dummy-root-ca? Why do TI docs have so many errors and omissions? Why is there (apparently) no comprehensive User Manual for UniFlash v4.1, preferably one written (or at least proof-read) by a native speaker of English?

    Ralph
  • Hi Ralph,

    The dummy-trusted-cert must be added as a user file (and should be added with the entire chain) in order for it to show up in the drop down menu. I'm not sure if this was the case during your test or not. It should show up as available when added as a user file.

    In order to validate the image, you need to verify the signature against a known Root CA. This means you can do the following -

    (1) Sign the image directly with the dummy-root-ca-cert-key and verify directly against the dummy-root-ca-cert (not always a realistic use-case)
    or
    (2) Sign with the dummy-trusted-cert-key and verify against the entire chain, by specifying dummy-trusted-cert as the certificate file name. In this case, the entire chain must be added to the file system (as user files for example).

    So the difference is that it is essentially a hierarchy of certificates with the dummy-root-ca-cert being the top and dummy-trusted-cert as the bottom.

    Best Regards,
    Ben M