UART and USB (HID Device) threads work separately, but not together?


Has anyone encountered a similar issue?

I have two threads: the UART thread has two UART peripherals (1200, 8n1), and I do make use of the callbacks and interrupts (e.g. UART_EVENT_RX_CHAR is an event I rely on); the USB thread is a HID, and should be sending simulated keystrokes to the computer (the USB Device HID example project for the S7G2-SK). 

When I disable the UART thread, the keystrokes are received and appear in e.g. a blank Notepad text file. 

When the UART thread and USB thread are both enabled: it appears that the UART thread is working (I see communication in/out), but the USB simulated keystrokes are not received. 

I have tried:

- changing the priorities of the threads (making USB the higher priority) 

- increasing the time slicing interval that the USB thread receives

- increasing the number of ticks per second in the ThreadX source, so that a tick period went from 10ms to 0.1ms. 

A breakpoint set in the USB code does hit consistently. After a certain period, the ux_device_class_hid_event_set() function call returns 0xFF, which I read in the X-Ware docs indicates that the USB circular buffer is full. 

As far as I know, USB HID hosts poll for these events – this, plus the 0xFF error code, led me to wonder if the PC was not polling. I'm leaning towards "not polling". The simulated USB HID does show up in Windows' Device Manager as a HID Keyboard Device, so it's at least enumerating correctly. I'm unsure if it's possible to determine from there whether the OS or driver is polling the device, however.

In any case, would anyone be able to shed some light on why the UART/USB interaction may be causing the latter to stop working as intended? 

  • Changing both of the thread priorities to 20 resolved the issue. 



    Based on this thread response, which mentioned that some SSP components spin up helper threads, I found a post about identifying running threads.

    Based on this response to that second thread, I opened up the RTOS Resources view. Note that there are two, one under Renesas OS and one under Partner OS -- choose the latter. The Renesas OS > RTOS Resources did not work for me, just showed a blank white box.


    It showed that there was a thread that seemed to be created by USBX at runtime. Seems it may be the thread that handles the polling from the host? 

    Setting the other threads' priorities to give CPU time to _ux_device_class_hid_interrupt_thread worked; simulated keystrokes are now received. 


    Edit: I also had to retain the changes to the ThreadX Source settings: 10000 (ten thousand) ticks per second, and giving the HID thread 10000 (ten thousand) time slicing ticks as well. UART thread still has the default time slicing interval of 1 tick (which somehow works).

  • In reply to hnguy:


    Thank you for sharing your solution with us.

    Kind regards,
  • Hi hnguy,

    How is your UART callback communicating with its thread? Performing busy waits (while loops waiting for a variable to be set/cleared) will block lower-priority threads from executing. It is recommended to implement waits in RTOS-friendly fashion, i.e. through use of thread objects (like semaphores, queues or event flags).

  • In reply to Renesas Karol:

    Hi Karol,

    The callbacks either do a single and immediate UART write or read -- or, as you mentioned, clear a flag or push data onto a queue. Now that you mention lower-priority threads being blocked, I wonder if even the UART reads/writes are taking too long still. Thanks!

  • In reply to hnguy:

    Hello hnguy,

    Thread-friendly waits (e.g. queue read with non-0 wait delay) will allow other, lower-priority threads to execute in the meantime.

  • In reply to Renesas Karol:

    I will give it a shot. Thank you!