Disabling DTR check in USB Debug console+ fsl_shell

[patriciocohen]

Hi,

After some days I have managed to make the debug console work through USB. At first I had the problem that the MCU program was hung until the DTR signal was activated in the PC terminal. After some research I was able to disable it and now the program runs without waiting for the DTR signal to be set.

Now I'm experiencing the same problem when adding the fsl_shell to the project. Everything gets stuck until DTR signal is sent from the terminal. I haven't been able to make it work, can someone at NXP give me a helping hand?

My last post regarding this topic:

https://community.nxp.com/t5/i-MX-RT/I-MXRT1060-debugconsole-via-USB-NOT-OpenSDA/m-p/1775742

Thank you and best regards,

Patricio 

[patriciocohen]

I have tried a lot of things, but nothing seems to work.

Please someone help me.

Best regards,

Patricio

[mjbcswitzerland]

Hi Patricio

Please load the binary image here to your RT1060EVK: https://www.utasker.com/iMX/RT1060.html#DUAL_USB_CDC_DEV

The description is:
"Complete project reference with dual-USB-CDC device, including boot loader, which can be loaded (copied to its QSPI-Flash) using your favorite loading tool - for example NXP MCUBootUtility.
This application supports a command line interface on the LPUART (connected to the board's VCOM interface) at 115'200 Baud. When the first HSUSB interface is connected to a host it appears as the same command line interface via USB-CDC [if blocked by the LPUART interface command "quit" to free it]. In the USB menu a USB-CDC to LPUART bridge can be commanded using the comand "usb-serial", whereby the LPUART's baud rate follows that set by the terminal emulator on the USB-CDC interface.

The second HSUSB enumerates as a second USB-CDC device and will echo back all received data."

and tell me whether you have the same issue with it or not.

Depending on the result I may then be able to tell you what needs to be changed in the SDK reference to allow it to work.

Regards

Mark

[patriciocohen]

Hi Mark,

Unfortunately my project is based in FreeRTOS, so what you are offering is not a solution for me.

Thanks you,

Patricio

[mjbcswitzerland]

Hi

I checked the SDK reference that you are using.

In

USB_DeviceCdcVcomCallback()

in fsl_component_serial_port_usb.c there is a case that handles the line state:

case kUSB_DeviceCdcEventSetControlLineState:

It handles the state with (I think it calls it DTE with reference as an input since it is DTR):

if (0U != (acmInfo->dteStatus & (uint8_t)USB_DEVICE_CDC_CONTROL_SIG_BITMAP_DTE_PRESENCE))
{
/* DTE_ACTIVATED */
if (1U == serialUsbCdc->attach)
{
serialUsbCdc->startTransactions = 1U; <---- allows the code to operate
}
}
else
{
/* DTE_DEACTIVATED */
if (1U == serialUsbCdc->attach)
{
serialUsbCdc->startTransactions = 0U; <---- causes the code to spin forever on a semaphore
}
}

and if it is set to 0 serialUsbCdc->startTransactions is set to 0 and the result is that the code spins in a wait loop on a semaphore called _debugConsoleReadWaitSemaphore in GetChar() so nothing is done (apart from handling USB interrupts).

If you set
serialUsbCdc->startTransactions = 1U;
in both cases it is then insensitive to the DTR state and so will always operate.

Regards

Mark

[patriciocohen · Accepted solution]

Hi Mark,

Thanks for your help. Unfortunately the problem persists. So, I modified the current fsl_shell.c to use the debug console instead of serial manager, and everything works great now.

Best regards,

Patricio 

[mjbcswitzerland]

Hi Patricio

That change worked in the original SDK reference but if you use it within a different environment it may have other issues and also not work whatever the state of the DTR is.
This is because the examples are generally to show a specific operation and not necessarily work as a part of a larger design - in the case of the original example the blocking on the semaphore would stop 'everything else' working too, unless each 'example' is put into a dedicated task in a pre-emptive multitasking environment and the tasks don't block each other.

Regards

Mark

[mjbcswitzerland]

Hi Patricio

Running the binary to answer the question would help.

The project also works with FreeRTOS so if you don't find a solution quickly it may help save you time and cost. I am however focusing on identifying the SDK issue so that the root cause is understood; since I have the capability to simulate the complete USB operation it is usually quite easy to understand what is actually going on and provide a fix to learn from: Eg. https://www.youtube.com/watch?v=3irORtbc4e0&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=31

Regards

Mark

[mjbcswitzerland]

Hi Patricio

The terminal sends the DTR and RTS states via the SET_CONTROL_LINE_STATE request on the control endpoint 0. This is the request value 0x22.

If you can identify where this OUT data is handled on that control endpoint you can see how the code responds to it. Presumably it reacts to the state that is received (the DTR is the first bit in wValue) and then you can remove this (presumably unwanted) handling and execute any pre-requisit for operation (from there) automatically when the device has enumerated.

Regards

Mark

For industrially proven USB solutions for professionals since 2008 (compatible on Kinetis and i.MX RT) see
https://www.utasker.com/docs/uTasker/USB_User_Guide.PDF
https://www.utasker.com/docs/uTasker/uTaskerV1.3_USB_Demo.PDF

For our discounted i.MX and Kinetis stock availability see https://www.utasker.com/Shop/semi.html