NXP Bare Metal USB Stack on K20 won't enumerate

[CzechThunder]

Hi All,

Just taking a shot here.  I have known good hardware.  I'm using a K20 with a USB3320 PHY.  I have an older version of the stack (when it was Freescale) that runs on this same hardware without issue.  I'm running High Speed Mode, device mode only, CDC class.

I'm trying to upgrade to a newer version of the stack because the driver code on the older stack, version 3.8.x is virtually incomprehensible from a readability/maintainability standpoint.  The upper layers of the CDC class and USB framework are largely the same, though.

The problem I'm having with the 4.1.1. stack is that on the very first enumeration request, the driver sends back all "FF" data in the response packet.  I know this because I've traced it with a hardware based USB network analyzer.  But the receive side works fine.  The incoming setup packet is the correct 8 bytes and the data is correct.  The transmit side has the  issue.  It sends the correct size packet, but the data is garbage.  I've verified that the EPLISTADDR is correct, and the DTD pointers look good.  I don't see anything obviously wrong.  All the functions in the driver are returning success codes.  The actual device descriptor, the 18 byte structure, is in memory that should be accessible.  Overall, the memory mapping is very similar between the two versions of drivers

Does the "FF" filed return paket point to anything basic that I've overlooked?

rgds,

Gary

[CzechThunder]

Mark's suggestion turned out to be the correct fix.

The bare metal stack has a demo project for the Kinetis tower boards.  I ported the code from this sample.  This project has hardware specific startup that includes the code to unlock flash memory for USBHS access.  I didn't include this portion because I have unique hardware and the majority of the sample startup code would not be applicable.  But you need this bit because the usb controller needs to access flash memory.  The device descriptor is defined as CONST and gets placed in flash memory.  Another workaround would be to simply move the descriptor into RAM but it's safer to have in flash as it should be a fixed byte structure in most applications.

Thanks again Mark for saving me tearing out the rest of my hair over this.

Gary

[mjbcswitzerland · Accepted solution]

Hi

Make sure that the K20 is allowed to read from Flash - it may be trying to respond with a fixed message located in Flash and this causes it to send all 0x00 or possibly all 0xff instead.

To enable this:

FMC_PFAPR |= FMC_FPAPR_USB_HS; // allow USBHS controller to read from Flash

where

#define FMC_FPAPR_USB_HS FMC_PFAPR_M6AP_RD

and

#define FMC_PFAPR_M6AP_RD 0x00001000 // master 6 - read access rights

for the K20F part.

Regards

Mark

[CzechThunder]

Thank you so much Mark!  I will try this and let you know.  By the way, we are extremely happy with your HS Flash drive bootloader.  Has been working wonderfully for our product.

Gary