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-CC1352P: Display_printf stops outputting to console and crashes the app

Part Number: LAUNCHXL-CC1352P

Hi team,

I am using the rfWakeOnRadioTx and rfWakeOnRadioRx examples to make a device that from time to time sends broadcast packets. I'm adding some lines cause I'd like to see the data in the received packet. So I added the Display driver using XDS110 UART:

On rfWakeOnRadioRx.c file I initialize the Display:

I have added some prints to the code as it follows:

I added the "New packet received" print on line 258 because on Display.h file reference says that "it is only possible to call the APIs from Task or Main context because the implementations may rely on Semaphores or other RTOS services that do not work correctly or do not work at all in Hwi / Swi context". So I created the "new_pck" variable that implements when a new packet is received:

Checking the UART output I can see that for some reason it only prints until "TEST4":

I also verified that after about 3 min 30 sec the app crashes and stops responding to new packets (it stops toggling the green LED).

Could please help me find out what I am missing here?

I appreciate,
Eduardo.

  • Hi Edouardo,

    Can you rin the uart independently without the radio? I don't think the radio has anything to do with the issue you're seeing.

    Can you reproduce this issue when a debugger is attached? Can you run the application until this issue happens, then press the pause button and post a screen shot of your call stack?

    Cheers,

    Marie H

  • Hi Marie,

    Correct, if I run the radio application I don't get any errors., it only happens when I add the Display_printf().

    I ran the app until it breaks (stops responding toggling the button) and paused as you said. This is the call stack:

    I also added 3 breakpoints to lines 237, 239 and 242 once it is where it stops printing to the console. They all have similar stacks, like the following one:

    Hope this can be useful, thanks!

    Cheers,
    Eduardo.

  • Hi Eduardo,

    Based on your call stack it seems like the device is running your application, it's not stuck in a HW exception or similar.

    Next thing to check is all the statuses returned from your UART APIs. I suspect you are getting (but not handling) a fail status from the UART driver.

    Cheers,

    Marie H