Issue transmitting USB data

[danielg14]

Hello,

I am currently attempting to create a USB interface for my project that will act as a virtual com port.

I am stuck in the enumeration stage of the USB communication.

I am receiving the setup packet from the computer, asking for the device descriptor to be sent. I set the address bytes of both of the ODD and EVEN buffer descriptors for the IN on endpoint 0 to be the address of my device descriptor in memory.

I get an error message after that (DMAERR). Can anyone please help point me in the correct direction to solving this problem?

-Thanks

[mjbcswitzerland]

Daniel

You don't say which part you are using. If it has MPU controller you can set

MPU_CESR = 0;

// allow concurrent access to MPU controller

to avoid access problems.

Regards

Mark

Kinetis: µTasker Kinetis support

USB User's Guide: http://www.utasker.com/docs/uTasker/USB_User_Guide.PDF

Composite USB: µTasker USB Device Configuration

For the complete "out-of-the-box" Kinetis experience and faster time to market

[danielg14]

Sorry, its the M20DX256vlk10.

I cleared the MPU_CESR bit already (This fixed the problem of no token being received at all). Now I can receive data, but not send it.

[mjbcswitzerland]

Daniel

Do you have the device descriptor in RAM or in Flash?

If in Flash you need to allow the USB controller to access by setting its bus master rights in FMC_PFAPR.

The USB controller in the K20 100M is bus master 4.

Are you re-developing a Kinetis USB stack? Freescale has a USB stack V5 which shows you how to do it (although may not work on all devices).

I have attached the FS device driver from the uTasker project as reference too, which supports multiple CDC instances and allows the Kinetis USB controller to be simulated for ease of driver and appliation development. It also works on all Kinetis KL and K devices without any porting requirements - including crystal-less operation and IRC48M workarounds.

Regards

Mark

Kinetis: µTasker Kinetis support

USB User's Guide: http://www.utasker.com/docs/uTasker/USB_User_Guide.PDF

Composite USB: µTasker USB Device Configuration

For the complete "out-of-the-box" Kinetis experience and faster time to market

[danielg14]

Originally it was in Flash, which I figured was causing the problem, so I changed it so that it was in RAM. Unfortunately the problem was still present.

For this project I am trying to create a simple USB CDC module that will be able to receive data from the computer and re-transmit it on the UART serial bus, and vis-versa. I downloaded the USB stack v5 before and I used that as a reference for this problem but had no luck.

From the couple examples that I have seen, you simply need to set the 'address' bits of both of the endpoint 0 Tx BDT entries to the address of the device descriptor in memory. My device descriptor is as follows:

static devdesc_t usbDeviceDesc =

{

  0x12,

  DESCRIPTOR_DEVICE,

  0x00 , 0x02, // USB 2.0

  DEVCLASS_COMMUNICATIONS,

  0x00,

  0x00,

  EP0_MAX_SIZE,

  0xA2 , 0x15, // Vender ID (MUST ACQUIRE)

  0x54 , 0x43, // Product ID

  0x01 , 0x00, // Device number

  0x01,

  0x02,

  0x03,

  0x01,

};

And this is how I handle passing the device descriptor to the bdt entry:

bdDataBuffer[ BD_IDX_EP0_IN_EVEN].addr = bdDataBuffer[BD_IDX_EP0_IN_ODD].addr = (uint8_t*)&usbDeviceDesc;     // Set addr to the device descriptor

bdDataBuffer[BD_IDX_EP0_IN_EVEN].desc.dts = bdDataBuffer[BD_IDX_EP0_IN_ODD].desc.byte32 = 0x00;                     // Clear information

bdDataBuffer[BD_IDX_EP0_IN_EVEN].desc.bc = bdDataBuffer[BD_IDX_EP0_IN_ODD].desc.bc = sizeof(usbDeviceDesc);// Set bc as the size of the device descriptor

bdDataBuffer[BD_IDX_EP0_IN_EVEN].desc.dts = bdDataBuffer[BD_IDX_EP0_IN_ODD].desc.dts = 0x01u;

// Allow data sync from the host

bdDataBuffer[BD_IDX_EP0_IN_EVEN].desc.data1 = bdDataBuffer[BD_IDX_EP0_IN_ODD].desc.data1 = 0x01u;                // Set Data1/0 to Data1

bdDataBuffer[BD_IDX_EP0_IN_EVEN].desc.own = bdDataBuffer[BD_IDX_EP0_IN_ODD].desc.own = 0x01u;                     // Allow access to the BDT

[mjbcswitzerland]

Hello Daniel

Without reviewing your code it is not possibe to say why you are having problems but I can give you the tip that the content of the buffer descriptor control entry should be 0x001200c8 for the initial device descriptor response (assuming 64 byte endpoint 0 size - if 8 byte endpoint 0 it needs to be sent as two buffers). The buffer descriptor data pointer is simply set to the source address (in RAM or in Flash as long as the USB controller has been gived rights to read from Flash).
Are you sure that you have the buffer descriptors correctly aligned (512 byte boundary)?

Are you re-developing a USB-UART bridge as a student assignment or is this for product development?

- For a student assignment you may prefer to look at Arduino code (eg. USB device from the Teensy K20 project - Teensy USB Development Board ) which allows you to do it very simply without needing to know internal working details but may be restritive in case you need more powerful features. If you wish to learn all internal working details the uTasker simulator allows this and is free for educational work. If your assignment is to construct the driver, CDC class and handle UART-CDC bridging with flow control you may however need to consider that it could take a number of weeks of work until basically developed, with a certain amount of validation testing before it is proven.
- For product development you may prefer to use ready made solutions that are industrially proven:
-- you may find something in the Freescale MQX Lite version if you need to use free software
-- The uTasker project includes USB-CDC with UART bridging function, including end to-end-flow control and will allow this on multiple UARTs as well as composite configurations with no development requirements.

In case you need to use your own code for product development and need specific help to solve problems and reduce development time you can also request consultancy services at uTasker support µTasker Support Page where all Kinetis USB devices are handled, including remote debugging on custom boards where needed.

Regards

Mark

Kinetis: µTasker Kinetis support

K20: µTasker Kinetis TWR-K20D72M support  / µTasker Kinetis FRDM-K20D50M support  / µTasker Kinetis TWR-K20D50M support  / µTasker Teensy3.1 support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[danielg14]

Thanks for all the advice! I will check those out.

My BDT entries match 0x001200c8 for both the even and odd IN endpoints for endpoint 0. And I am supporting the 64 bytes. I have the memory aligned with 512 bytes.

The only thing I might be doing wrong is what index of the BDT I should be working with. If I want to control the BDT entry for IN-bound data then that is indexed at the 2nd(EVEN) and 3rd(ODD) indices (ie starting at 16 bytes past the starting address of the BDT)?

[mjbcswitzerland]

Daniel

The BDTs are just ping-pong buffers and can be used in any order; I just simulated enumeration to check in the uTasker project and it also uses the same EVEN buffer, as you have chosen, for the first IN transmission.

Regards

Mark

Kinetis: µTasker Kinetis support

K20: µTasker Kinetis TWR-K20D72M support  / µTasker Kinetis FRDM-K20D50M support  / µTasker Kinetis TWR-K20D50M support  / µTasker Teensy3.1 support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[danielg14]

Ok So I've been looking at these example projects and I have a Kinetis freedom board with an example code for a USB-CDC running.

The chip on that board is a mk20DX128VLH5.

I brought over that code to my board ( the board was custom designed by someone else ) and the code does not even come close to working. A massive number of USB errors occur.

On the board I am working with I noticed that the VOUT3.3 (The USB regulated output) has nothing connected to it. In the reference manual it displays the VOUT3.3 with a decoupling capacitor. I also noticed the the VReg (which directly connects to the VOUT3.3 pin) appears to be used by the Dm/Dp signal lines of the USB module. Could the lack of a capacitor on the board cause an issue with transmissions?

[mjbcswitzerland · Accepted solution]

Daniel

The VOUT3.3 needs a 2.2uF capacitor. Without it USB will not work (this is a mistake that I have encountered before and can confirm that it must be corrected).

The input to the regulator is usually connected to the 5V line of the USB bus.

I am not sure which code you are referring to but also beware that the K20-50, K20-72 (as well as K20-F120) are in fact not fully compatible with each other or your K20-100. They have various differences requiring modified settings, especially in the clock set-ups. This is an added reason why using the FSL USB 5.0 stack (if you are referring to that) will probably need additional porting work. The closest Freescale board for your chip is in fact the TWR-K60D100 due to this reason. It would presumably be best to start with a working K60 project and port it to the K20-100 if that is your route, ensuring that the clock sources are suitable in the process

Regards

Mark

Kinetis: µTasker Kinetis support

K20: µTasker Kinetis TWR-K20D72M support  / µTasker Kinetis FRDM-K20D50M support  / µTasker Kinetis TWR-K20D50M support  / µTasker Teensy3.1 support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[danielg14]

I added the capacitor and it WORKED! =)

Thanks for all the help!

[danielg14]

Ok great! (Well hopefully that solves the problem). I will solder a cap on the board and see how things act after that. =)

Also I am looking at the registers for the crossbar (AXBS) and the peripheral bridge (AIPS0). Would the default (ie reset) values need to be changed to allow USB communication?

[mjbcswitzerland]

Daniel

The crossbar switch settings do not need to be modifed for basic USB operation.

However, if you have a lot of burst memory-to-memory DMA [RAM<->RAM or Flash->RAM] you can find that some USB errors occur (invalid frames that are repeated by the controller ad so not actualyl noticeable at higher levels) due to the fact that the flash and SRAM slave priorites are higher than the USB slave's.

Setting the crossbar switches to use round-robin strategy rather than polling solves this by allowing the USB controller to steal cycles even if there is a memory-memory burst transfer in progress.

Regards

Mark

Kinetis: µTasker Kinetis support

K20: µTasker Kinetis TWR-K20D72M support  / µTasker Kinetis FRDM-K20D50M support  / µTasker Kinetis TWR-K20D50M support  / µTasker Teensy3.1 support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[danielg14]

Thanks for the tip!

And again thanks for all the help.

I now have a fully configured USB device that my computer recognizes and I can send data to. =)