• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 389 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.

LAUNCHXL-F280039C: FreeRTOS

Eranga Madhushan
Prodigy 10 points

Part Number: LAUNCHXL-F280039C
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

I start from the freeRTOS, as I need it immediately. I tried the example code used the sysconfig in ccs for the  LAUNCHXL-F280039C. It doesn't work even after I select the board correctly. Then there is an example that same procedure without sysconfig, it works properly. Then I just take the main code of that one and paste to sysconfig example, main code it works. Then I try a new task there to run similar task which is define by me but it doesn't work.

I have some other issues too like in some project when I try to debug they end up with the  "#10234-D: unresolved symbols remain", I can't find them. Better to give me some way to solve the problem and how to approach the problem if its happen in future. 

  • 0
    TI__Expert 3425 points

    Hi,

    We have tested & verified that both the Sysconfig and non-Sysconfig versions of the FreeRTOS ex1 demo work correctly on the F280039C Launchpad. You would need to change the GPIO output pins to 20 & 22 in SysConfig to see the LEDs blinking correctly, since these are the Launchpad LED pin mappings (this information can be found in device.h).

    Error #10234-D occurs when you try to use a variable/function in your project before defining it first. Please verify that all symbols listed under the error message are correctly defined, then recompile.

    Regards,

    Arnav

  • 0 in reply to Arnav Menon R
    Prodigy 10 points

    Hi,

    Thank you for your response!

    Regarding the #10234-D error — the compiler doesn’t list any specific symbols, so it's difficult to trace.

    In the free RTOS part, I did change the LED pins to 20 and 22 as you suggested, and in the non-SysConfig example, everything works fine. However, in the SysConfig-based example, the LEDs still don't blink, even after updating the pins correctly.

    Interestingly, when I replace the main.c code in the SysConfig project with the one from the non-SysConfig example, it starts working. So, the issue seems related to how SysConfig is integrating with FreeRTOS.

    Initially, I was using CCS version 20 on macOS with SDK 5.4 and SysConfig 1.23, but now I also tried it on Windows (CCS v12), and I still face the same issues.

    To verify whether SysConfig was doing anything at all, I tried setting initial LED states directly in SysConfig, and that part worked — the LEDs stayed in that initial state. However, when I step through the code in debug mode, it gets stuck in a loop inside task.c, and never reaches the point where the tasks should be running.

    I'm attaching screenshots related to this for further context.

    I'd really appreciate your help in figuring out what's going wrong here.

    Best regards,

  • 0 in reply to Eranga Madhushan
    TI__Expert 3425 points

    Hi,

    Can you try placing breakpoints inside the tasks and the timer ISR in the Sysconfig example, to make sure the tasks & interrupt are configured properly? The loop you are seeing is the FreeRTOS IDLE task, so the scheduler has started successfully. Could you also link you .syscfg file for further debugging?

    Regards,

    Arnav

  • 0 in reply to Arnav Menon R
    Prodigy 10 points 

    /**
 * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
 * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
 * @cliArgs --board "/boards/LAUNCHXL_F280039C" --device "F28003x" --part "F28003x_100PZ" --package "100PZ" --context "system" --product "C2000WARE@5.04.00.00"
 * @v2CliArgs --board "/boards/LAUNCHXL_F280039C" --device "TMS320F280037C" --package "100PZ" --context "system" --product "C2000WARE@5.04.00.00"
 * @versions {"tool":"1.23.0+4000"}
 */

/**
 * Import the modules used in this configuration.
 */
const led       = scripting.addModule("/driverlib/board_components/led", {}, false);
const led1      = led.addInstance();
const led2      = led.addInstance();
const cputimer  = scripting.addModule("/driverlib/cputimer.js", {}, false);
const cputimer0 = cputimer.addInstance();
const FREERTOS  = scripting.addModule("/kernel/freertos_tool/FREERTOS", {}, false);
const FREERTOS1 = FREERTOS.addInstance();

/**
 * Write custom configuration values to the imported modules.
 */
led1.$name      = "myLED1";
led1.$hardware  = system.deviceData.board.components.LED5;
led1.gpio.$name = "LED1";

led2.$name      = "myLED2";
led2.$hardware  = system.deviceData.board.components.LED4;
led2.gpio.$name = "LED2";

cputimer0.$name                     = "timer1";
cputimer0.enableInterrupt           = true;
cputimer0.registerInterrupts        = true;
cputimer0.timerPeriod               = 20000000;
cputimer0.startTimer                = true;
cputimer0.cputimerBase              = "CPUTIMER0_BASE";
cputimer0.timerInt.interruptHandler = "timer1_ISR";
cputimer0.timerInt.enableInterrupt  = true;

FREERTOS1.$name                               = "myFREERTOS0";
FREERTOS1.CPU_CLOCK_HZ                        = 120000000;
FREERTOS1.MINIMAL_STACK_SIZE                  = 256;
FREERTOS1.USE_MUTEXES                         = true;
FREERTOS1.USE_RECURSIVE_MUTEXES               = true;
FREERTOS1.USE_COUNTING_SEMAPHORES             = true;
FREERTOS1.vTaskSuspend                        = false;
FREERTOS1.STACK_ALLOCATION_FROM_SEPARATE_HEAP = true;
FREERTOS1.tasks.create(2);
FREERTOS1.tasks[0].$name                      = "redTask";
FREERTOS1.tasks[0].taskPointer                = "LED_TaskRed";
FREERTOS1.tasks[0].taskStackSize              = 256;
FREERTOS1.tasks[0].taskPriority               = 2;
FREERTOS1.tasks[0].taskParams                 = "0xDEADBEAF";
FREERTOS1.tasks[1].$name                      = "blueTask";
FREERTOS1.tasks[1].taskPointer                = "LED_TaskBlue";
FREERTOS1.tasks[1].taskStackSize              = 256;
FREERTOS1.tasks[1].taskPriority               = 1;
FREERTOS1.tasks[1].taskParams                 = "0xBAADF00D";
FREERTOS1.semaphores.create(1);
FREERTOS1.semaphores[0].$name                 = "binarySem1";

/**
 * Pinmux solution for unlocked pins/peripherals. This ensures that minor changes to the automatic solver in a future
 * version of the tool will not impact the pinmux you originally saw.  These lines can be completely deleted in order to
 * re-solve from scratch.
 */
led1.gpio.gpioPin.$suggestSolution = "boosterpack1.12";
led2.gpio.gpioPin.$suggestSolution = "boosterpack2.53";

    This is the sysconfig as a text file, that they given in the example.

  • 0 in reply to Arnav Menon R
    Prodigy 10 points

    Hi Arnav,

    I have identified and fixed the issue!

    Even though the SysConfig was set up correctly for the LAUNCHXL-F280039C board, it turns out that the pins mapped for the launchpad were not activated by default. I confirmed this by checking device.h, where I noticed the LaunchPad-specific pin definitions were inactive.

    To solve this, I went into the project properties, navigated to Build → C2000 Compiler → Predefined Symbols, and manually defined:

    LAUNCHXL_F280039C

    After doing this, the correct board-specific pins became active, and everything started working as expected. You can always double-check the correct define name in device.h.

    Thanks again for your support — hope this helps others who might run into the same issue!

    Best regards,

  • 0 in reply to Eranga Madhushan
    TI__Expert 3425 points

    Hi,

    Good to hear you were able to resolve this issue! In case you have any other queries, feel free to follow up, or create another thread.

    Regards,

    Arnav