• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 54 subscribers
  • Views 391 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.

CC1312R: [CC1312]TI Logger Python Parsing: Format Specifier Support Inquiry

Young June Kim
Prodigy 60 points
Part Number: CC1312R


Tool/software:

Hello TI Support Team,

I am encountering unresolved issues with TI Logger in the latest SimpleLink SDK implelink_cc13xx_cc26xx_sdk_8_30_01_01 when parsing logs via Python:

  1. %d prints values as unsigned integers (similar to %u).

  2. %s fails to display string values entirely.

This occurs despite correct format specifiers in C code, suggesting a potential mismatch in the Python parsing implementation within TI Logger.

Key Questions:

  • Is there a known limitation in TI Logger's Python module regarding standard format specifiers (%d, %u, %s)?

  • Are there plans to update TI Logger's Python parser to align with standard printf behavior in future SDK releases?

  • If modifications are needed, which Python modules/files in the SDK should be referenced (e.g., ti_logger_parser.py, log_format.py)?

Additional Context:

  • Example log output and Python parsing code available upon request.

Please advise on workarounds or patches.

Best regards,
YJ KIm

  • 0
    TI__Expert 7645 points

    Hi Kim,

    could you please share more details on the topic:

    - Which log sink are you using?
    - A minimal example of project and parsing code?

    Have you already checked out the collaterals explaining the implementation:
    - SimpleLink Academy: https://dev.ti.com/tirex/explore/node?node=A__AUtBCHw9KYI99xItuPjn4w__com.ti.SIMPLELINK_ACADEMY_CC13XX_CC26XX_SDK__AfkT0vQ__LATEST
    - README: SDK-directory\tools\log\tiutils\README.md

    Kind regards,
    Theo

  • 0 in reply to Theo Lange
    Prodigy 60 points

    Hi Theo,

    Thanks for your quick response.

    Regarding your questions:

    • I've tested with both ITM and UART log sinks, and the issue persists with both, yielding the same results.
    • A minimal example of the problem is as follows: I have an int8_t variable representing an RSSI value. When I print this variable using Log_printf with the %d format specifier, expecting a negative value like -101, the output I receive is 4294967195. The expected correct output would be -101.

    This behavior seems to stem directly from the argument handling described in log.h. As per the comments in the header file, arguments are cast to uintptr_t, which is an unsigned integer type. This inherently limits how signed values are interpreted on the target side before being transmitted.

    Please refer to the following excerpt from log.h

    * The arguments are type-cast to a uintptr_t, which is an unsigned integer
 * type. This limits the supported format specifiers to the following:
 * - Unsigned decimal integer: %u
 * - Unsigned hexadecimal integer: %x
 * - Unsigned hexadecimal integer (capital letters): %X
 * - Character: %c
 * - Signed decimal integer for positive values: %i, %d
 * - Signed octal for positive values: %o
 *
 * @note All arguments are treated as 32-bit wide and are promoted or
 * truncated accordingly.

    As this documentation indicates, %i and %d are limited to "positive values" when cast to uintptr_t. This explains why a negative int8_t value (e.g., -101, which is 0xFFFFFF9B when promoted to a 32-bit signed integer) appears as its unsigned 32-bit equivalent (4294967195) in the raw log output. The PC-side parsing tool (tilogger) then interprets this raw unsigned value.

    I have already checked the provided SimpleLink Academy and README collaterals, but they don't seem to address this specific signed integer interpretation issue on the host side.

    Kind regards, Kim

  • 0 in reply to Young June Kim
    TI__Expert 7645 points

    Hi Kim,

    thank you for the details.

    I checked the implementation and you are right.
    Unfortunately, the format is limited for %d/%i to positive values.

    Kind regards,
    Theo

  • 0 in reply to Theo Lange
    Prodigy 60 points

    Hi Theo,

    Thank you for confirming the %d/%i format limitation. It's helpful to know my understanding of the implementation details was correct.

    As you've noted, this limitation means that negative signed integers sent via Log_printf are effectively transmitted as large unsigned numbers due to the uintptr_t casting on the firmware side.

    My key question now is about the intended strategy for handling this on the host side, specifically with the tilogger tool.

    • Given this firmware limitation, is tilogger expected to perform the necessary conversion (e.g., re-interpreting the received uintptr_t value as a signed integer when the format specifier is %d or %i)?
    • Or is there a different recommended approach, perhaps a specific way to prepare negative values on the firmware side before passing them to Log_printf (similar to the RSSI workaround I mentioned previously)?

    Understanding this will help us determine the correct path for displaying accurate signed integer values in our logs.

    I also have a couple of related questions regarding tilogger's capabilities within this logging framework:

    1. String Format Specifier (%s): Does tilogger have plans to support the %s format specifier? My understanding from the documentation is that Log_printf sends a pointer to the string's address on the target. If so, tilogger would presumably need a mechanism to dereference this pointer (e.g., by reading target memory via a debugger connection) to display the string content.
    2. ELF File Usage: tilogger requires the .out file for log decoding. For release builds where we aim to limit exposure of sensitive information, we plan to use objcopy to create a stripped-down .out file containing only the .log_data and .log_ptr sections. Will tilogger be able to correctly parse logs using such a minimized .out file, or does it require the full debug .out file?

    Any guidance on these points would be greatly appreciated.

    Kind regards, Kim

  • 0 in reply to Young June Kim
    TI__Expert 7645 points

    Hi Kim,

    the parsing is done by the Python tool. It is filling the debug statements with the values sent from the target MCU and in this parsing step is the limitation.
    You can follow logger.py in SDK-dir\tools\log\tiutils\core\tilogger\


    Instead, you would need to assign different types to the variables in the tuple to parse them differently.

    The easiest option might be to convert the RSSI value to a positive scale.

    Kind regards,
    Theo

  • 0 in reply to Theo Lange
    Prodigy 60 points

    Hi Theo,

    Thanks again for clarifying that the parsing limitation for %d/%i lies within the Python tilogger tool, and that logger.py is the relevant file to look into. That was really helpful.

    Following your guidance, I've been trying to modify logger.py to correctly interpret uintptr_t values as signed integers when %d or %i format specifiers are used.

    I've attached my current logger.py file with the modifications I've attempted. 

    My goal is to convert the received unsigned 32-bit value back to a signed 32-bit integer, for instance, turning 4294967195 (which is 0xFFFFFF9B as an unsigned 32-bit int) into -101. My general Python approach for this uses struct.unpack('<l', struct.pack('<L', received_unsigned_value))[0], and it works in isolation.

    However, I'm finding it challenging to integrate this robustly into logger.py's existing parsing logic to correctly handle all cases based on the format string (%d, %i). Specifically, I'm having trouble with [briefly describe where you're stuck, e.g., "identifying where in the parsing loop to apply the conversion," or "ensuring the correct variable type is applied from the .out file's metadata," or "handling edge cases for very large unsigned numbers that should be negative."].

    Could you provide more specific guidance or an example of how this conversion should be applied within logger.py's context to ensure proper signed integer interpretation?

    Additional Questions on tilogger Capabilities

    I also have a couple of related questions regarding tilogger's broader capabilities within this logging framework:

    • String Format Specifier (%s): Does tilogger have plans to support the %s format specifier? My understanding is that Log_printf sends a pointer to the string's address on the target, so tilogger would presumably need a mechanism to dereference this.
    • Minimized ELF File Usage: tilogger requires the .out file for log decoding. For release builds where we aim to limit exposure of sensitive information, we plan to use objcopy to create a stripped-down .out file containing only the .log_data and .log_ptr sections. Will tilogger be able to correctly parse logs using such a minimized .out file, or does it require the full debug .out file?

    Your continued guidance on these points would be greatly appreciated.

    Kind regards, Kimtiutils_fail.zip

  • 0 in reply to Young June Kim
    TI__Expert 7645 points

    Hi Kim,

    yes you can remove sensitive information from the .out file following the readme (relevant part below)

    ELF Files Specification

    Non-logging related sections from your elf.out file may be removed as they may
    contain sensitive information. To do this, use the utilities found in your
    toolchain to run the appropriate command below:

    * GCC
       ```arm-none-eabi-objcopy --only-section=.log_data --only-section=.log_ptr input.out output.out```
    * TICLANG and IAR projects
       ```tiarmobjcopy --only-section=.log_data --only-section=.log_ptr input.out output.out```

    You can provide ELF files containing Log-string information either globally (to
    all transports you add) if you have just one device or if the devices run the
    same firmware, and you can provide the ELF files to each transport individually.

    Unfortunately, I can't provide you an example for parsing but I think you have are at a good staring point.
    The %s format specifier is not supported because the log message is contained in the .out file and only the variable state sent out.
    A good practice would be be to define conditions for sending out different debug messages on the embedded side.

    Kind regards,
    Theo