You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by nu...@charnell.plus.com on 2021/02/14 09:37:31 UTC
USB on Kinetis k64f
Hello,
I would like to setup a Kinetis k64f as a USB host to communicate with a
USB serial device. As there is not a configuration for USB host with the
k64f I thought I would start by configuring the k64f as a USB device,
but have not been able to produce a working (visible USB device on K64
USB interface) setup yet.
I wonder if anyone has used the USB interface on the Kinetis k64f, or
the Kinetis k28, or might have some tips on how to debug?
The k64f has two modes of USB clocking, derived from PLL clock or IRC48
clock sync'd to incoming USB data. I started by using clocking derived
from PLL.
I have modified a number of source files based on the Kinetis k28, which
has a configuration for usbnsh:
nuttx/boards/arm/kinetis/freedom-k64f/include/board.h based on
freedom-k28 board.h. Modified to set MCG Frequency (PLLOUT) to 96 MHz
and included settings for USB clocks.
nuttx/boards/arm/kinetis/freedom-k64f/src/k64_usbdev.c. Added DP Pullup
in non-OTG device mode, based on k28_usbdev.c, and k64_usbinitialize
routine. Pull-up functioning (measured with multimeter).
nuttx/boards/arm/kinetis/freedom-k64f/src/k64_bringup.c - Added call to
k64_usbinitialize & CONFIG_PL2303
nsh is working over SDA USB interface (the Kinetis k64f board
programming and debug interface, via a K20DX device, separate from the
K64 USB interface connected directly to the k64f device). I also have
Ethernet (nsh via telnet) functioning.
I have built the PL2303 & CDCACM apps, neither produce a usb device
visible from Linux laptop
Output of dmesg (PL2303 app with some USB debug enabled)
nsh> dmesg
__start: Reset status: 00:00
khci_hwinitialize: BDT Address 0
khci_hwinitialize: BDTPAGE3 1f
khci_hwinitialize: BDTPAGE2 ff
khci_hwinitialize: BDTPAGE1 46
Mounting procfs to /proc
Successfully bound SDHC to the MMC/SD driver
kinetis_usbsuspend: resume: 1
Output of journalctl on linux PC connected via USB hub to K64 USB interface
Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: new full-speed
USB device number 124 using xhci_hcd
Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: device
descriptor read/64, error -32
Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: device
descriptor read/64, error -32
Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: new full-speed
USB device number 125 using xhci_hcd
Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: device
descriptor read/64, error -32
Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: device
descriptor read/64, error -32
Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2-port4: attempt
power cycle
Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: new full-speed
USB device number 126 using xhci_hcd
Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
responding to setup address.
Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
responding to setup address.
Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: device not
accepting address 126, error -71
Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: new full-speed
USB device number 127 using xhci_hcd
Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
responding to setup address.
Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
responding to setup address.
Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: device not
accepting address 127, error -71
Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2-port4: unable to
enumerate USB device
Kind regards
Stewart Charnell
Re: USB on Kinetis k64f - FRDM-K64F board
Posted by nu...@charnell.plus.com.
Hi Brennan,
I can confirm your changes have worked for me on my Kinetis FRDM-K64F
board, thanks again for working on this.
Kind regards
Stewart Charnell
On 15/02/2021 08:05, nuttx@charnell.plus.com wrote:
> Hi Brennan,
>
> Thanks you for fixing this for me, I will pull your changes and try
> this out this week.
>
> I had spotted the changes needed to the freedom-k64f board.h file (but
> had missed that the 48 MHz USB clock could be generated from the
> standard 120 MHz PLL frequency, I had changed the PLL frequency to 96
> MHz).
>
> I had thought that additional code was needed in the kinetis_usbpullup
> routine of k64_usbdev.c to call khci_putreg to enable the DPPULLUP
> (was in the fredom-k28 code) but will try your code changes.
>
> I have a Picoscope which may have code for decoding USB transactions.
>
> Kind regards
>
> Stewart Charnell
>
> On 15/02/2021 00:27, Brennan Ashton wrote:
>> Stewart,
>> I had been looking for an excuse to test NuttX on this chip, so I took
>> a look and added the missing support you can see it here:
>> https://github.com/apache/incubator-nuttx/pull/2847
>>
>> The main issue was the clock was not being configured correctly. The
>> k28 has a different default PLL frequency so needs different scalers
>> to get us the 48MHz clock.
>>
>> Personally when debugging USB I long ago invested in a USB analyzer
>> which helps, but they are not cheap, so NuttX does have some really
>> helpful built-in tracing functionality.
>> The easiest way to enable it is through these configuration settings.
>> Here I am using the nsh usbdev tracer, but you can also use the
>> monitor functionality to dump to syslog but you then have to
>> initialize the monitor thread as well.
>>
>> < CONFIG_DEBUG_ERROR=y
>> < CONFIG_DEBUG_FEATURES=y
>> < CONFIG_DEBUG_INFO=y
>> < CONFIG_DEBUG_USB=y
>> < CONFIG_DEBUG_USB_ERROR=y
>> < CONFIG_DEBUG_USB_WARN=y
>> < CONFIG_DEBUG_WARN=y
>>
>> < CONFIG_NSH_USBDEV_TRACE=y
>> < CONFIG_NSH_USBDEV_TRACECLASS=y
>> < CONFIG_NSH_USBDEV_TRACECONTROLLER=y
>> < CONFIG_NSH_USBDEV_TRACEINIT=y
>> < CONFIG_NSH_USBDEV_TRACEINTERRUPTS=y
>> < CONFIG_NSH_USBDEV_TRACETRANSFERS=y
>>
>> < CONFIG_SYSTEM_CDCACM=y
>> < CONFIG_SYSTEM_CDCACM_TRACECLASS=y
>> < CONFIG_SYSTEM_CDCACM_TRACECONTROLLER=y
>> < CONFIG_SYSTEM_CDCACM_TRACEINIT=y
>> < CONFIG_SYSTEM_CDCACM_TRACEINTERRUPTS=y
>> < CONFIG_SYSTEM_CDCACM_TRACETRANSFERS=y
>>
>> < CONFIG_USBDEV=y
>> < CONFIG_USBDEV_DUALSPEED=y
>> < CONFIG_USBDEV_TRACE=y
>> < CONFIG_USBDEV_TRACE_STRINGS=y
>>
>> With these enabled here is what you get when sending some data out the
>> CDCACM device:
>>
>> nsh> echo "foo" > /dev/ttyACM0
>> Interrupt entry 23: ENTRY 0008
>> Interrupt decode 21: KHCI_TRACEINTID_TRNC 0008
>> Interrupt decode 22: KHCI_TRACEINTID_TRNCS 0000
>> Interrupt decode 24: KHCI_TRACEINTID_NOSTDREQ 0021
>> Interrupt decode 3: KHCI_TRACEINTID_DISPATCH 0000
>> Class setup : Class SETUP request 0022
>> EP submit : Submit endpoint request 0000
>> EP 0 IN queued : Write request queued 0000
>> EP 0 IN write : Outgoing data written 0000
>> Interrupt decode 38: KHCI_TRACEINTID_EP0SETUPOUT 0080
>> Interrupt exit 23: EXIT 0008
>> Interrupt entry 23: ENTRY 0008
>> Interrupt decode 21: KHCI_TRACEINTID_TRNC 0008
>> Interrupt decode 22: KHCI_TRACEINTID_TRNCS 0028
>> Interrupt decode 11: KHCI_TRACEINTID_EPINDONE 0028
>> EP 2 Request complete: Request completed 0004
>>
>> Prior to the changes in my PR you would have seen the resets being set
>> over and over from the
>> host with no transactions ever starting. This was not super useful in
>> this case since the issue
>> was at the physical layer with the wrong clock being used.
>>
>> Hope this helps,
>> Brennan
>>
>>
>>
>>
>>
>> On Sun, Feb 14, 2021 at 11:16 AM <nu...@charnell.plus.com> wrote:
>>> Hello,
>>>
>>> Should have said this is the FRDM-K64F board, freedom-k64f
>>> configuration.
>>>
>>> Kind regards
>>>
>>> Stewart
>>>
>>> On 14/02/2021 09:37, nuttx@charnell.plus.com wrote:
>>>> Hello,
>>>>
>>>> I would like to setup a Kinetis k64f as a USB host to communicate with
>>>> a USB serial device. As there is not a configuration for USB host with
>>>> the k64f I thought I would start by configuring the k64f as a USB
>>>> device, but have not been able to produce a working (visible USB
>>>> device on K64 USB interface) setup yet.
>>>>
>>>> I wonder if anyone has used the USB interface on the Kinetis k64f, or
>>>> the Kinetis k28, or might have some tips on how to debug?
>>>>
>>>> The k64f has two modes of USB clocking, derived from PLL clock or
>>>> IRC48 clock sync'd to incoming USB data. I started by using clocking
>>>> derived from PLL.
>>>>
>>>> I have modified a number of source files based on the Kinetis k28,
>>>> which has a configuration for usbnsh:
>>>>
>>>> nuttx/boards/arm/kinetis/freedom-k64f/include/board.h based on
>>>> freedom-k28 board.h. Modified to set MCG Frequency (PLLOUT) to 96 MHz
>>>> and included settings for USB clocks.
>>>> nuttx/boards/arm/kinetis/freedom-k64f/src/k64_usbdev.c. Added DP
>>>> Pullup in non-OTG device mode, based on k28_usbdev.c, and
>>>> k64_usbinitialize routine. Pull-up functioning (measured with
>>>> multimeter).
>>>> nuttx/boards/arm/kinetis/freedom-k64f/src/k64_bringup.c - Added call
>>>> to k64_usbinitialize & CONFIG_PL2303
>>>>
>>>> nsh is working over SDA USB interface (the Kinetis k64f board
>>>> programming and debug interface, via a K20DX device, separate from the
>>>> K64 USB interface connected directly to the k64f device). I also have
>>>> Ethernet (nsh via telnet) functioning.
>>>>
>>>> I have built the PL2303 & CDCACM apps, neither produce a usb device
>>>> visible from Linux laptop
>>>>
>>>> Output of dmesg (PL2303 app with some USB debug enabled)
>>>> nsh> dmesg
>>>> __start: Reset status: 00:00
>>>> khci_hwinitialize: BDT Address 0
>>>> khci_hwinitialize: BDTPAGE3 1f
>>>> khci_hwinitialize: BDTPAGE2 ff
>>>> khci_hwinitialize: BDTPAGE1 46
>>>> Mounting procfs to /proc
>>>> Successfully bound SDHC to the MMC/SD driver
>>>> kinetis_usbsuspend: resume: 1
>>>>
>>>> Output of journalctl on linux PC connected via USB hub to K64 USB
>>>> interface
>>>>
>>>> Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: new
>>>> full-speed USB device number 124 using xhci_hcd
>>>> Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: device
>>>> descriptor read/64, error -32
>>>> Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: device
>>>> descriptor read/64, error -32
>>>> Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: new
>>>> full-speed USB device number 125 using xhci_hcd
>>>> Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: device
>>>> descriptor read/64, error -32
>>>> Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: device
>>>> descriptor read/64, error -32
>>>> Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2-port4: attempt
>>>> power cycle
>>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: new
>>>> full-speed USB device number 126 using xhci_hcd
>>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
>>>> responding to setup address.
>>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
>>>> responding to setup address.
>>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: device not
>>>> accepting address 126, error -71
>>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: new
>>>> full-speed USB device number 127 using xhci_hcd
>>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
>>>> responding to setup address.
>>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
>>>> responding to setup address.
>>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: device not
>>>> accepting address 127, error -71
>>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2-port4: unable to
>>>> enumerate USB device
>>>>
>>>>
>>>> Kind regards
>>>>
>>>> Stewart Charnell
>>>>
>>>>
Re: USB on Kinetis k64f - FRDM-K64F board
Posted by nu...@charnell.plus.com.
Hi Brennan,
Thanks you for fixing this for me, I will pull your changes and try this
out this week.
I had spotted the changes needed to the freedom-k64f board.h file (but
had missed that the 48 MHz USB clock could be generated from the
standard 120 MHz PLL frequency, I had changed the PLL frequency to 96 MHz).
I had thought that additional code was needed in the kinetis_usbpullup
routine of k64_usbdev.c to call khci_putreg to enable the DPPULLUP (was
in the fredom-k28 code) but will try your code changes.
I have a Picoscope which may have code for decoding USB transactions.
Kind regards
Stewart Charnell
On 15/02/2021 00:27, Brennan Ashton wrote:
> Stewart,
> I had been looking for an excuse to test NuttX on this chip, so I took
> a look and added the missing support you can see it here:
> https://github.com/apache/incubator-nuttx/pull/2847
>
> The main issue was the clock was not being configured correctly. The
> k28 has a different default PLL frequency so needs different scalers
> to get us the 48MHz clock.
>
> Personally when debugging USB I long ago invested in a USB analyzer
> which helps, but they are not cheap, so NuttX does have some really
> helpful built-in tracing functionality.
> The easiest way to enable it is through these configuration settings.
> Here I am using the nsh usbdev tracer, but you can also use the
> monitor functionality to dump to syslog but you then have to
> initialize the monitor thread as well.
>
> < CONFIG_DEBUG_ERROR=y
> < CONFIG_DEBUG_FEATURES=y
> < CONFIG_DEBUG_INFO=y
> < CONFIG_DEBUG_USB=y
> < CONFIG_DEBUG_USB_ERROR=y
> < CONFIG_DEBUG_USB_WARN=y
> < CONFIG_DEBUG_WARN=y
>
> < CONFIG_NSH_USBDEV_TRACE=y
> < CONFIG_NSH_USBDEV_TRACECLASS=y
> < CONFIG_NSH_USBDEV_TRACECONTROLLER=y
> < CONFIG_NSH_USBDEV_TRACEINIT=y
> < CONFIG_NSH_USBDEV_TRACEINTERRUPTS=y
> < CONFIG_NSH_USBDEV_TRACETRANSFERS=y
>
> < CONFIG_SYSTEM_CDCACM=y
> < CONFIG_SYSTEM_CDCACM_TRACECLASS=y
> < CONFIG_SYSTEM_CDCACM_TRACECONTROLLER=y
> < CONFIG_SYSTEM_CDCACM_TRACEINIT=y
> < CONFIG_SYSTEM_CDCACM_TRACEINTERRUPTS=y
> < CONFIG_SYSTEM_CDCACM_TRACETRANSFERS=y
>
> < CONFIG_USBDEV=y
> < CONFIG_USBDEV_DUALSPEED=y
> < CONFIG_USBDEV_TRACE=y
> < CONFIG_USBDEV_TRACE_STRINGS=y
>
> With these enabled here is what you get when sending some data out the
> CDCACM device:
>
> nsh> echo "foo" > /dev/ttyACM0
> Interrupt entry 23: ENTRY 0008
> Interrupt decode 21: KHCI_TRACEINTID_TRNC 0008
> Interrupt decode 22: KHCI_TRACEINTID_TRNCS 0000
> Interrupt decode 24: KHCI_TRACEINTID_NOSTDREQ 0021
> Interrupt decode 3: KHCI_TRACEINTID_DISPATCH 0000
> Class setup : Class SETUP request 0022
> EP submit : Submit endpoint request 0000
> EP 0 IN queued : Write request queued 0000
> EP 0 IN write : Outgoing data written 0000
> Interrupt decode 38: KHCI_TRACEINTID_EP0SETUPOUT 0080
> Interrupt exit 23: EXIT 0008
> Interrupt entry 23: ENTRY 0008
> Interrupt decode 21: KHCI_TRACEINTID_TRNC 0008
> Interrupt decode 22: KHCI_TRACEINTID_TRNCS 0028
> Interrupt decode 11: KHCI_TRACEINTID_EPINDONE 0028
> EP 2 Request complete: Request completed 0004
>
> Prior to the changes in my PR you would have seen the resets being set
> over and over from the
> host with no transactions ever starting. This was not super useful in
> this case since the issue
> was at the physical layer with the wrong clock being used.
>
> Hope this helps,
> Brennan
>
>
>
>
>
> On Sun, Feb 14, 2021 at 11:16 AM <nu...@charnell.plus.com> wrote:
>> Hello,
>>
>> Should have said this is the FRDM-K64F board, freedom-k64f configuration.
>>
>> Kind regards
>>
>> Stewart
>>
>> On 14/02/2021 09:37, nuttx@charnell.plus.com wrote:
>>> Hello,
>>>
>>> I would like to setup a Kinetis k64f as a USB host to communicate with
>>> a USB serial device. As there is not a configuration for USB host with
>>> the k64f I thought I would start by configuring the k64f as a USB
>>> device, but have not been able to produce a working (visible USB
>>> device on K64 USB interface) setup yet.
>>>
>>> I wonder if anyone has used the USB interface on the Kinetis k64f, or
>>> the Kinetis k28, or might have some tips on how to debug?
>>>
>>> The k64f has two modes of USB clocking, derived from PLL clock or
>>> IRC48 clock sync'd to incoming USB data. I started by using clocking
>>> derived from PLL.
>>>
>>> I have modified a number of source files based on the Kinetis k28,
>>> which has a configuration for usbnsh:
>>>
>>> nuttx/boards/arm/kinetis/freedom-k64f/include/board.h based on
>>> freedom-k28 board.h. Modified to set MCG Frequency (PLLOUT) to 96 MHz
>>> and included settings for USB clocks.
>>> nuttx/boards/arm/kinetis/freedom-k64f/src/k64_usbdev.c. Added DP
>>> Pullup in non-OTG device mode, based on k28_usbdev.c, and
>>> k64_usbinitialize routine. Pull-up functioning (measured with
>>> multimeter).
>>> nuttx/boards/arm/kinetis/freedom-k64f/src/k64_bringup.c - Added call
>>> to k64_usbinitialize & CONFIG_PL2303
>>>
>>> nsh is working over SDA USB interface (the Kinetis k64f board
>>> programming and debug interface, via a K20DX device, separate from the
>>> K64 USB interface connected directly to the k64f device). I also have
>>> Ethernet (nsh via telnet) functioning.
>>>
>>> I have built the PL2303 & CDCACM apps, neither produce a usb device
>>> visible from Linux laptop
>>>
>>> Output of dmesg (PL2303 app with some USB debug enabled)
>>> nsh> dmesg
>>> __start: Reset status: 00:00
>>> khci_hwinitialize: BDT Address 0
>>> khci_hwinitialize: BDTPAGE3 1f
>>> khci_hwinitialize: BDTPAGE2 ff
>>> khci_hwinitialize: BDTPAGE1 46
>>> Mounting procfs to /proc
>>> Successfully bound SDHC to the MMC/SD driver
>>> kinetis_usbsuspend: resume: 1
>>>
>>> Output of journalctl on linux PC connected via USB hub to K64 USB
>>> interface
>>>
>>> Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: new
>>> full-speed USB device number 124 using xhci_hcd
>>> Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: device
>>> descriptor read/64, error -32
>>> Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: device
>>> descriptor read/64, error -32
>>> Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: new
>>> full-speed USB device number 125 using xhci_hcd
>>> Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: device
>>> descriptor read/64, error -32
>>> Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: device
>>> descriptor read/64, error -32
>>> Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2-port4: attempt
>>> power cycle
>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: new
>>> full-speed USB device number 126 using xhci_hcd
>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
>>> responding to setup address.
>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
>>> responding to setup address.
>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: device not
>>> accepting address 126, error -71
>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: new
>>> full-speed USB device number 127 using xhci_hcd
>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
>>> responding to setup address.
>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
>>> responding to setup address.
>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: device not
>>> accepting address 127, error -71
>>> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2-port4: unable to
>>> enumerate USB device
>>>
>>>
>>> Kind regards
>>>
>>> Stewart Charnell
>>>
>>>
Re: USB on Kinetis k64f - FRDM-K64F board
Posted by Brennan Ashton <ba...@brennanashton.com>.
Stewart,
I had been looking for an excuse to test NuttX on this chip, so I took
a look and added the missing support you can see it here:
https://github.com/apache/incubator-nuttx/pull/2847
The main issue was the clock was not being configured correctly. The
k28 has a different default PLL frequency so needs different scalers
to get us the 48MHz clock.
Personally when debugging USB I long ago invested in a USB analyzer
which helps, but they are not cheap, so NuttX does have some really
helpful built-in tracing functionality.
The easiest way to enable it is through these configuration settings.
Here I am using the nsh usbdev tracer, but you can also use the
monitor functionality to dump to syslog but you then have to
initialize the monitor thread as well.
< CONFIG_DEBUG_ERROR=y
< CONFIG_DEBUG_FEATURES=y
< CONFIG_DEBUG_INFO=y
< CONFIG_DEBUG_USB=y
< CONFIG_DEBUG_USB_ERROR=y
< CONFIG_DEBUG_USB_WARN=y
< CONFIG_DEBUG_WARN=y
< CONFIG_NSH_USBDEV_TRACE=y
< CONFIG_NSH_USBDEV_TRACECLASS=y
< CONFIG_NSH_USBDEV_TRACECONTROLLER=y
< CONFIG_NSH_USBDEV_TRACEINIT=y
< CONFIG_NSH_USBDEV_TRACEINTERRUPTS=y
< CONFIG_NSH_USBDEV_TRACETRANSFERS=y
< CONFIG_SYSTEM_CDCACM=y
< CONFIG_SYSTEM_CDCACM_TRACECLASS=y
< CONFIG_SYSTEM_CDCACM_TRACECONTROLLER=y
< CONFIG_SYSTEM_CDCACM_TRACEINIT=y
< CONFIG_SYSTEM_CDCACM_TRACEINTERRUPTS=y
< CONFIG_SYSTEM_CDCACM_TRACETRANSFERS=y
< CONFIG_USBDEV=y
< CONFIG_USBDEV_DUALSPEED=y
< CONFIG_USBDEV_TRACE=y
< CONFIG_USBDEV_TRACE_STRINGS=y
With these enabled here is what you get when sending some data out the
CDCACM device:
nsh> echo "foo" > /dev/ttyACM0
Interrupt entry 23: ENTRY 0008
Interrupt decode 21: KHCI_TRACEINTID_TRNC 0008
Interrupt decode 22: KHCI_TRACEINTID_TRNCS 0000
Interrupt decode 24: KHCI_TRACEINTID_NOSTDREQ 0021
Interrupt decode 3: KHCI_TRACEINTID_DISPATCH 0000
Class setup : Class SETUP request 0022
EP submit : Submit endpoint request 0000
EP 0 IN queued : Write request queued 0000
EP 0 IN write : Outgoing data written 0000
Interrupt decode 38: KHCI_TRACEINTID_EP0SETUPOUT 0080
Interrupt exit 23: EXIT 0008
Interrupt entry 23: ENTRY 0008
Interrupt decode 21: KHCI_TRACEINTID_TRNC 0008
Interrupt decode 22: KHCI_TRACEINTID_TRNCS 0028
Interrupt decode 11: KHCI_TRACEINTID_EPINDONE 0028
EP 2 Request complete: Request completed 0004
Prior to the changes in my PR you would have seen the resets being set
over and over from the
host with no transactions ever starting. This was not super useful in
this case since the issue
was at the physical layer with the wrong clock being used.
Hope this helps,
Brennan
On Sun, Feb 14, 2021 at 11:16 AM <nu...@charnell.plus.com> wrote:
>
> Hello,
>
> Should have said this is the FRDM-K64F board, freedom-k64f configuration.
>
> Kind regards
>
> Stewart
>
> On 14/02/2021 09:37, nuttx@charnell.plus.com wrote:
> > Hello,
> >
> > I would like to setup a Kinetis k64f as a USB host to communicate with
> > a USB serial device. As there is not a configuration for USB host with
> > the k64f I thought I would start by configuring the k64f as a USB
> > device, but have not been able to produce a working (visible USB
> > device on K64 USB interface) setup yet.
> >
> > I wonder if anyone has used the USB interface on the Kinetis k64f, or
> > the Kinetis k28, or might have some tips on how to debug?
> >
> > The k64f has two modes of USB clocking, derived from PLL clock or
> > IRC48 clock sync'd to incoming USB data. I started by using clocking
> > derived from PLL.
> >
> > I have modified a number of source files based on the Kinetis k28,
> > which has a configuration for usbnsh:
> >
> > nuttx/boards/arm/kinetis/freedom-k64f/include/board.h based on
> > freedom-k28 board.h. Modified to set MCG Frequency (PLLOUT) to 96 MHz
> > and included settings for USB clocks.
> > nuttx/boards/arm/kinetis/freedom-k64f/src/k64_usbdev.c. Added DP
> > Pullup in non-OTG device mode, based on k28_usbdev.c, and
> > k64_usbinitialize routine. Pull-up functioning (measured with
> > multimeter).
> > nuttx/boards/arm/kinetis/freedom-k64f/src/k64_bringup.c - Added call
> > to k64_usbinitialize & CONFIG_PL2303
> >
> > nsh is working over SDA USB interface (the Kinetis k64f board
> > programming and debug interface, via a K20DX device, separate from the
> > K64 USB interface connected directly to the k64f device). I also have
> > Ethernet (nsh via telnet) functioning.
> >
> > I have built the PL2303 & CDCACM apps, neither produce a usb device
> > visible from Linux laptop
> >
> > Output of dmesg (PL2303 app with some USB debug enabled)
> > nsh> dmesg
> > __start: Reset status: 00:00
> > khci_hwinitialize: BDT Address 0
> > khci_hwinitialize: BDTPAGE3 1f
> > khci_hwinitialize: BDTPAGE2 ff
> > khci_hwinitialize: BDTPAGE1 46
> > Mounting procfs to /proc
> > Successfully bound SDHC to the MMC/SD driver
> > kinetis_usbsuspend: resume: 1
> >
> > Output of journalctl on linux PC connected via USB hub to K64 USB
> > interface
> >
> > Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: new
> > full-speed USB device number 124 using xhci_hcd
> > Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: device
> > descriptor read/64, error -32
> > Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: device
> > descriptor read/64, error -32
> > Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: new
> > full-speed USB device number 125 using xhci_hcd
> > Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: device
> > descriptor read/64, error -32
> > Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: device
> > descriptor read/64, error -32
> > Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2-port4: attempt
> > power cycle
> > Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: new
> > full-speed USB device number 126 using xhci_hcd
> > Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
> > responding to setup address.
> > Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
> > responding to setup address.
> > Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: device not
> > accepting address 126, error -71
> > Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: new
> > full-speed USB device number 127 using xhci_hcd
> > Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
> > responding to setup address.
> > Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
> > responding to setup address.
> > Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: device not
> > accepting address 127, error -71
> > Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2-port4: unable to
> > enumerate USB device
> >
> >
> > Kind regards
> >
> > Stewart Charnell
> >
> >
USB on Kinetis k64f - FRDM-K64F board
Posted by nu...@charnell.plus.com.
Hello,
Should have said this is the FRDM-K64F board, freedom-k64f configuration.
Kind regards
Stewart
On 14/02/2021 09:37, nuttx@charnell.plus.com wrote:
> Hello,
>
> I would like to setup a Kinetis k64f as a USB host to communicate with
> a USB serial device. As there is not a configuration for USB host with
> the k64f I thought I would start by configuring the k64f as a USB
> device, but have not been able to produce a working (visible USB
> device on K64 USB interface) setup yet.
>
> I wonder if anyone has used the USB interface on the Kinetis k64f, or
> the Kinetis k28, or might have some tips on how to debug?
>
> The k64f has two modes of USB clocking, derived from PLL clock or
> IRC48 clock sync'd to incoming USB data. I started by using clocking
> derived from PLL.
>
> I have modified a number of source files based on the Kinetis k28,
> which has a configuration for usbnsh:
>
> nuttx/boards/arm/kinetis/freedom-k64f/include/board.h based on
> freedom-k28 board.h. Modified to set MCG Frequency (PLLOUT) to 96 MHz
> and included settings for USB clocks.
> nuttx/boards/arm/kinetis/freedom-k64f/src/k64_usbdev.c. Added DP
> Pullup in non-OTG device mode, based on k28_usbdev.c, and
> k64_usbinitialize routine. Pull-up functioning (measured with
> multimeter).
> nuttx/boards/arm/kinetis/freedom-k64f/src/k64_bringup.c - Added call
> to k64_usbinitialize & CONFIG_PL2303
>
> nsh is working over SDA USB interface (the Kinetis k64f board
> programming and debug interface, via a K20DX device, separate from the
> K64 USB interface connected directly to the k64f device). I also have
> Ethernet (nsh via telnet) functioning.
>
> I have built the PL2303 & CDCACM apps, neither produce a usb device
> visible from Linux laptop
>
> Output of dmesg (PL2303 app with some USB debug enabled)
> nsh> dmesg
> __start: Reset status: 00:00
> khci_hwinitialize: BDT Address 0
> khci_hwinitialize: BDTPAGE3 1f
> khci_hwinitialize: BDTPAGE2 ff
> khci_hwinitialize: BDTPAGE1 46
> Mounting procfs to /proc
> Successfully bound SDHC to the MMC/SD driver
> kinetis_usbsuspend: resume: 1
>
> Output of journalctl on linux PC connected via USB hub to K64 USB
> interface
>
> Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: new
> full-speed USB device number 124 using xhci_hcd
> Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: device
> descriptor read/64, error -32
> Feb 13 10:18:21 stewart-Inspiron-5559 kernel: usb 1-2.4: device
> descriptor read/64, error -32
> Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: new
> full-speed USB device number 125 using xhci_hcd
> Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: device
> descriptor read/64, error -32
> Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2.4: device
> descriptor read/64, error -32
> Feb 13 10:18:22 stewart-Inspiron-5559 kernel: usb 1-2-port4: attempt
> power cycle
> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: new
> full-speed USB device number 126 using xhci_hcd
> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
> responding to setup address.
> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
> responding to setup address.
> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: device not
> accepting address 126, error -71
> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: new
> full-speed USB device number 127 using xhci_hcd
> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
> responding to setup address.
> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: Device not
> responding to setup address.
> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2.4: device not
> accepting address 127, error -71
> Feb 13 10:18:23 stewart-Inspiron-5559 kernel: usb 1-2-port4: unable to
> enumerate USB device
>
>
> Kind regards
>
> Stewart Charnell
>
>