USB on Kinetis k64f

2021-02-14 Thread nuttx

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




Board-level Ethernet PHY operations in STM32.

2021-02-14 Thread Fotis Panagiotopoulos
Hi everybody,

I am trying to perform some reads/writes to my Ethernet PHY (LAN8720A) in
board-level.

I am pretty confused on what is the correct interface to use for this
purpose.
As far as I can tell, it is only possible to perform MII read/writes
through ioctl's in application code.
How can the board logic control the PHY? Is this possible?


USB on Kinetis k64f - FRDM-K64F board

2021-02-14 Thread nuttx

Hello,

Should have said this is the FRDM-K64F board, freedom-k64f configuration.

Kind regards

Stewart

On 14/02/2021 09:37, nu...@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




Using nsh application return code in a script

2021-02-14 Thread Bob Feretich

I have tried to write a nsh script that...
* Runs an application.
* Examines the application's return code.
* Then runs one of several applications based upon the value of the return code.

The application return code seems to have an effect on $?, if I set the return 
code to 0 or 1,
but if I set the return code to 2, $? never shows the 2.

How can I store the application return code in a local nsh variable, so I can 
test it using if-then-else-fi?

Regards,
Bob


Re: USB on Kinetis k64f - FRDM-K64F board

2021-02-14 Thread Brennan Ashton
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 entry23: ENTRY0008
Interrupt decode   21: KHCI_TRACEINTID_TRNC 0008
Interrupt decode   22: KHCI_TRACEINTID_TRNCS
Interrupt decode   24: KHCI_TRACEINTID_NOSTDREQ 0021
Interrupt decode3: KHCI_TRACEINTID_DISPATCH 
Class setup  : Class SETUP request  0022
EP submit: Submit endpoint request  
EP 0 IN queued   : Write request queued 
EP 0 IN write: Outgoing data written
Interrupt decode   38: KHCI_TRACEINTID_EP0SETUPOUT  0080
Interrupt exit 23: EXIT 0008
Interrupt entry23: ENTRY0008
Interrupt decode   21: KHCI_TRACEINTID_TRNC 0008
Interrupt decode   22: KHCI_TRACEINTID_TRNCS0028
Interrupt decode   11: KHCI_TRACEINTID_EPINDONE 0028
EP 2 Request complete: Request completed0004

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  wrote:
>
> Hello,
>
> Should have said this is the FRDM-K64F board, freedom-k64f configuration.
>
> Kind regards
>
> Stewart
>
> On 14/02/2021 09:37, nu...@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