FRDM-K64K host_msd_fatfs USB not detecting device

[neilporven]

Hi everyone,

I am using the demo app host_msd_fatfs_frdmk64f to write my USB driver.  After much headaches

troubleshooting, etc... I got the project to do a usb_host_init and usb_host_register_driver_info.

I also have it running, but unfortunately when I insert a USB stick the code seems not to detect it.

I keep getting case USB_DEVICE_IDLE and the g_mass_device[i].state_change = 0.  I believe that 

it could be an issue with the interrupt of the USB.  I would like to know where does the demo software

setup the interrupt settings for the USB (USBx_INTEN).

Also, if I run the project through the P&E multilink + Kinetis KDS on the FRDM-K64F evaluation board and

I place a breakpoint inside USB_DEVICE_ATTACHED where the demo project is called from and I stick a USB

stick the software never transitions from  USB_DEVICE_IDLE?  Another interesting thing, if I place a USB device

that detects if power is present on the J22 connector (K64 USB), it shows no power on the device. I have J21

jumped and R72 with a zero OHM shorted, just in case someone is wondering.  I am powering the board through

the J27 connector.

Thank you,

Neil

[neilporven · Accepted solution]

Hi Daniel,

I found why my custom board was not detecting the attachment of the USB stick.  Apparently, the following two lines of code are needed:

OS_Task_create(USB_task, NULL, 4L, 4000L, "task_start", NULL);
OSA_Start();

I don't understand what the above lines of code do?

I did find that after the call from OSA_Start(), it never returns back.  I do see that it is locked inside the APP_task() performing the different cases, which is great for the detection to occur, but at some point I need for it to get out so that I can service other routines in my application.  Can you exlplain what the above two lines of code do and how can I make OSA_Start() return?

Thanks,

Neil

[neilporven]

Hi Daniel,

As far as the usb device itself being recognized, I don't think its an issue.  I have 3 USB sticks and the demo board recognizes

each.  I use the same for my custom board.

Today, I am running the two boards simultaneously to see where one differs from the other.  I know that the demo board uses a 50MHz signal

that is fed from the Ethernet PHY chip, where my board has a 16MHz crystal for the USB external clock.  I also read that there is a code sequence

that must be followed in order to prevent enumeration failures (I don't know if this has anything to do with the actual issue).  I am hoping to find a 

difference in the Embsys Registers when the APP_init() function finishes.  I can then focus at least on something relating to configuration of the USB module itself or the clock settings.

Can you please let me know if you find out who(function, where can I see it, etc..) triggers the attachment.  I know that there has to be a function

which looks at ISTAT[ATTACH] and triggers once it is seen.

Thanks,

Neil

[danielchen]

Hi Neil:

It doesn't matter , take care!

I cut J8 and J12 , according to user manual. see below picture.

I use the NXP released demo, not change anything. 

Regards

Daniel

[neilporven]

Hi Daniel,

I haven't heard back from you on the issue of the FRDM-K64F board not communicating with the terminal program.

I was looking at your picture that shows the FRDM-K64F board and noticed that you don't have the MICRO USB OTG

cable connected with a USB stick.  How is this demo working for you without it?   Notice my setup, it has the MICRO

USB OTG cable installed in J22 connector (K64USB).

Regards,

Neil

[danielchen]

I connected with a USB stick through J22(K64USB) while testing.

[neilporven]

Hi Daniel,

First, thank you for your help.  Unfortunately, I am not getting the same results.  Here is my setup

This is the back of my board/w cut traces.  I placed a jumper on J11 and J12, so that I can always

go back if I need to.

I am using the host_msd_fatfs_bm_frdmk64f demo from NXP, nothing changed.  I am using

RealTerm to capture the data.  RealTerm is configured as 115200, no parity, 8 data bits, 1 Stop,

and no hardware flow.

Today, I am going to see if the original dropping the binary file using the OPENSDA still works, but

if it does, then I don't know why using the P&E should be any different?

Thanks,

Neil