Kinetis K20 USB device descriptor returns nulls

[leccy]

We have incorporated the Processor Expert K20 tower example project USB_MS_Device into our project.

With our device running, connecting a USB cable causes what appear to be correct resets/suspensions (viewed on Ellysis USB explorer).

Host PC asks for device descriptor - our reply is correctly formed and can be followed on debug to USB_LDD_DeviceQueueDataPacket() in USB_LDD.c with what appears to be the correct data in the buffer to be sent (the first byte can be seen in debug as 0x12).

The USB analyzer shows the reply payload to be all nulls, and the PC shows 'USB device not recognized'.

We can run the K60 tower example project without problems.

Our USB D+ and D- lines are attached directly to the K20 via 30ohm resistors as per K60 tower.

Processor Expert components were copied from the example project to our project.

K20 component bus timings were altered to accommodate our 4MHz external crystal, USB clock setting shows 48MHz.

Does anyone have any ideas why we might see nulls as the payload data?

Thanks

Alex

[mjbcswitzerland]

Alex

Is the descriptor that you want to transfer located in RAM or in Flash?

If it is in Flash and you use a Rev. 2 K20 part (eg. 120MHz part) you will need to ensure that the USB controller has rights to access it (otherwise it will send 'rubbish').

If this is the case you need to set

MPU_CESR = 0;

// allow concurrent access to MPU controller

Regards

Mark

[leccy]

Thanks for your reply Mark.

MPU_CESR is set to 0 on start-up.

On debugger, it does seem that the data is ready to be sent, pointers in routine USB_LDD_DeviceQueueDataPacket() do appear to be set to correct data.

Data is sent by the routine and can be seen on the USB sniffer as a packet, except that it is all zeros!

Regards

Alex

[mjbcswitzerland]

Alex

You didn't say whether the data pointer was to a buffer in RAM or Flash. With the MPU_CESR set to 0 it shouldn't make any difference though.

I have used the USB device mode successfully on all Kl and K processor types (with USB) without any differences in the driver code (apart from the clock register setting) so don't have any other explanation at the moment.

Also it is not clear which K20 you are using. If it is a 50MHz, 72MHz,100MHz or 120MHz version? What core clock rate do you have? If you are deriving the USB clock from it, are you sure that the 48MHz accuracy is ensured?

I have a number of USB-MSD images here: http://www.utasker.com/SW_Demos.html#K70

which can be used to verify that the HW is OK - in case you find one there matching your board.

Regards

Mark

[leccy]

Mark

The descriptors are in flash, should have mentioned this.

We are using MK20DN512ZVLQ10, 100MHz.

Using external 4MHz resonator to generate a core clock of 48MHz (i have basically tried to copy the settings from the USB_MS_Device project).

We are going to look at the accuracy of the 48MHz today.

Again, many thanks for your suggestions.

Regards

Alex

[mjbcswitzerland · Accepted solution]

Alex

I still suspect that the USB controller is not being allowed to access the Flash since I don't expect small deviations in the clocks to cause such an effect.

To exclude this, I would copy the data (in the single test case) from Flash to a RAM buffer and then see whether this transaction is correct. Depending on the result you will know where to investigate more closely.

Regards

Mark

[leccy]

Mark

You are spot-on.  Moved the Device Descriptor to RAM, and all Device Descriptor requests reply with good data, all other requests still return nulls.

Can you suggest where else to look to configure the USB controller to access FLASH?

Many thanks for your help!

Alex

[leccy]

Looking at another post, it is possible to enable flash access for the USB by setting M4AP bits in the FMC_PFAPR register.

Our device now enumerates correctly with USB descriptors in flash.

Complicated little beastie...

[mjbcswitzerland]

Alex

I have to appologise since I oversaw this detail when I originally responded, although it is indeed needed (as well) for flash access.

You will however see, in case you do this on different processor types, that the bus master number is not always 4. In case you use a type with FPU it is then 3, if you use a K20-50M type it is also 3, and if you use HS USB on a K61/70 it will be bus master 6.
In the case of KL devices there is no FMC, so it then shouldn't be done...their USB controllers can always access Flash...

Regards

Mark