• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 784 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.

CCS/LAUNCHCC3220MODASF: Avoiding external serial flash programming from command line

Ralph Corderoy
Expert 1110 points

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

Tool/software: Code Composer Studio

Hi,

I'm developing for the CC3220SF on Linux using gcc, make, etc., and currently program the CC3220's external serial flash, in development mode, with a bit of Uniflash from the shell:

    /opt/ti/uniflash_5.2.0/dslite.sh --mode cc32xx \
        project program --name $project --dev

It takes well over a minute before the new code runs given the bootloader has to spot the internal parallel flash is out of date and update that too.

I understand CCS has the option, or always does it, of writing to the internal flash directly, cutting out the external-flash write? Is that correct? Or does it instead write to SRAM and execute that instead, leaving both flashes alone?

Either way, I'd like to obtain the same effect but sticking to the command line. I've the XDS110 on the LAUNCH development board, a separate XDS110 probe, and a Segger J-Link to hand. How can I achieve a faster edit-compile-run cycle from the command line using those, whether by running CCS in some non-GUI manner, kicking off the external-to-CCS process which CCS runs, or something else entirely?

Thanks, Ralph.

  • 0
    TI__Guru**** 163035 points

    Ralph,

    If you want to program the onchip flash with UniFlash this should be possible.

    When selecting the device in UniFlash I can select the CC3220SF that has "On-Chip" on the right.  If I select thte LaunchPad then it is set to program the external serial flash.

    I then select the debug probe:

    Now when I click on start it does not run the ImageCreator GUI but just gives the UniFlash options for programming onchip flash.

    I generated the command line package.  When I look at the geneated dslite.sh it is running a command that looks like:

    DSLite flash -c user_files/configs/CC3220SF.ccxml -l user_files/settings/generated.ufsettings -s VerifyAfterProgramLoad="No verification"

    Are you doing any source level debugging after flashing?  If so then CCS would still need symbols.  If you are just building, loading and running then this could work.

    Another option might be to use loadti.

    http://software-dl.ti.com/ccs/esd/documents/sdto_dss_loadti.html

    Regards,

    John

  • 0 in reply to JohnS
    Expert 1110 points

    Hi John,

    Thanks very much. I went with loadti:

        ti=/usr/local/ti
        # -v = verbose.
        # -c = target definition.
        # -r = reset before load.
        # -b = init BSS.
        # -l = exit after load.
        $ti/ccs920/ccs/ccs_base/scripting/examples/loadti/loadti.sh \
            -c $ti/FreeRTOSv10.1.1/FreeRTOS/Demo/CORTEX_M4_SimpleLink_CC3220SF_CCS/targetConfigs/CC3220SF.ccxml \
            -r -b -l a.out # ELF file.

    This works fine and is a noticeable improvement in speed. However, the bulk of the programming time is taken by CCS starting up on Linux, which is high CPU usage across all cores, i.e. it takes 20 seconds before the 'DSS Generic Loader' appears on a slow lab PC which is connected to the target board. And that's the second run so no disk reads occur to slow the measurement.

    Many of the syscalls, 38%, are ioctl(2), which I assume is during the 'Loading a.out' phase when userspace is passing the XDS110 a little data at a time? Context switches during this rise from ~12K/sec to ~150K/sec.

    So looking for further improvement, I see TestServer in the CCS scripting examples which I think should allow me to suffer the start-up cost of CCS and DS once with just the programming time needed on each flash-burn after that?

    For completeness, Google also found 's repositories inspired by TestServer. https://github.com/webbcam

    Cheers, Ralph.

  • 0 in reply to Ralph Corderoy
    TI__Guru**** 163035 points

    Ralph,

    Yes a TestServer like implementation would save that startup time.  Loading all the libraries for the debugger takes a while.  Test Server would have further optimization as it would have done the debugger initialization as well.  

    Regards,

    John