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.

TMS320F28379D: C28x led_ex2_sysconfig example hangs after a hardware reset

Part Number: TMS320F28379D
Other Parts Discussed in Thread: SYSCONFIG, C2000WARE, LAUNCHXL-F28379D

Hello,

I am testing the led_ex2_sysconfig example and have encountered some unexpected behavior. I would appreciate it if you could review the issue.

My Environment:

  • CCS: v12.8.0

  • C2000Ware: v5.05.00.00

  • Board: LAUNCHXL-F28379D

  • Project: C2000Ware_5_05_00_00\driverlib\f2837xd\examples\dual\led\led_ex2_sysconfig_cpu*

Configuration:

  • The build configuration for both the CPU1 and CPU2 projects was set to FLASH.

  • _LAUNCHXL_F28379D was added to the predefined symbols.

  • The program was loaded directly onto the target via CCS.

Problem Description:

To begin, I am testing the CPU1 project standalone. To do this, I commented out the IPC_sync() line in main.c as shown below.

[Modified main.c]

// This is the code from the led_ex2_sysconfig_cpu* example with the IPC_sync line commented out.
#include "driverlib.h"
#include "device.h"
#include "board.h"

void main(void)
{
    Device_init();
    Device_initGPIO();
    Board_init();
    Interrupt_initModule();
    Interrupt_initVectorTable();

    // The original code would halt here, which is expected as CPU2 is not running.
    // IPC_sync(IPC_CPU1_L_CPU2_R, IPC_SYNC);

    EINT;
    ERTM;

    for(;;)
    {
        GPIO_writePin(DEVICE_GPIO_PIN_LED1, 0);
        DEVICE_DELAY_US(500000);
        GPIO_writePin(DEVICE_GPIO_PIN_LED1, 1);
        DEVICE_DELAY_US(500000);
    }
}

Observed Behavior:

  1. When I build and run the CPU1 project with the debugger, the program correctly enters the for loop in main(), and the LED begins to blink as expected.

  2. However, if I then press the hardware reset button on the board, the LED no longer blinks after the board resets.

  3. It appears the program is halting somewhere during the boot process. Since this is triggered by a hardware reset, I am unable to use the debugger to determine where the code is getting stuck.

Additional Information:

  • For comparison, I tested the led_ex1_blinky_cpu* (the non-SysConfig version) example under the exact same conditions. This project works perfectly, and the LED blinks correctly even after a hardware reset.

Could you please investigate this? It seems there might be a difference in the boot or initialization sequence in the SysConfig-based led_ex2 example that causes it to hang after a standalone reset.

Thank you for your support.

 

  • Hello,

    When you comment out the IPC_sync() line and run CPU1 standalone, the SysConfig initialization (Board_init()) still configures several modules (GPIOs, clocks, and IPC structures) assuming CPU2 will also boot and acknowledge ownership.

    During a hardware reset, however, CPU2 remains held in reset by default. Therefore, the program may stall in the generated board or device initialization, even before reaching your main loop.

    Please try regenerating the code with the above changes and let us know if the LED toggling works as expected after reset.

    Best regards,

    Masoud

  • Hello Masoud,

    Thank you for your response. I have found the cause of the issue.

    The build configuration for the example project defaults to FLASH, so I naturally expected the program to be stored in FLASH and also boot from FLASH.

    However, after inspecting the CMD module within the SysConfig GUI, I discovered that the project is configured to store the program in FLASH but sets the boot entry point to RAMM.

    This setting is applied even when the build configuration is explicitly set to RAM.

    The problem was caused by this incorrect program start address, which prevented the device from booting correctly after a hardware reset.