MK66FN2M0VMD18 Custom Board Vcom Issues

[jmuller1]

I have been developing a custom board with an integrated MK66FN2M0VMD18 chip. I have been trying to send data over the boards USB port, and while doing so I came across the K66 FRDM boards dev_cdc_vcom demo. This essential what I need but the demo sends the data over UART pins into its K20 daughter board before sending it over USB. All the USB examples do this, but because of the custom board this is an issue. I want to just be able to send this data over the DP and DM pins directly, as this is how my board is configured. Is there an easy way around this, or am I stuck making drivers from scratch. 

[myke_predko]

Hi Jake,

What you posted looks like the standard bare metal USB CDC Device example for the Kinetis devices (As I've been learning about the SDK I've actually worked with the code on the K64 and K22 Freedom boards as well as our custom product hardware (MK20 and MK22). It works fine on all of these platforms but I wouldn't say that it's easily understandable or portable to another application.  

What do you mean "sends the data over UART pins into its K20 daughter board before sending it over USB"?  The K66 has it's own USB port(s) and that is what the code is accessing along with it's own DP/DM pins - you should be able to load the code into your custom K66 board and be off to the races...

...with the only issue being clocking.  Make sure that you have the appropriate clocking going into the USB module.  

Just looking at the FRDM-K64F Schematics - J22 is the USB port that is connected directly to the MK66 and this is the port the demo code will run with.  The other USB port (J26) does pass through the OpenSDA programmer MCU (the MK20) but this is for programming/debug and is not USB port you will be communicating with.  When you run the demo, you will have one USB cable from your development system to J26 and J22 will provide you with a USB CDC device interface.  

Does that help?

myke

[jmuller1]

Thanks Myke,

This is a big help, but you'll have to forgive me for my lack of knowledge, I'm still a novice with some of this and still trying to wrap my head around some of this. This narrows down my problem though. When running the demo file I have been enabling USB FS clock and routing the USB0_Clk pins, but the USB0 peripheral is disabled by default and enabling it fills the whole project with errors so I have been avoiding that. Now, when debugging it never displays the VCOM ports within device manager. I figured this was due to the FRDM boards built in drivers which allow it to appear in device manager and interacted with via Putty/TeraTerm. But if you think I should be "off to the races" this has me skeptical. So my current plans of action are to look into USB peripheral settings to see if that is where my problem arises, or to see if I require windows drivers that help the device enumerate a VCOM port. 

If you have any input that would be great,

If you know of a more efficient and easy way to send data over USB that would be great too.

Thanks, 

Jake

[myke_predko]

Hi Jake,

No worries, we've all been where you are.  

Reading what you're writing here, I think you're putting too much work into getting the demo running.  You should NOT be changing clocks or anything else - just build the demo code and load/run it in the FRDM-K66 and plug your PC into the second USB port and things should be fine with Tera Term (what I use with Windows machines) or Putty (LInux and Macs).  

If you have been changing the .mex file settings then I recommend that you delete the project from MCUXpresso, reload it and try it as is.  For running the demo on a Windows 7 machine, you will require installing the NXP/FSL CDC .inf driver file.  If you're running Windows 10, you shouldn't have any issues.  

I'm using a modified version of the FreeRTOS demo code in my product but I had a lot of struggles understanding how to get the clocking right (for a few months I simply copied the demo clock_config.c/.h files into my project because I couldn't get things working and then I spent a few *days* working with the Reference Manual and Clock Wizard to figure out what I needed to do).  Clocking really isn't explained very well in any of the documentation I could find and, even in the end, getting the USB clocking right involved a lot of clicking on controls in the clock wizard because things didn't seem to be linearly linked together.  

Just build and load the demo as is and you should see everything working.  Once you have it working, the operation of virtual_com.c will become clearer.  

myke

[jmuller1]

Hi Myke,

When I have been running the base file I would get no response, with no signal through the . Although after looking over the schematic of both my custom board and the K66 FRDM board, it looks like that the FRDM board is only wired to USB1 DP/DM connections leaving USB0 unwired. My custom board is only connected to USB0 in contrast. So from where I'm at now It looks like I have to find the code that determines which USB is being used to the VCOM enumeration. If you have any idea how to do this that would be great, otherwise you have been a great help.

Thanks Again,

Jake

[myke_predko]

Hi Jake,

Sorry, I should have looked deeper into the FRDM-K66F schematic.  I naturally assumed the connector was attached to USB0 because that's what all the Freedom and Tower boards are connected to (but they all have one USB port).  

I'm not sure how you determine which USB is being enumerated out of the two unless you have initialized each of them.  From my understanding of how USB works (which may be wrong), before any kind of enumaration takes place, the USB controller must be initialized.  

Now, have you tried selecting a different USB port for the demo app?  If I look at "virtual_com.h", line 15, the "CONTROLLER_ID" is #defined as "kUSB_ControllerEhci0" - could you try changing it to "kUSB_ControllerEhci1" for the Freedom Board?  CONTROLLER_ID is used in "AppInit" (in "virtual_com.c") when it calls "USB_DeviceClassInit" and this is the only location where the port number seems to be spectified.  

"kUSB_ControllerEhci0" is defined in "usb/includes/usb.h" and has this message:

/*!< EHCI 1U, Currently, there are no platforms which have two EHCI IPs, this is reserved
to be used in the future. */

As this file is dated 2015 and it is the identical one that I have for the FRDM-K22F then I would try to give this a shot thinking that the contents are accurate but the comments are out of date/inappropriate for the MK66.  

Now, when you are testing this, what are you plugging your Freedom board in to communicate with it?  Could I suggest that you use a Windows machine that has a chime when a new USB connection is good (or when it's bad)?  If the USB Port is not set up at all, you won't get any kind of sound, if it is set up but not working properly (I found that clocking was the biggest issue here) you will get what I call the "clunk" sound - which is good as you're actually starting to move forwards.  

Good luck - again apologies that I didn't read througth FRDM-K66F schematics as carefully as I should have.

myke