• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 471 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.

Emulation after bootloader runs

henlee
Intellectual 840 points
Other Parts Discussed in Thread: SEGGER, AM3352

We use CCS 6.0.1.00040.  The bootloader and a default application for our Am335x board reside in SPI Flash.  Before the SPI Flash is programmed, I can connect to the board using a Blackhawk USB560v2 emulator and .gel file, load code into DDR3, and run to main() all in one step.  However, after the SPI Flash is programmed and the bootloader has loaded code into DDR3 and that code is running, I haven't found a way to halt the target, reload DDR3 with a new application, and run to main() for developing new code.  In this case, the emulator connects to the target successfully but shows verification errors.  I've tried removing DDR3_EMIF_Config from the .gel file, and removing everything from the .gel file since the bootloader has already configured the clocks, DDR3, etc. 

How do I halt the application which the bootloader loaded into DDR3, load a new application into DDR3, and run to main()?  Preferably this would be done in one step.  Please include specific settings for the Program and Target tabs in Debug Configurations if that's where can be configured.

  • 0
    Guru 92251 points

    Try setting the "Reset the target on a connect" only on the IcePick_D_0. See Can CCS5.5 be configured to assert a system reset before loading a program for how that was used on an AM3359.

  • 0 in reply to Chester Gillon
    Intellectual 840 points
    That works! Chester Gillon, thanks for a really helpful answer. TI, this seems like a pretty common thing to do. Maybe CCS can just reset IcePick_D_0 by default in a future release so people don't bang their heads.
  • 0 in reply to henlee
    Guru 92251 points

    henlee said:
    TI, this seems like a pretty common thing to do. Maybe CCS can just reset IcePick_D_0 by default in a future release so people don't bang their heads.

    I agree that a full system reset before starting a debugging session is probably a good default, to get the target into a known state.

    One time you don't want a system reset if you are attaching the debugging to an existing running target to investigate it's state, e.g. after a run time failure or crash. Maybe there should be a "top level" connection option such as "start debugging after full system reset" or "attach to running target" to make it clear what will happen, rather than a less obvious debug properties setting.

    One possible reason why an IcePick_D reset can't be the default is that it's availability depends upon the debug emulator used. E.g. using a XDS100v2 to debug an AM3352 is slow compared to a Segger J-Link, but the CCS Segger J-Link driver doesn't support the IcePick_D debug options.

    I did try and look at the CCS 6.1 configuration files to see if there was a file which could be changed to make a system reset via IcePick_D the default for a new target configuration, but failed to find such a setting. The option about if to assert a IcePick_D reset upon connect only seems to be saved in the .launches/<project_name>.launch file in the CCS Workspace after you have made a change.

  • 0 in reply to Chester Gillon
    Intellectual 840 points

    Your alternate solution in a previous thread, i.e. adding these lines to .gel file, works well also:

    StartUp()
    {
        GEL_AdvancedReset("System Reset");
        GEL_TextOut("Performed System Reset\n");
    }

    CCS posts the following warning, but we ignore it:  "Blackhawk XDS560v2-USB System Trace Emulator_0/IcePick_D_0 : Target must be connected before loading program."