• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 3 answers
  • Subscribers 30 subscribers
  • Views 538 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.

Original question:

CCS/IWR1443BOOST: Not able to print on console

IWR1443BOOST: System_printf to console failure

JH
Prodigy 20 points
Part Number: IWR1443BOOST
Other Parts Discussed in Thread: UNIFLASH

While using the Level Sensor Demo (high_accuracy_14xx_mss), I am unable to print from main.c. I am using CCS version 12, SDK 2.1.0.04, mmWave Industrial Toolbox 4_11_0. At this time, I'm just trying to get any serial print to work. Here's my current code:

//sprintf("%d Range\n",tempRange);
dummyDetectionOut.rangeIdx = (uint16_t) tempRange & 0xFFFF;
dummyDetectionOut.x = tempRange >> 16;

dummyDetectionOut.peakVal = (uint16_t) tempRange1 & 0xFFFF;
dummyDetectionOut.y = tempRange1 >> 16;

dummyDetectionOut.dopplerIdx = (uint16_t) tempRange2 & 0xFFFF;
dummyDetectionOut.z = tempRange2 >> 16;

(above unchanged from the demo)

System_printf("Hello World");
System_flush();

I've tried the following:

1. Default settings in the cfg file (with and without system flush)

2. cfg file modified as follows with a SysMin variable (with and without flush):

var SysMin = xdc.useModule('xdc.runtime.SysMin');
SysMin.bufSize = 32;
System.SupportProxy = SysMin;

For both SysMin and SysStd, I then navigated to Tools -> ROV classic --> SysMin/SysStd and checked what it said there -- in both, it says "Target Running" but shows no other data.

In all cases, the program builds and runs without error -- just also without an output on the serial. 

Thank you for your time!

  • 0
    TI__Genius 17265 points

    Hi,

    To be clear, do you see the existing prints properly outputting to the console?

    Best Regards,
    Alec

  • 0
    Prodigy 20 points
    1. Yes. If I put a test print in those spots, I likewise see it. I believe the problem has to do with where I'm trying to call the print, and I'm not sure how to work around it.
  • 0 in reply to JH
    TI__Genius 17265 points

    Hi,

    Got it. Also, have you tried without the system_flush call? I wonder if perhaps it is interrupting something which is in progress. I also know that most of the printf calls are made before chirping is active, so it is possible that the system printf call is cycle intensive and is causing issues with the processing completing in time

    Best Regards,
    Alec

  • 0 in reply to Alec May
    Prodigy 20 points

    Yup, I've tried with and without system_flush. My end goal is to see the data output on my console rather than in the GUI. I'm considering trying to open a new UART channel and do a UART_Write to the console instead of using System_printf, but I'm not sure how to do that (or then how to direct it to the console instead of to the GUI). Do you have any suggestions? 

  • 0 in reply to JH
    TI__Genius 17265 points

    Hi,

    Got it. It's worth noting that the CCS console is not really meant to be used to display the output data from the device in real time. It may be easier to output it via the existing UART data port, and to simply modify the format to fit your needs and then view it via a serial terminal interface such as Teraterm.

    Best Regards,
    Alec

  • 0 in reply to Alec May
    Prodigy 20 points

    That's great advice - I didn't even think about using a non-CSS terminal interface.

  • 0 in reply to Alec May
    Prodigy 20 points

    Alec,

    I connected to Tera Term and now all I see is this:

    I connected to the XDS110 Class Application/User UART. Before connecting to Tera Term, I confirmed that the GUI was receiving output, and then I disconnected the Gui and closed UniFlash. My device is in functional mode. This results from toggling the NRST button or from running from the debugger. I have my Tera Term speed set to 115200, which is the recommend speed listed on the GUI. Can you advise as to why no data is populating?

    Edit: I also have it set in functional mode, 1 0 0.

    Edit #2: I have also attempted this across the XDS110 Class Auxiliary Data Port at the recommended baud rate of 921600, and I get this:

  • 0 in reply to JH
    TI__Genius 17265 points

    Hi,

    Yes, the info you are seeing on the XDS110 Class Auxiliary Data Port is the actual radar data. Since it is in a binary format, you will likely want to use the logging function built into teraterm (make sure to select the option to record as binary format) and then you can refer to the lab documentation for more info on the exact format of the binary data. If you want to make a custom data format, you would modify the UART data transmit code in the lab in order to do this.

    Best Regards,
    Alec

  • 0 in reply to Alec May
    Prodigy 20 points

    Hm. When I set the option to record in binary format, I still get gibberish. I looked into the lab documentation prior, so I know that I should be seeing some combination of headers, "Magic words", and data. Is that expected, and I should move on to Tera Term forums/documentation, or should I be seeing readable data?

  • 0 in reply to JH
    TI__Genius 17265 points

    Hi, 

    When you say gibberish, what exactly do you mean? When you record it as a binary file, you should be able to view it and scan for the magic word, and then follow the frame format to parse it. Feel free to attach a sample log here if it still does not make sense. Also, be sure that the data port baud rate is set to 921600, while the CLI baud rate is 115200. 

    Best Regards,
    Alec

  • 0 in reply to Alec May
    Prodigy 20 points

    Using Tera Term, I was unable to get it to show in a binary or hex format in the terminal. However, I've since switched to Serial Port Monitor and was able to get that program's file to open in hex. Interestingly enough, I don't see the magic word. According to main.c, I should be looking for:

    header.platform = 0xA1443;
    header.magicWord[0] = 0x0102;
    header.magicWord[1] = 0x0304;
    header.magicWord[2] = 0x0506;
    header.magicWord[3] = 0x0708;

    So presumably, I should see something as follows: 01 02 03 04 05 06 07 08, followed by the data I need. Is that correct?

  • 0 in reply to JH
    TI__Genius 17265 points

    Hi,

    I believe this can get a bit weird due to byte ordering and endianness. I pulled up a log I had laying around for a different demo, and I believe it appeared as 
    02 01 04 03 06 05 08 07. The easiest thing would likely be to record a log of the UART stream, and you should be able to pretty quickly identify the magic word. However, I believe the pattern that I posted above should be correct.

    Best Regards,
    Alec