bare metal usb stack 4.1.1 cdc

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

bare metal usb stack 4.1.1 cdc

1,050 Views
marcobehr
Contributor I

Hi,

I stuck at implementing bare metal USB stack on FRDM-K64F which should work as an USB Host for a single CDC device.

The K64 shall be used to connect to a specific CDC device (which is realised on a Microchip PIC24F Microcontroller). The K64 sends commands to the PIC which executes them and responds in some cases with about 200 characters. I have problems with receiving this response if it is larger than 64 characters. There are no problems when sending an command with less than 64 chars and receiving a response with <64 chars.

At first, Initialize USB controller as follows:

- Set up clock to work at 48MHz

- enable USB and Interrupt for USB

- init Polling structure

- call usb_host_init

- register driver info table

- set up a FILE_CDC structure

- when a matching CDC device is attached, the file will be opened and from now two functions (CDC_Write and CDC_Read can do their work)

- The CDC_Write  uses _io_cdc_serial_write to transmit a given command string to the CDC device -> here are no problems

- The read function shall use _io_cdc_serial_read to collect the received data - I tried different ways to get the incoming data but none worked correctly:

1.  giving the _io_cdc_serial_read function a big buffer and let it read e.g. 4096 chars will return with e.g. 150 received characters (which might be a correct number of chars)

     Most of the received data in the buffer are correct, but some are corrupted and overwritten with 0x00 which does not come from the cdc device (PIC controller). I think the corrupted

     data are at intervals of 64 characters (which is the packet size of the CDC device)

2.  let the _io_cdc_serial_read function only read 1 character at a time and collect them in a loop will make the K64 stuck because it will hang in the time_delay function and watchdog reset      happens. This way it is possible to call serial_read 2 times, the 3rd one will never return - I don't know whats the reason for this

3.  choosing a buffer size which is matching the packet size of 64 works for the first read but the second will also be corrupted (some of the characters are overwritten with 0x00 values)

The incoming data stream from CDC device uses \n (and not \r) as end of line character - could this be a problem because the documentation of _io_cdc_serial_read says it expects \r?

In this case, how can I change the line end character which is expected?

I use the ARM GCC compiler.

In case more information is required please ask.

Thank you for helping.

PS: It's a pity the USB stack is really bad documented for somebody who doesn't use Processor Expert or doesn't want to use Freescale MQX OS.   

0 Kudos
1 Reply

564 Views
isaacavila
NXP Employee
NXP Employee

Hi Marco,

Just as reference, there is baremetal firmware for USB (Host and Device) in KSDK 1.2.0. () This USB firmware is almost the same as the standalone stack and MQX's, but you can use it in its baremetal option and has a lot of improvements.

There is also a host cdc example for FRDM-K64 and I did a simple test. I connected 2 FRDM-K64 boards (One as Host, another as device) and download the cdc example to each other (Host CDC and Device CDC respectively) and it can receive more than 64 bytes without errors.

Maybe you should look at this example and use it as guidance.

(Note: In my case, i could only send OUT data in 64-bytes-length packets, due how device CDC example was designed, but you should be able to use it without restrictions with your CDC device)

I hope this can help you

Best Regards,

Isaac

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

0 Kudos