LAUNCHXL-CC1310: Strange lockup when using some posix clock stuff

The only other change is in the Board_Lcd_writeString* functions in board_lcd.c:

/*!
 * Write a string on the LCD display.
 *
 * Public function defined in board_lcd.h
 */
void Board_Lcd_writeString(char *str, uint8_t line)
{
#if defined(BOARD_DISPLAY_USE_UART)
#if defined(DEBUG_PRINT_TIMESTAMP)
    print_timestamp();
#endif
    System_printf(str);
    System_printf("\r\n");
#endif

#if defined(BOARD_DISPLAY_USE_LCD)
    if(hDisp != NULL)
    {
        Display_control(hDisp, DISPLAY_CMD_TRANSPORT_OPEN, NULL);
        Display_print0(hDisp, line, 0, str);
        Display_control(hDisp, DISPLAY_CMD_TRANSPORT_CLOSE, NULL);
    }
#endif /* BOARD_DISPLAY_USE_LCD */
}

/*!
 * Write a string and value on the LCD display.
 *
 * Public function defined in board_lcd.h
 */
void Board_Lcd_writeStringValue(char *str, uint16_t value, uint8_t format,
                                uint8_t line)
{
    int len = strlen(str);
    memset(lcdBuf, 0, MAX_LCD_BUF);
    memcpy(lcdBuf, str, len);
    Util_itoa(value, &lcdBuf[len], format);

#if defined(BOARD_DISPLAY_USE_UART)
#if defined(DEBUG_PRINT_TIMESTAMP)
    print_timestamp();
#endif
    System_printf((xdc_CString)lcdBuf);
    System_printf("\r\n");
#endif

#if defined(BOARD_DISPLAY_USE_LCD)
    if(hDisp != NULL)
    {
        Display_control(hDisp, DISPLAY_CMD_TRANSPORT_OPEN, NULL);
        Display_print0(hDisp, line, 0, (char *)lcdBuf);
        Display_control(hDisp, DISPLAY_CMD_TRANSPORT_CLOSE, NULL);
    }
#endif /* BOARD_DISPLAY_USE_LCD */
}

But, you're right.  Declaring the variables in the top of the function "fixed" everything.  Note to self...

Thanks!

Well, crud.  I spoke too soon.  Still doing it with the changes below:

#if defined(DEBUG_PRINT_TIMESTAMP)
#include <stdio.h>
void print_timestamp(void)
{
    uint32_t t;
    time_t t1;
    struct tm *ltm;
    char *curTime;
    char buf[81];

    t = Seconds_get();
    t1 = time(NULL);
#if 1
    ltm = localtime(&t1);
    curTime = asctime(ltm);
    strcpy(buf,curTime);
#else
    Util_ltoa(t1, (uint8_t *)buf, 10);
#endif
    t = strlen((char *)buf);
    buf[t-1] = ':';
    buf[t] = ' ';
    buf[t+1] = 0;
    System_printf((xdc_CString)buf);
}
#endif

I had put the same changes into the Collector example, and it actually works fine.

I also pulled the "char buf[81]" out of there into a static array to see if the stack was getting hosed, but that didn't change behavior.

I wonder if this has something to do with the "struct tm" and/or the "char *" that gets allocated and used in that localtime and asctime calls?

Or, hopefully I'm just doing something stupid.

Hi Dave, 

it still looks like memory issue to me. Did you look into using localtime_r() that is thread safe and uses a user provide buffer for the result that you can define statically?
I would recommend you to implement an alternative for asctime() as also here is internally memory allocated which might break the code.

Kind regards,
Theo

Hmmm....the *_r() time functions don't seem to be available in the ccs environment?

unresolved symbol localtime_r, first referenced in <whole-program>

Did you give that a shot in your environment?

Thanks

Hi Dave,

my bad, I didn't test the implementation first. It is indeed not included.

I was running now some tests using your latest implementation and I can reproduce the DAP access error.
I'm not sure yet what exactly causes it.

You could try instead going with your second option and format it using char array based operations.

Kind regards,
Theo

I think there is some funkiness going on with 32 vs 64 bit mode...I saw some posts about telling the compiler which clock version to use (i forget the macro). Lots of stuff regarding epoch differences between functions, etc.  Seems overly complicated for something that a lot of folks use, but probably not normally in production product with these components.

And thanks for taking a look!

Hi Dave,

I'm not sure about that. But in general we have also another option to add timestamps to you debug output which you can activate in the project properties -> Debug: https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_debug-main.html#misc-other-options 

Did you already check it out?

Kind regards,
Theo

I didn't check that out yet...thanks.

I'm actually not running these targets under the debugger 99% of the time.  The timestamps are a crude "when did that happen" over days of time.

As an interesting aside, it seems that Seconds_get() (1970 epoch) and time(NULL) (1900 epoch) don't return the same values for me.

Hi Dave,

I checked our mac layer implementation again and there is by default timestamps that you can use to print out. Did you check the implementations suggested in the following threads:

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/736993/rtos-cc2652r-bug-report-the-timestamp-of-macmcpsdatacnf_t-in-simplelink_zigbee_sdk_plugin_2_20_00_06-is-invalid

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/839444/ccs-cc1310-rf_getcurrenttime-pdataind--timestamp-pdataind--timestamp2

You can search for the "timestamp" variables with the file search (ctrl+h).

Kind regards,
Theo

This is all great info...my big worry is really more the locking up at this stage of the game. Seconds_get() works fine for now, and I just won't use the pretty time functions.

Hi Dave, 

I'm sorry if I missed something.

Can you please explain the remaining "locking up" issue again?

Kind regards,
Theo

That "Cortex_M3_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 20.0.0.3178)" I detailed above.  You said you even replicated it.

If I don't run the code in the debugger, my target just constantly resets.

Thanks.

Hi Dave,

could replicate it when using localtime() and asctime().

But when I use the function in this configuration:

void print_timestamp(void)
{
    uint32_t t;
    time_t t1;
    char buf[81];

    t = Seconds_get();
    t1 = time(NULL);
#if 0
    ltm = localtime(&t1);
    curTime = asctime(ltm);
    strcpy(buf,curTime);
#else
    Util_ltoa(t1, (uint8_t *)buf, 10);
#endif
    t = strlen((char *)buf);
    buf[t-1] = ':';
    buf[t] = ' ';
    buf[t+1] = 0;
    System_printf((xdc_CString)buf);
}

It runs without error.

Did you make any additional modifications that I don't have in my example?

Kind regards,
Theo

No...like you said, it runs without error when NOT using localtime and asctime.  I'd like to use them ;-)  They are pretty standard operations.

Thanks.

Hi Dave,

I'm looking into if there is a way to use these functions in an embedded rtos environment but they are not the standard.

If you look at the recommended standard then you can find an example project for cc1310 implementing a real time clock with formatted output here: https://dev.ti.com/tirex/explore/node?node=A__ADyXJdDRtNfrNfBnPIYDxw__com.ti.SIMPLELINK_CC13X0_SDK__eCfARaV__LATEST I think the best would be to implement the clock following this project as it would provide you the formatted output that you want to have.

Kind regards,
Theo

Hi Theo,

I appreciate the link...I'm not using C++ in my application.  But, we're getting a bit off track. I've used the standard time stuff (time(),asctime(),localtime(),ctime) for lots of years in lots of embedded rtos environments. Especially ones that support posix.

I'm actually fine right now with my solution to display time, so don't need an alternative. I just thought you'd be a bit more interested in the lockup/"Unable to access the DAP" created when I use the built-in functions of the sdk.  Seems like you've recreated that issue yourself, so good luck with a fix!  And I wouldn't think a "fix" would be "use something else", as those functions are very standard.

Regards,

-- Dave

Hi Dave,

I can only guarantee that our recommended implementations work. I will anyways follow up on this with R&D and update this thread in the future.

I'm happy that you have a solution for your case right know.

Kind regards,
Theo