How to solve debugging problem with lpc54608

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to solve debugging problem with lpc54608

852 Views
Anonymous
Deactivated User

I am having some serious debug issues with the lpc54608 board.

The LPC-Link2 CMSIS-DAP (default out-of-the-box) firmware does not work or not reliable. I keep having issues with probes not being found.

I was able to flash the LPC-Link2 interface with the J-Link firmware. This works but I have some issues with not being able to view the content of variables: as soon as my mouse hovers over a variable name, I get an empty value field. From that moment on, I cannot step or continue my program and I can only click on the "cleanup and debug" button in MCUXpresso v11 to restart.

Switching from the LPC-Link2 J-Link firmware to a real J-link probe from Segger shows the same problem.

Any ideas on how to identify the underlying problem to fix this?

Using MCUXpresso v11.0.0 build 2516 on Windows 10 with LPC-Link v2/J-Link firmware and original HW J-Link probe v8.0 with v6.44i firmware

0 Kudos
4 Replies

693 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello Rob,

What about your board, a demo board or custom?

How about debug a simple demo ?

Could you please take a video or screenshots show your steps.

BR

Alice

0 Kudos

693 Views
Anonymous
Deactivated User

Hi Alice,

I am using the standard LPCXpresso 45608 board from NXP but I discovered that my "some issues" are related to the program I'm debugging.

Without FreeRTOS I don't see a problem but with FreeRTOS it suddenly becomes unstable.

It seems like I can view/watch standard variables but no structures.

I took the lpcxpresso54608_freertos_generic example program from the SDK (SDK_2.x_LPCXpresso54608 version 2.5.0).

This example works but when I add some lines of code I can reproducethe same error as in my own application.

To the prvQueueSendTask I added just two lines of code. See the changed function:

static void prvQueueSendTask(void *pvParameters)
{
    TickType_t xNextWakeTime;
    const uint32_t ulValueToSend = 100UL;
    TaskStatus_t task_list;

    /* Initialise xNextWakeTime - this only needs to be done once. */
    xNextWakeTime = xTaskGetTickCount();

    for (;;)
    {
        /* Place this task in the blocked state until it is time to run again.
        The block time is specified in ticks, the constant used converts ticks
        to ms.  While in the Blocked state this task will not consume any CPU
        time. */
        vTaskDelayUntil(&xNextWakeTime, mainQUEUE_SEND_PERIOD_MS);
        task_list.pcTaskName = "bla";

        /* Send to the queue - causing the queue receive task to unblock and
        increment its counter.  0 is used as the block time so the sending
        operation will not block - it shouldn't need to block as the queue
        should always be empty at this point in the code. */
        xQueueSend(xQueue, &ulValueToSend, 0);
    }
}

TaskStatus_t task_list; and task_list.pcTaskName="bla"; , on lines 5 and 17, are added.

This just adds a structure to trigger my debugging problem.

When I place a breakpoint in the code to stop in this function (FreeRTOS task), I can view the variables used and continu the program. But as soon as I hover over "task_list", the debugger is corrupted. When I press Resume (F8), the program does not continue and I get an error message from MCUXpresso:

pastedImage_1.png

This problem only seems to pop up when I debug FreeRTOS tasks and try to view structures or arrays of structures.

Regards,

Rob

0 Kudos

693 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello Rob,

Please choose "All-Stop" at the IDE Debug Mode:

pastedImage_1.png

And about debug FreeRTOS project on MCUXpresso IDE, please refer to "MCUXpresso_IDE_FreeRTOS_Debug_Guide.pdf", I attached it for you.

Hope it helps,

Have a great day,
TIC

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

693 Views
Anonymous
Deactivated User

Hi Alice,

thanks for your help.

Unfortunately the result does not change. "All-stop" is the default mode.

I re-read the FreeRTOS debug guide carefully to see if I missed something before but this seems not to be the case.

Just to be sure I reverted back to MCUXpresso v10.1.1 build 606 and the problem does not appear in that version of the tools.

The only reason to use the v11 version of MCUXpresso is because of the new LPCXpresso54608 SDK. For now I will just use v10.1.1 with SDK version 2.4.1

Thanks again,

Rob

0 Kudos