USB CDC link lost on MK22FN and PC

[shuichiy]

Hi all,

I have a project based on USB CDC Vcom Lite sample.

The project is developed on KSDK2.4.1 and the mcu is MK22FN128VLH10.

In addition to CDC, 2ch ADCs  and a PIT timer work together.

Snippet is as follows:

void PIT0_IRQHandler(void)
{

  if  (PIT_GetStatusFlags(PIT, kPIT_Chnl_0) != 0)  {
    PIT_StopTimer(PIT, kPIT_Chnl_0);
    PIT_ClearStatusFlags(PIT, kPIT_Chnl_0, PIT_TFLG_TIF_MASK);
     ADC16_SetChannelConfig(ADC0, 0, &adc16ChannelConfigStruct0);
     ADC16_SetChannelConfig(ADC1, 0, &adc16ChannelConfigStruct1);
  }

}

void ADC0_IRQHandler(void)

{
  ADCData0 = ADC16_GetChannelConversionValue(ADC0, 0);     
}

void ADC1_IRQHandler(void)
{
  ADCData1 = ADC16_GetChannelConversionValue(ADC1, 0);     
  PIT_StartTimer(PIT, kPIT_Chnl_0);
}

Symptoms:

The period of PIT timer is 20us or more, it works fine.

The period is less than 20us, Windows  loses the link of USB.

II think PIT or ADC interrupts effect on something USB features.

Does someone know the restriction of USB interface or workaround of this ?

[mjbcswitzerland]

Hi

I think that your interrupt routines are taking up all of the CPU power and so stopping normal operation. Since the USB controller handles most of the USB activity in HW there shouldn't be a great dependency of general response times.

Attached are two binary file that I just created as reference:
- one for FRDM-K22F running at 120MHz
- the second for FRDM-KL27Z running at 48MHz

Both have USB-CDC with a command line interface and a PIT interrupt running at a rate of a few us, but only flashing an LED in its interrupt handler

The K22 has a 2us PIT interrupt rate, which doesn't have any noticeable influence on the USB-CDC behavior
The KL27 has a 5us PIT interrupt and again no noticeable influence on USB

However, if I increase the K22 PIT interrupt frequency to 1us period the emumeration becomes unreliable - same for 4us on KL27. Even faster PITs stop all operation.

Of course if the PIT interrupt (and others) do more work the limit gets more critical.

Hence my conclusion that you are probably hitting this limit due to your longer interrupt routine code at this rate and you have the following possibilities:
1. Optimise interrupt handler code to reduce its overhead - if you directly access registers rather than passing through HAL calls you may get them down by 2..5x
2. Consider interrupt priorities and allowing higher priority interrupts to pre-empt lower priority ones - this may help in some system designs but won't help overall if 1 is already the limit.
3. Consider using DMA to do the work that is in the interrupts since the K22 DMA should allow you to sample multiple ADCs to a buffer without needing interrupts and thus hardly loading the CPU.

Obviously 3. is the only really wise way to go for serious product development.

As reference: https://www.youtube.com/watch?v=n-GABeILGV8&feature=youtu.be
This is a K22. It can do 400kHz sampling and process 8000 point FFT at the same time with around 60% of a K22's CPU power (including USB) so your limit of 50kHz for the ADC handling is not a hard system limit but a design limit.

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html
Kinetis K22:
- http://www.utasker.com/kinetis/FRDM-K22F.html
- http://www.utasker.com/kinetis/TWR-K22F120M.html
- http://www.utasker.com/kinetis/BLAZE_K22.html
- http://www.utasker.com/kinetis/tinyK22.html

For less questions and restrictions, and faster, cheaper developments: try uTasker for Kinetis