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.

RTOS/CC2640R2F: 2nd UART

Part Number: CC2640R2F

Tool/software: TI-RTOS

Hi,

I want to communicate with a sensor over UART while still using UART for logging?

Is there a 'SoftwareSerial' driver available?

Cheers,

Evan

  • Hi Evan,

    There is no Software UART driver available for the M3 part of the CC2640R2F. There is a UART emulator available in the sensor controller which you could use as a second UART port if you are not currently using the sensor controller.
  • Great, thanks. I hadn't considered the sensor controller. I'll check out the demo project.

  • Hi Evan,

    There should be a UART Emulator example available inside Sensor Controller Studio. The Project folder should contain CCS and IAR projects as well that is to be used together with the Sensor Controller project.
  • Thanks, I found the example.  Looks like the sensor controller can't use TDO for the transmit pin? I can't select it in the IO mapping.  I was hoping to use this pin with the AUX serial port of an XDS1000 debugger.

    Also, I assume (e.g. by e2e.ti.com/.../541746) that there is no display driver using the sensor controller?  Is it a simple matter of copying the UART display driver and updating all the UART driver procedure calls to those of the SC uart emulator?

  • Hi Evan,

    You are correct, TDO is not available for the Sensor Controller on CC2640R2F. Only a limited set of the device I/O are available for the Sensor Controller as you can see in the IO mapping.

    The display driver is not available for the Sensor Controller application. I don't think it is as simple as replacing the UART driver straight up in the display driver but with some work I think you can be able to port it.

    You could also possible do your own log function by wrapping sprintf and the SC uart emulator API.
  • I am having trouble getting the example to work.  I am using simple_peripheral as the starting point and have added the following to the end of `SimpleBLEPeripheral_init`:

        scifUartSetBaudRate(115200);
        scifExecuteTasksOnceNbl(BV(SCIF_UART_EMULATOR_TASK_ID));
        scifUartTxPutChar('a');
    

    I have set the SC TX pin to IOID_12 which is connected to an FTDI device (which I know works as I have tested with the hardware UART on this pin) and hardware uart to IOID_5 (connected to the XDS1000 and using the display driver).  I can see the hardware UART output but nothing from the sensor controller.

    Do I need to call the sc init function, `scifInit(&scifDriverSetup)`.  When I try doing this as the first line of the above code I still get no output and the hardware UART starts outputting garbage.

  • So I realized I had the wrong chip defined in the sensor controller code (facepalm). When I fixed that, the code above (including the scifInit line) worked! I'll see if I can port the display driver. Is there a github I can post a pull request to if I get it working so it can be shared with the community?
  • Hi Evan,

    Great news, I'll look forward to seeing if you are able to get a display driver port together for the SC.

    Unfortunately, there is no community repo available from TI that you could share the work on. What you can do is to post your solution here or in a new thread which will make it possible for everyone on the forum to find it.
  • Hi M-W,

    Ok, no worries.  I believe I have both logging and the display driver working but I'll do a bit more testing and clean-up before posting.  It's a bit messy due to having to include all the sensor controller code, and I had some issues integrating the display driver into the ti source libraries (i.e. running the makefile) so I've just kept it as a separate include for now.

    Cheers,

    Evan

  • Hi M-W,

    I was having some issues where characters were missing from the output and found I had to throttle the transmitting, even when only sending one character at a time.  Any idea why this might be happening?

    for (i = 0; i < count; i++)  {

    // Loop while still data being sent while(scifUartGetTxFifoCount() > 0) { ;; } scifUartTxPutChar(buf[i]); }

    - Evan

  • Hi Evan,

    I'm not sure on why this might be, my understanding of it is that you should only have to stall if the TX FIFO is full. I will have to look at this myself to give you any good advice on why. Would it be possible to maybe share your efforts?

  • These are the files for logging.  Assumes you have the files from the sensor controller studio output in the project directory and otherwise integrated as per uart_logs (SCUart_init in main.c, update the RTOS cfg file for logging calls).

    /cfs-file/__key/communityserver-discussions-components-files/158/sc_5F00_uart_5F00_logs.c

    /cfs-file/__key/communityserver-discussions-components-files/158/sc_5F00_uart_5F00_logs.h

  • Hi Evan,

    I tried the SC part of your code out and I can not find any problem there. What I did was simply doing sc_uartLog_doWrite calls with a longer string multiple times without seeing any data loss even if removing the delay loop.

    I did not manage to get the full Log situation running, maybe you could share an existing project you have that I can test out?
  • Hi M-W,

    It's late here (Melbourne/Australia) so I will put together a project tomorrow.  But in the meantime, here's the config additions I use.  I will also double-check I still see the issue when the delay is removed.

    // Need Text loaded for formatting of Log_info/warning/error, but not for Log_print.
    Text.isLoaded = true;
    
    /* ================ Logging configuration ================ */
    // Logging
    var Log = xdc.useModule('xdc.runtime.Log');
    
    // Override error output color with ANSI codes, and use shorter (file.c:line) format.
    Log.L_error =  {
        mask: Diags.STATUS,
        level: Diags.ERROR,
        msg: "\x1b[31;1mERROR:\x1b[0m (%s:%d) %$S"
    };
    
    Log.L_info = {
        mask: Diags.INFO,
        msg: "\x1b[32;1mINFO:\x1b[0m (%s:%d) %$S"
    };
    
    Log.L_warning = {
        mask: Diags.STATUS,
        level: Diags.WARNING,
        msg: "\x1b[33;1mWARNING:\x1b[0m (%s:%d) %$S"
        };
    
    // Pull in LoggerCallback
    var LoggerCallback = xdc.useModule('xdc.runtime.LoggerCallback');
    
    // Tell LoggerCallback to call our output function
    LoggerCallback.outputFxn = "&sc_uartLog_outputFxn";
    
    // Tell the Idle module to add our flush() function to the idle loop (before Power)
    var Idle = xdc.useModule('ti.sysbios.knl.Idle'); // Add if Idle isn't already imported.
    Idle.addFunc('&sc_uartLog_flush');
    
    // Create a static instance of LoggerCallback and set as default Main logger
    var loggerParams = new LoggerCallback.Params();
    loggerParams.arg = 1;
    
    // Only for Main (code that's not in an rtsc module)
    Main.common$.logger = LoggerCallback.create(loggerParams);
    //Defaults.common$.logger = LoggerCallback.create(loggerParams); // Use for all log events
    
    // Turn on USER1 logs and INFO in Main module (user code). Turn off USER2 for fun.
    Main.common$.diags_USER1 = Diags.ALWAYS_ON;
    Main.common$.diags_USER2 = Diags.ALWAYS_OFF;
    Main.common$.diags_USER6 = Diags.ALWAYS_ON;
    Main.common$.diags_INFO = Diags.ALWAYS_ON;

    Obviously, xdc_runtime_Log_DISABLE_ALL needs to be undefined.

    I've been using the logging now for a few days testing the UART motor controller driver I am working on and all seems good apart from this issue.

  • Hi Evan,

    Were you able to try out removing the delay again and if so, what was the results?
  • Hi M-W,

    Sorry, I had to switch focus and work on getting the hardware designed before a deadline.  Hopefully can revisit early next week and will post the results.