USB-CDC and UARTs with ECOM-Comm

We are currently using a few UARTs through ECOM-Comm. I would like to add USB-CDC.

In the project from our training, I noticed the following configuration in STM32F746GDISCO-Met-CM7hardfp_ARMCC5-configuration/ecom-comm/bsp.xml:

        <nativeImplementation name="LLCOMM_UART" nativeName="LLCOMM_BUFFERED_CONNECTION"/>
        <nativeImplementation name="LLCOMM_CDC" nativeName="LLCOMM_BUFFERED_CONNECTION"/>

Is this the correct way to configure it?
I read the Device Developer’s Guide or Application Note: TLT-0652-AN-MICROEJ-ECOM-COMM, but I didn’t see any information on doing this.


Hi Lyle,

Indeed, you need to define the CDC in the bsp.xml. Then in your implementation, you need to add the bsp implementation.

For the STM32F746G-Disco, you can see:

  • \Projects\STM32746G-Discovery\Applications\MicroEJ\inc-comm\LLCOMM_CDC*
  • \Projects\STM32746G-Discovery\Applications\MicroEJ\src-comm\LLCOMM_CDC.c
  • \Projects\STM32746G-Discovery\Applications\MicroEJ\src-comm\comms.c

Finally, you can use it, see


Thank you Pierre. I could get dynamic USB connections working with that information.

I found something I don’t understand in comms.c. It has the following code:

void LLCOMM_IMPL_syncConnectionsEnter(void)
	xSemaphoreTake(sync_connections_sem, 0);

It looks like it polls the semaphore, and returns immediately whether the semaphore was taken or not.

Did I understand this correctly? Blocking the task would be a problem, but how does this prevent race conditions for dynamic connections?


Hi Lyle,

This is a bug on our code, it should be a waiting for portMAX_DELAY instead of 0.
If we are already running on a critical section, then the task will be suspended until we exit the section with LLCOMM_IMPL_syncConnectionsExit.

Blocking the task would be a problem

Why would it be an issue?


Thank you. I will update our code.

Problem was too strong a word. Maybe inconvenient? I was just thinking that it would block the JVM task, so all Java threads would be blocked.

Hi Pierre,

I changed the value to portMAX_DELAY, and it locked up the JVM task.

I think this may be what happens, although it may happen in the same thread:

  1. Thread 1 takes the semaphore
  2. Thread 2 attempts to take the semaphore
  3. The FreeRTOS Task is blocked
  4. Thread 1 can not run, so it will never release the semaphore

Does this sound correct to you?


Hi Pierre,
I’m working on this again. I think I missed some things from the example project. I should be able to figure the rest out by myself.