Kinetis Design StudioのトピックRe: why USB_LDD cannot work correctly?

why USB_LDD cannot work correctly?

jianfengzheng — Thu, 06 Jul 2017 09:35:29 GMT

I use MCU MK22FN256VLL12, the development tool is KDS3.2.0.

I implement USB device by ProcessorExpert, and generate USB_LDD.

After USB device(i.e. my PCB) is attached to PC, it begin to 'standard device request', it works well as below:

1. GET_DESCRIPTION (type=DEVICE) ------- OK

2. SET_ADDRESS ------- OK

3. GET_DESCRIPTION (type=DEVICE) ------- OK

4. GET_DESCRIPTOR (type = CONFIGURATION) ------- fail, host closed the USB port

I have tried many times, it always failed on the 4th step at each time.

I am sure the previous three steps are successful, because the USB device can be showed by a tool named as 'USB Monitor'. following is the cut picture.

Port5 is my PCB, there Vendor=0x1234, Product ID=0x1122 are correct.

My question is:

Why the host quits instead to continue to request CONFIGURATION DESCRIPTOR

What is the problem, I have tried one week to search the BUG, and have to give up today, and need your help now.

The attached file is my KDS project. the drive file is <drive_usb.c>, please help me to check it .

Please note, this <drive_usb.c> worked OK on my another PCB, although, it is designed by different MCU, MKL26Z128VLH4. It can be correctly detected as following also by USB Monitor

THANK YOU ! Wait here Anxiously!

Original Attachment has been moved to: K22NUSB.zip

Re: why USB_LDD cannot work correctly?

jorge_a_vazquez — Mon, 17 Jul 2017 21:27:13 GMT

Hi Jianfeng Zheng

Regard your request; Have you checked this community document?

Creating a New USB project with KSDK and Processor Expert support in KDS

Here a colleague explain how to create a new USB device project with Processor expert and SDK 1.3. Please use it as reference if you want to create a project with processor expert.

Also, please check this community post:
USB Host Project with KSDK 1.3 and Processor Expert
It also show USB Host project, it gives some recommendation about PE and USB.

Unfortunately I tried to test your code and I couldn't compile it because it has relative paths to your workspace. Also, I noticed that you are implementing your own USB drivers, is it possible for your application to use our USB drivers? and if possible, use the latest USB stack that comes with SDK 2.2?

Best Regards

Jorge Alcala

Re: why USB_LDD cannot work correctly?

jianfengzheng — Tue, 25 Jul 2017 09:43:13 GMT

Jorge Alcala:

Thank you for your answer.

However, the two documents you recommended cannot help me.

I believe you should test my code, then help me to get over the problem.

I wonder if my project used "linked" mode, so you couldn't compile it.

Therefore I have changed the mode to "standalone" mode. Please see the attached file.

Also, I suppose the USB drivers are not related to my problem, since the HOST has not enumerated the DEVICE.

Thank you again, very much!

Re: why USB_LDD cannot work correctly?

jianfengzheng — Mon, 07 Aug 2017 10:01:21 GMT

Answer by myself.

Today, eventually, I have found the bug.

I suppose the reason is the USB Engine can't read FLASH ROM.

As it happens, the variable "ConfigDescriptor" is located in FLASH ROM, however the "DeviceDescriptor" is located in RAM, look at following codes:

static LDD_USB_TDevDescriptor DeviceDescriptor = {.....};

static const unsigned char ConfigDescriptor[] = {........}; // note the "const" keyword

At 1st step, GET_DESCRIPTION (type=DEVICE), it is correct.

but when GET_DESCRIPTOR (type = CONFIGURATION), MCU cannot read correctly ConfigDescriptor from FLASH ROM.

As soon as the "const" is deleted, the USB device is enumerated successfully!

ps. this problem occurs only for CortexM4F platform, But Cortex M0+ has not this shortcom. Hence my another board based on MKL26Z128, whose USB code is the same, is normally running.

That's all.

Re: why USB_LDD cannot work correctly?

PitOn — Thu, 16 Nov 2017 17:42:33 GMT

This is not the problem.
There the problem of alignment of these structures.
If you change the code, it will stop running.