I managed to get the PLL up and running with external crystal, generating PLLclk = 48Mhz, which is feed to USB through MCGPLLCLK ( PLLFLLSEL = 1).
Core runs at 48Mhz, bus, flash and flexbus runs at 24Mhz.
I have verified the frequencies on PTC3.
When I connect the USB cable the software makes transition som BLPE/VLPR -> RUN/PEE, after this is verified and done the USB starts up. But for some reason the computer will not recognize the device. If I plug into a win7 computer it said that it "failed to get device description".
But if I break the software I can see that I do get a token from the computer with device descriptor request and it the protocol stack ( Freescale 4.1.1 ) breaks at the usb_descriptor.c file where it does get the descriptor, the protocol stack flags no errors.
Btw, I also tried running of IRC48, with same result.
Any idea why the computer won't recognize it ?
Hi! I've found about 6 different ways to break enumeration with the FSL USB stack 4.1.1 on the MK22FN1M0VLH12 lately. I'll see if I can remember some of them.
#1 was having the MPU in its default configuration. This prevents the USB controller from accessing the BDT. As a result, it doesn't know that the control endpoint is enabled and will never generate an ACK for the setup transaction. Make sure you have the MPU set up to allow the controller access to RAM.
I think #2 was a crossbar switch setting.
#3 was caused by my bringing the Kinetis and Coldfire versions of the project into closer sync and in the processes getting the big-endian flag in the SOPT2 register wrong on the Coldfire version.
I'll post others if I think of them, but check the memory protection unit and crossbar switch settings first.
Within the USB DCI you can set a breakpoint where it receives SOF packets. If you're getting SOF packets and the frame numbers match what you're seeing on the hardware protocol analyzer, the SIE is working properly and it's most likely a problem with access to the buffer descriptors.
Scott
#4 was switching from the Processor Expert version of the stack (which doesn't support delayed processing) to the full version and not getting the USB clock initialization right.
#5 was trying to access a USB register before the peripheral clock gate was enabled.
Here's my init now, for a 120 MHz PLL (taken from the PE init):
void usb_init(void)
{
SIM_SOPT2 |= SIM_SOPT2_USBSRC_MASK; /* Divided PllFll clock */
SIM_CLKDIV2 = (uint32_t)((SIM_CLKDIV2 & (uint32_t)~(uint32_t)(
SIM_CLKDIV2_USBDIV(0x03)
)) | (uint32_t)(
SIM_CLKDIV2_USBDIV(0x04) |
SIM_CLKDIV2_USBFRAC_MASK
)); /* Div=5 - Mult=2 */
/* Enable module clock */
/* SIM_SCGC4: USBOTG=1 */
SIM_SCGC4 |= SIM_SCGC4_USBOTG_MASK;
/* Reset module */
/* USB0_USBTRC0: USBRESET=1 */
USB0_USBTRC0 = USB_USBTRC0_USBRESET_MASK; /* Reset module */
while (USB_PDD_GetModuleResetPendingFlag(USB0_BASE_PTR)) {
; /* Wait for reset done */
}
/* Enable USB voltage regulator */
/* SIM_SOPT1: ??=1 */
SIM_SOPT1 |= 0x80U; /* Enable USB voltage regulator */
/* USB0_USBTRC0: ??=1 */
USB0_USBTRC0 = 0x40U; /* Enable internal pull-up */
/* USB0_USBCTRL: SUSP=1 */
USB0_USBCTRL = (USB_USBCTRL_SUSP_MASK | USB_USBCTRL_PDE_MASK); /* Disable weak pull-downs and suspend transceiver */
/* USB0_OTGCTL: DPHIGH=0,??=0,DPLOW=0,DMLOW=0,??=0,OTGEN=1,??=0,??=0 */
USB0_OTGCTL = USB_OTGCTL_OTGEN_MASK;
// BDTPAGE set in DCI
}
And from the PE CPU init, here's the MPU and AXBS setup:
/* SIM_SCGC7: MPU=1 */
SIM_SCGC7 |= SIM_SCGC7_MPU_MASK;
/* Initialization of the MPU module */
/* MPU_CESR: SPERR=0,VLD=0 */
MPU_CESR &= (uint32_t)~(uint32_t)((MPU_CESR_SPERR(0x1F) | MPU_CESR_VLD_MASK));
/* Initialization of the AXBS module */
/* AXBS_PRS0: ??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,M5=4,??=0,M4=3,??=0,??=0,??=0,??=0,??=0,M2=2,??=0,M1=1,??=0,M0=0 */
AXBS_PRS0 = AXBS_PRS_M5(0x04) |
AXBS_PRS_M4(0x03) |
AXBS_PRS_M2(0x02) |
AXBS_PRS_M1(0x01) |
AXBS_PRS_M0(0x00);
/* AXBS_PRS1: ??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,M5=4,??=0,M4=3,??=0,??=0,??=0,??=0,??=0,M2=2,??=0,M1=1,??=0,M0=0 */
AXBS_PRS1 = AXBS_PRS_M5(0x04) |
AXBS_PRS_M4(0x03) |
AXBS_PRS_M2(0x02) |
AXBS_PRS_M1(0x01) |
AXBS_PRS_M0(0x00);
/* AXBS_PRS2: ??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,M5=4,??=0,M4=3,??=0,??=0,??=0,??=0,??=0,M2=2,??=0,M1=1,??=0,M0=0 */
AXBS_PRS2 = AXBS_PRS_M5(0x04) |
AXBS_PRS_M4(0x03) |
AXBS_PRS_M2(0x02) |
AXBS_PRS_M1(0x01) |
AXBS_PRS_M0(0x00);
/* AXBS_PRS3: ??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,M5=4,??=0,M4=3,??=0,??=0,??=0,??=0,??=0,M2=2,??=0,M1=1,??=0,M0=0 */
AXBS_PRS3 = AXBS_PRS_M5(0x04) |
AXBS_PRS_M4(0x03) |
AXBS_PRS_M2(0x02) |
AXBS_PRS_M1(0x01) |
AXBS_PRS_M0(0x00);
/* AXBS_PRS4: ??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,M5=4,??=0,M4=3,??=0,??=0,??=0,??=0,??=0,M2=2,??=0,M1=1,??=0,M0=0 */
AXBS_PRS4 = AXBS_PRS_M5(0x04) |
AXBS_PRS_M4(0x03) |
AXBS_PRS_M2(0x02) |
AXBS_PRS_M1(0x01) |
AXBS_PRS_M0(0x00);
/* AXBS_CRS0: RO=0,HLP=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,ARB=0,??=0,??=0,PCTL=0,??=0,PARK=0 */
AXBS_CRS0 = (AXBS_CRS_ARB(0x00) | AXBS_CRS_PCTL(0x00) | AXBS_CRS_PARK(0x00));
/* AXBS_CRS1: RO=0,HLP=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,ARB=0,??=0,??=0,PCTL=0,??=0,PARK=0 */
AXBS_CRS1 = (AXBS_CRS_ARB(0x00) | AXBS_CRS_PCTL(0x00) | AXBS_CRS_PARK(0x00));
/* AXBS_CRS2: RO=0,HLP=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,ARB=0,??=0,??=0,PCTL=0,??=0,PARK=0 */
AXBS_CRS2 = (AXBS_CRS_ARB(0x00) | AXBS_CRS_PCTL(0x00) | AXBS_CRS_PARK(0x00));
/* AXBS_CRS3: RO=0,HLP=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,ARB=0,??=0,??=0,PCTL=0,??=0,PARK=0 */
AXBS_CRS3 = (AXBS_CRS_ARB(0x00) | AXBS_CRS_PCTL(0x00) | AXBS_CRS_PARK(0x00));
/* AXBS_CRS4: RO=0,HLP=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,ARB=0,??=0,??=0,PCTL=0,??=0,PARK=0 */
AXBS_CRS4 = (AXBS_CRS_ARB(0x00) | AXBS_CRS_PCTL(0x00) | AXBS_CRS_PARK(0x00));
/* AXBS_MGPCR0: ??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,AULB=0 */
AXBS_MGPCR0 = AXBS_MGPCR0_AULB(0x00);
/* AXBS_MGPCR1: ??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,AULB=0 */
AXBS_MGPCR1 = AXBS_MGPCR1_AULB(0x00);
/* AXBS_MGPCR2: ??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,AULB=0 */
AXBS_MGPCR2 = AXBS_MGPCR2_AULB(0x00);
/* AXBS_MGPCR4: ??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,??=0,AULB=0 */
AXBS_MGPCR4 = AXBS_MGPCR4_AULB(0x00);
Hi,
I'm also looking forward to you share the analysis result of the USB analyzer.
And I'd like to know which kind of the MCU you use.
Have a great day,
Ping
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Default the Flash access was not enabled for USB ( Master 4 ), so I tried to enable read/write access and prefetching for master 4. Made no difference.
Next tried the USB analyzer ( USBLyzer ), when connecting the device it shows up here the same way as it does in windows ( missing device descriptor ). It also comes up with a warning that the driver has reported something wrong ( error code 43 ). Now this error-code is something that familiar, and normally has something to do with windows / drivers.
Is there somewhere where I can download the appropriate drivers to use ? Right now I'm using the .inf file that came with the stack, should I use another one ?
Never imagined that getting the USB to work would be this difficult :smileyhappy:
Btw. using MK22FN512VLL12
Hi,
The USB stack 4.1.1 doesn't provide the corresponding demo for the K22_120, so I'd highly recommend you to download the KSDK 1.3 through the link as below.
The KSDK 1.3 contains the updated USB stack, and it also includes the USB demo for the K22_120 which reside in the ~\KSDK_1.3.0\examples\frdmk22f\demo_apps\usb.
Software Development Kit for Kinetis MCUs|NXP
Have a great day,
Ping
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
The demo I found that works with the MK22FN1M0VLH12 as in CodeWarrior 10.6's examples folder, under Processor_Expert/Kinetis/TWR-K21F120M/USB_MSD_Device. That assumes, of course, that you're running CW 10. It was that example that helped me find my MPU problem.
Not using KDS, using Crossworks Compiler. Reason is that I like to Write most of the code myself to have total Control, not having some scripts build code for me :smileyhappy: old habits die hard:)
But thanks for the enumeration breakdown and the sample code I will give this a try!
Found it difficult debug this in the original code so made a New Project With just the USB now, should make it debug and try stuff since the USB was only 5% off the code originally, lots of other stuff happening that might cause issues I Guess.
I'll update thread once I've tried it
The 512vll12 does not have a MPU so no settings needed here. Adjusted the FMC register to allow the USB read access to flash.
Testet the new software on the FRDM and finally it worked, ran the USB and core of the IRC48M. When testing the same code on my hardware, it failed enumeration. Leads me to beleive that there might be a hardware issue on my PCB causing the issue, not sure exactly what but :smileyhappy:
Since both my hardware and the FRDM runs nearly the same cpu ( same reference manual, 512vhl12 VS 512vll12 ) there shoudn't be any compability issues here.
Found one strange thing on my hardware, the VOUT33 ( output from regulator ), is above 5V, with a ripple of 500mV. Measuring the same output on the FRDM it measures stable 3v3.
I do not use the regulator output, so I've connected this through a 2.2uF capacitor to gnd.
So the search continues :smileyhappy:
Huh, I knew the MK22FN512 and MK22FN1M had some differences but I didn't know the 512 was missing the MPU. I guess that's what happens when you let the marketing department determine your part numbers instead of engineering.
What's VREGIN look like? I neglected to connect a decoupling capacitor on VOUT33 on my board initially but it still worked. I'd check all of your USB connections carefully. D+ should be 3.3v and D- should be 0 when it's configured and ready to be detected. When you connect to the host, the host should assert a SE0 (both lines low) for 10 msec and the USB controller should generate a bus reset interrupt. In my experience Windows 8 at least will give a beep like it successfully connected even if it doesn't get any further than speed detection.
Try setting a breakpoint around line 1830 in usb_dci_kinetis.c, in the "SOF Token Received" section. sof_count is loaded from the frame number register and you should see it increment every millisecond. This should work even if something's wrong with DMA or your buffer descriptor table, and will tell you that the transceiver is functioning. Or that the receiver side is at least, I suppose.
The 5v+ reading would worry me and I'd probably focus on that first. Where does VBUS from the USB connector go? Is it being used? Any chance you're getting injection current on another I/O pin from a 5v source?
Scott
Found the regulator error, I had the wrong capacitor value on the regulator output, so changed this one and the regulator regulated correctly. Luckily I did not use it, dangerous regulator that changes from 3v3 to 5.5V output when wrong capacitor is applied... But anyways regulator now output 3v3.
I already testet the SOF packet, and it is received and decoded by the stack, followed the stack all the way through the decoding, fetching device descriptors and returning them, but still error on the computer, "cannot recognize the device".
To eliminate more hardware issues, I made another PCB with just the cpu and the parts required for USB. And on this it worked, when connecting computer recognizes as CDC device and installs appropriate drivers.
So my guess is that the software is now finally OK and that it was giving the USB access to flash that was missing, and that the problems are in hardware.
So the search continues, start removing one component at a time to see what does the trick, and then try finding out why :smileyhappy: I'll update the thread when I find the solution
Hi
For emumeration problems you will need a HW USB anaylser. If the enumeration is not good, no *.inf files will be involved yet.
Does the SW run on a reference board - enumerate successfuly?
If your board is compatible with either of the following, try running reference binaries:
http://www.utasker.com/kinetis/FRDM-K22F.html
http://www.utasker.com/kinetis/TWR-K22F120M.html
Regards
Mark
Okey, if problem does not go away I have to get a HW analyzer and see if that gives me any more information. Did not know the thing about .inf, so thanks for the info, nice to know!
I've tried the same on the FRDM.22F with the same result..
Downloaded the uTaskerSerialBoot and loaded this to FRDM-K22F and this worked just fine, plugged in the USB cable and everything loaded just fine.
Unfortenately I guess this means there is a software issue on my side causing the problems, and not windows/driver issues.. but what the problem is is still a very good question :smileyhappy:
Are there any USB stacks by Freescale that are "device aware" and handles the Mk22FN512VLL12 that will handle all the hardware setup ?
Hi
If you build your project so that it should operate on the FRDM-K22F board I can load it to mine (attach the binary to the thread) and tell you what the problem is. It may still be the crossbar switch settings in case you made a mistake setting it up, which will be visible immediately with my HW anayser.
Don't forget that the uTasker USB stack is HW independent and runs on all K, KL, Coldfires - it also allows you to simulate USB, the board and your project in case you would like to accelerate project developments and achieve more optimum performance.
Regards
Mark
I will try go get the software compatible with the FDRM-K22F board and attach the binaries, there is some work to get it compatible, so probabaly won't be ready today.
What kind of crossbar switch settings are necessary ? I thought no configuration of this was required ?
>>What kind of crossbar switch settings are necessary ? I thought no configuration of this was required ?
Setting the crossbar master's access rights, as you have aready tried.
Regards
Mark
Hi
Attached is a K22 serial USB-MSD loader version that uses exclusively the IRC48M for processor and USB control. This means that it should run on any HW with the 512k Flash/128k RAM chip part (no external clock speed dependencies) and allow you to check that your own HW is OK.
Regards
Mark
Ah the settings were in the FMC registers so was fixed on flash controller, not crossbar switch :smileyhappy:
Where is the file ? I cannot see it ?
Hi
You should see the file attached in the post as long as you are logged in - if you don't you may be using an incompatible browser or have some other problem.
You can also download it from http://www.uTasker.com/temp/uTaskerSerialBoot_FRDM-K22-USB-MSD-48M.bin
I set up for the 48MHz clock for everything:
Regards
Mark
This is kinda a longshot, but I just tried to get the default USB project working in KDS with a FRDM-KL27z board, however (without changing anything) it would give "failed to get device description". If I paused the processor, it had entered the default ISR handler (infinite loop) when trying to lock a mutex used for USB. I later found out that, by default, the KDS project has 0 heap space allocated, so the initial creation of the mutex would fail because it couldn't allocate any space for it. So your problem may be related to mutex locking/unlocking if it fails at the same point.
Also are you using USB Stack|NXP ? It says it's been discontinued, but its probably the exact same thing as is bundled with KSDK anyway.