• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 1301 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.

RTOS/TM4C123GH6PM: Usage of fprintf within UART callback leads to assertion

Volker Weber
Intellectual 570 points
Part Number: TM4C123GH6PM


Tool/software: TI-RTOS

Hi,

I am using the SysCallback implementation with usage of System_printf within my implementation. Furthermore I am using a debug implementation with a fprintf functionality which leads my output to stderr which is mapped to the UART interface:

    freopen("UART:0", "w", stderr);
    setvbuf(stderr, NULL, _IOLBF, 128);

If I use the debug mechansim within a single thread it works as expected. However, the usage within another UART callback leads to an assertion:

$ ti.sysbios.gates.GateMutex: line 99: assertion failure: A_badContext: bad calling context. See GateMutex API doc for details.
xdc.runtime.Error.raise: terminating execution

The documentation is talking about this:

Cause: Calling System_printf() or printf() from a Swi or Hwi when xdc.runtime.SysStd is your System.SupportProxy.

As far as I know are UART callbacks neither HWIs nor SWIs. Furthermore the usage of SysMin is no alternative. What am I doing wrong?

  • 0
    TI__Guru* 96960 points
    Hi Volker,

    The UART callback is made in Hwi context.

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 570 points

    Thanks Todd for the quick response. I mixed up again the terms of "Vector Number" and "Interrupt Number" which is confusion implemented, from the documentation:

    Whereas the ROV speaks about the Interrupt Number but means the Vector Number:

    Besides this: why is a System_printf working whereas a fprintf will lead to a assertion?

  • 0 in reply to Volker Weber
    Intellectual 570 points

    Volker Weber said:

    Besides this: why is a System_printf working whereas a fprintf will lead to a assertion?

    I add this to my question: looking for a way to use the xdc/runtime/System.h implementations I found several print function, however a fprintf functionality is missing there. How can I explicitly print to the stderr output using these mechanics?

  • 0 in reply to Volker Weber
    TI__Guru* 96960 points
    Hi Volker,

    I'll answer this tomorrow.

    Todd
  • 0 in reply to ToddMullanix
    TI__Guru* 96960 points
    Volker,

    It looks like you have fprintf tied to a UART. You cannot call UART_write() in the context of a Hwi. You can call UART_writePolling() though.

    I'm not sure what you have System.SupportProxy set to so let's look at the three most common ones:
    1. SysMin: When System_printf is called, the ASCII string is stored in an internal buffer. This can be flushed to the CCS console via System_flush() or if the program exits/aborts.
    2. SysStd: When System_printf is called, printf is used. So it gets written to the CCS console by default. Note: this breaks real-time.
    3. SysCallback: by default nothing happens with a System_printf unless you plug in your functions.

    So in all three cases System_printf can be called from an Hwi.

    Todd