USB-CDC and UARTs with ECOM-Comm

MicroEJ SDK
1

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:

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

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.

Lyle

2

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 https://github.com/MicroEJ/Example-Standalone-Foundation-Libraries/tree/master/com.microej.example.foundation.ecom.hotplug

Regards,

3

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?

Lyle

4

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?

Regards,

5

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.

6

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?

Lyle

7

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.
Thanks,
Lyle