Discussion:
NuttX 6.17 Released
(too old to reply)
Gregory N
2012-04-14 16:01:22 UTC
Permalink
NuttX-6.17 was released today and is available for download here:

https://sourceforge.net/projects/nuttx/files/nuttx/nuttx-6.17/

nuttx-6.17 Release Notes

The 84th release of NuttX, Version 6.17, was made on April 14, 2012, and is available for download from the SourceForge website. Note that the release consists of two tarballs: nuttx-6.17.tar.gz and apps-6.17.tar.gz. Both may be needed (see the top-level nuttx/README.txt file for build information).

Note also that all SVN information has been stripped from these tarballs. If you need the SVN configuration, you should check out directly from SVN. Revision r4607 should equivalent to release 6.17:

svn co -r4607 https://nuttx.svn.sourceforge.net/svnroot/nuttx nuttx

Post Release Patches:

* There are no post-released patches as of this writing.

New features and extended functionality:

* Networking. Additional low-level, thread-independent socket interfaces (for NFS client support).

* RTC. Added a new interface call clock_synchronize(). This function will reload the system time from an RTC and is required when the system re-awakens from certain deep-sleep modes.

* Graphics. Add NxConsole. This is a character device driver that wraps an NX window and can be re-directed for stdout. This allows, for example, a pop-up graphics window that contains a NuttShell (NSH) session. A test of NxConsole is available at apps/examples/nxconsole.

* Watchdog Drivers. Added an interface definition an "upper half" driver to support watchdog timers.

* Calypso. Support for TI Calypso-based cellphones (as supported by the Osmocom-BB project) was contributed by members of the Osmocom-BB team. This includes configurations for the Compal e88 and e99 phones.

* USB Device Interface. Needed to extend the USB device interface because there was no mechanism for passing endpoint OUT data that may need to accompany a setup request.

* STM32 drivers. Added some power management controls for entering reduced power consumption states. An OTG FS driver was completed and partially verified (this driver seems to be functional but since it has been test so lightly, it might better be listed in the next section "Work in progress").

* PIC32 drivers. The PIC32 Ethernet driver is now stable. The PIC32 USB device controller driver is now functional (but not yet stable).

* PIC32 boards. Added support for the Sure DB-DP11212 PIC32 General Purpose Demo Board. There is now a PIC32 Starter Kit that provides NSH only through a Telnet connection.

* Build System. Some header files were moved into include/nuttx. The goal is to move any non-standard header files to include/nuttx or include/arch. Moved include/math.h to include/nuttx/math.h; this file is now only instantiated as the 'system' math.h if CONFIG_ARCH_MATH_H=y is defined.

* Tools. Added tools/cmpconfig.c, a tool for comparing two configuration files.

Work in progress. This release includes some partially completed work that is still not ready for prime time.

* NFS Client. Work is progressing on support for an NFS client file system. This is a port of the BSD NFS client file system that is being done by Jose Pablo Rojas V.

* Automated Configuration. Automated configuration based on the kconfig-frontends tool is being incorporated into the build system. The configuration is still not complete enough for general use in this release.

* STM32 Drivers. Added files that will (eventually) hold an STM32 OTG FS host driver. This is still a work in progress.

Bugfixes:

* Networking. Corrected a deadlock that only occurred when executing the NSH ifconfig command over Telnet.

* File system. Fix incorrect return errno value from read() when the file is opened write-only.

* Graphics. Fix several compilation errors that have crept into the multi-user NX server because of lack of use.

* STM32. In order to use CAN2, both CAN1 and CAN2 clocking must be enabled. Fixed a troublesome bug in the STM32 F4 I2C driver that resulting in timeouts.

* LPC17xx. Fixes for errors the crept in the LPC17xx DAC logic (Contributed by Lzyy).

* Build System. Reordered the link command line to account for new versions of libgcc.a that require symbols from the application (abort()).

Additional bugfixes, name changes, and other differences as detailed in the ChangeLogs.
nuttx-6.17 ChangeLog

6.17 2012-04-14 Gregory Nutt <gnutt AT gnutt.org>

* configs/sure-pic32mx: Add support for the Sure DB-DP11212 PIC32 General Purpose Demo Board
* arch/arm/src/stm32/stm32_usbhost.c/.h: Add files that will (eventually) hold an STM32 USB host driver (the initial check-in is the NuttX LPC17 USB host driver with name changes only).
* arch/arm/src/stm32/chip/stm32_otgfs.h: STM32 USB OTG FS register definitions (not complete on initial check-in).
* net/connect.c: Add another low level, thread-independent socket interface for use within the OS.
* arch/mips/src/pic32mx/pic32mx_ethernet.c: The PIC32 Ethernet driver is now stable on the PIC32 Starter Kit.
* configs/pic32-starterkit/nsh2: Add a PIC32 Ethernet Starter Kit NSH configuration that has no serial console; all interaction is done via Telnet.
* net/netdev_sem.c: Correct a deadlock condition by making a seamphore recursive. To my knowledge this deadlock only occurs when running the NSH command ifconfig over Telnet. In that case the function netdev_foreach takes the network device semaphore, but so does the telnet logic causing the deadlock.
* arch/arm/src/stm32/stm32_pm*.c: Add basic STM32 power management logic that will eventually be used to implement low power states.
* arch/arm/src/stm32/stm32f*0xx_rcc.c: In order to use CAN2, both CAN1 and CAN2 clocking must be enabled.
* arch/mips/src/pic32mx/picm32mx-usbdev.c: Several stall-related fixes so that the USB device driver can used the the mass storage class (which does a LOT of stalling as part of its normal protocol). The PIC32 USB Mass Storage device is, however, still non-functional when debug is OFF.
* include/nuttx/fs: Move all file-system related files from include/nuttx to include/nuttx/fs.
* include/nuttx/serial: Move all serial-driver related files from include/nuttx to include/nuttx/serial.
* include/nuttx/clock.h and sched/clock_initialize.c: Add a new OS interface called clock_sychronize() that can be used to re-synchronize the NuttX system time with a hardware RTC. This function is called normally at power up but may also need to be called when recovering from certain low-power usage states where the system time is no longer accurate.
* arch/arm/src/calypso and arch/arm/include/calypso: Support for the TI "Calypso" phone processor. Contributed by Denis Carilki and includes the work of Denis, Alan Carvalho de Assis, and Stefan Richter.
* configs/compal_e88 and configs/compal_e99: Support for Compal e88 and e99 phones Contributed by Denis Carilki and includes the work of Denis, Alan Carvalho de Assis, and Stefan Richter.
* arch/arm/src/lpc17xx: Several fixes for error that have crept in for the LPC17xx DAC. Contributed by by Lzyy.
* graphics/nxconsole: Add a character driver that can be used as a console output device for text output (still under development on initial check-in).
* graphics/nxmu: Fix several compilation errors that have crept into the multi- user NX server because of lack of use.
* graphics/nxconsole: The NX text console is basically function (in multi- user NX mode only).
* arch/arm/src/stm32/stm32_i2c.c: Correct a bug in the STM32 I2C driver. The behavior of I2C status bits seems to be different between F1 and F4.
* configs/stm3210e-eval/nxconsole: New STM32 F1 configuration that runs the NuttShell (NSH) within an NX window.
* graphics/nxconsole/nxcon_sem.c: Add protection from re-entrance with debug is enabled.
* include/nuttx/ascii.h and vt100.h: Header files to centralize ASCII and VT100 escape sequence definitions.
* graphics/nxconsole/nxcon_vt100.c: Add add framework to support VT100 escape sequences in NxConsole.
* fs/fs_read.c: Fix read() return value for attempt to read from write-only file or device. Was returning EBADF, should return EACCES.
* graphics/nxconsole.c: NxConsole now supports backspace and a cursor.
* Kconfig and arch/sim/Kconfig: Beginnings of support for a NuttX configuration tool. Currently using the kconfig parser kconfig-frontend available at http://ymorin.is-a-geek.org/projects/kconfig-frontends (version 3.3.0-1 is also available in the NuttX SVN at trunk/misc/tools/kconfig-frontends-3.3.0-1.tar.gz). Contributed by Lzyy.
* */Kconfig: Added skeleton Kconfig files to all directories that may need them.
* include/nuttx/math.h: Moved include/math.h to include/nuttx/math.h because it conflicts too often with the system math.h (and people aren't inclined to read the documentation on how to handle this). Now, if CONFIG_ARCH_MATH_H=y is defined, the top-level makefile will copy the redirecting math.h header file from include/nuttx/math.h to include/math.h. So for the architectures that define CONFIG_ARCH_MATH_H=y, include/math.h will be in place as it was before; for the architectures that don't select CONFIG_ARCH_MATH_H, the redirecting math.h header file will stay out-of-the-way in include/nuttx/.
* Kconfig, sched/Kconfig, lib/Kconfig, libxx/Kconfig, arch/sim/Kconfig, drivers/Kconfig, drivers/mtd/Kconfig, drivers/input/Kconfig, drivers/analog/Kconfig, drivers/lcd/Kconfig: Updated kernel configuration support provided by Lzyy.
* Kconfig: Many more Kconfig updates (no longer tracking in the ChangeLog)
* arch/arm/src/Makefile, arch/x86/src/Makefile, arch/avr/src/Makefile, arch/mips/src/Makefile, arch/sim/src/Makefile, arch/hc/src/Makefile, arch/sh/src/Makefile: The libgcc.a in newer versions of GCC now have an dependency on an external implementation of abort(). This required modification to the Makefiles that do the final link: Now libgcc.a must be included within the group of libraries that are search recursively.
* arch/arm/srm/stm32/stm32_otgfsdev.c: A USB OTG FS device-side driver for the STM32 F4 (and maybe F2 and F1 connectivity line).
* tools/cmpconfig.c: A tool for comparing two configuration files.
* include/nuttx/usb/usbdev.h, drivers/usbdev/*, arch/*/src/*/usb.c: Extend the USB device side interface so that EP0 OUT data can be passed with OUT SETUP requests.
* include/nuttx/watchdog.h: Add the definition of a standard watchdog driver interface.
* drivers/watchdog.c: The "upper half" watchdog timer driver.

apps-6.17 ChangeLog

6.17 2012-04-14 Gregory Nutt <gnutt AT gnutt.org>

* apps/examples/can: Add conditional compilation so that the test can be configured to only send messages or to only receive messages. This will let the test work in other modes than simple loopback testing.
* apps/examples/hello and apps/examples/ostest: Can now be built as NSH built-int functions.
* vsn/hello: Removed. The modified apps/examples/hello is enough "Hello, World!"
* apps/examples/nxconsole: Add a test of the NX console device.
* apps/examples/nxconsole: The NX console example now supports running the NuttShell (NSH) within an NX window.
* apps/system/readline: Now uses standard definitions from include/nuttx/ascii.h and vt100.h
* Kconfig, */Kconfig: Added skeleton Kconfig files to all directories that may need them.
avrbasic
2012-04-21 11:50:53 UTC
Permalink
Hi

1) I2C fix STM32F4 OK, verified fully working no more issues

2) USB works for STM32F4 when enabled from UART console. When disabling uart consoler - our board is designed to have only usb console then problems happen :(

host tries to enumerate 3 times, each time first get descriptor fails, what i see

reset
get descriptor
setup ACK
IN response 1 byte packet data 0x0A with CRC 0x0000

reset
get descriptor
setup ACK
IN response 0 byte

reset
get descriptor
setup ACK
IN response 1 byte packet data 0x4E with CRC 0x0000

it seems like the responses are
<CR>N
probably first char of Nuttx, but this happening way before usb enumeration is completed!

Maybe I am doing something wrong?

Antti
Gregory N
2012-04-21 12:55:16 UTC
Permalink
Post by avrbasic
2) USB works for STM32F4 when enabled from UART console. When disabling uart consoler - our board is designed to have only usb console then problems happen :(
This sounds like a problem with the initialization sequence. What are you using for a configuration. Are you still using NSH but trying to connect through Telnet? Or a are you using some other configuration?

Greg
avrbasic
2012-04-21 13:05:21 UTC
Permalink
Post by Gregory N
Post by avrbasic
2) USB works for STM32F4 when enabled from UART console. When disabling uart consoler - our board is designed to have only usb console then problems happen :(
This sounds like a problem with the initialization sequence. What are you using for a configuration. Are you still using NSH but trying to connect through Telnet? Or a are you using some other configuration?
Greg
?
I have NSH conf modified to add more stuff, no networking at all, it was using uart console, no changed to usb console thats it.

do not see anything to change to get the init differently

Antti
Meier Lorenz
2012-04-23 13:31:02 UTC
Permalink
I can also report USB to be operational on our STM32F4x platform. I failed however to enable NSH through the CDC-ACM interface.

I tried to enable UART console and CDC console, leading to a crash:
CONFIG_CDCACM_CONSOLE=y
CONFIG_USART1_SERIAL_CONSOLE=y

Is this meant to be exclusive? I quickly tried to only enable the CDCACM console, but the board didn't connect to USB (I didn't get the time yet to check what JTAG tells me).

Am I missing something in the configuration?

-Lorenz
Post by avrbasic
2) USB works for STM32F4 when enabled from UART console. When disabling uart consoler - our board is designed to have only usb console then problems happen :(
This sounds like a problem with the initialization sequence. What are you using for a configuration. Are you still using NSH but trying to connect through Telnet? Or a are you using some other configuration?
Greg
?
I have NSH conf modified to add more stuff, no networking at all, it was using uart console, no changed to usb console thats it.

do not see anything to change to get the init differently

Antti






------------------------------------------------------
Lorenz Meier
PhD Student
Computer Vision and Geometry Lab
ETH Zurich /
Swiss Federal Institute of Technology
http://www.inf.ethz.ch/personal/lomeier/



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/nuttx/join
(Yahoo! ID required)

<*> To change settings via email:
nuttx-digest-***@public.gmane.org
nuttx-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
nuttx-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Gregory N
2012-04-23 14:10:26 UTC
Permalink
Post by Meier Lorenz
I can also report USB to be operational on our STM32F4x platform. I failed however to enable NSH through the CDC-ACM interface.
CONFIG_CDCACM_CONSOLE=y
CONFIG_USART1_SERIAL_CONSOLE=y
Yes, you can only have one console device (/dev/console)
Post by Meier Lorenz
Is this meant to be exclusive? ...
Yes
Post by Meier Lorenz
...I quickly tried to only enable the CDCACM console, but the board didn't connect to USB (I didn't get the time yet to check what JTAG tells me).
This sounds like the same problem that Antti reported. It sounds like some kind of initialization problem, but the solution is not known. I don't expect to be working with STM32 F4 USB for another week or so but I will make some time then to look into the problem if no one else comes up with a fix sooner.

Greg
Meier Lorenz
2012-04-24 09:33:45 UTC
Permalink
Following up on this, I seem to not be able to push data through the link. Greg, could you post your defconfig entries for the F4 board you were using? The default values in the defconfigs I've been looking at (eval and discovery) conflict with the comments in the comment section above. I would not be surprised if I set them wrong.

Thanks!

-Lorenz
Post by Meier Lorenz
I can also report USB to be operational on our STM32F4x platform. I failed however to enable NSH through the CDC-ACM interface.
CONFIG_CDCACM_CONSOLE=y
CONFIG_USART1_SERIAL_CONSOLE=y
Yes, you can only have one console device (/dev/console)
Post by Meier Lorenz
Is this meant to be exclusive? ...
Yes
Post by Meier Lorenz
...I quickly tried to only enable the CDCACM console, but the board didn't connect to USB (I didn't get the time yet to check what JTAG tells me).
This sounds like the same problem that Antti reported. It sounds like some kind of initialization problem, but the solution is not known. I don't expect to be working with STM32 F4 USB for another week or so but I will make some time then to look into the problem if no one else comes up with a fix sooner.

Greg






------------------------------------------------------
Lorenz Meier
PhD Student
Computer Vision and Geometry Lab
ETH Zurich /
Swiss Federal Institute of Technology
http://www.inf.ethz.ch/personal/lomeier/



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/nuttx/join
(Yahoo! ID required)

<*> To change settings via email:
nuttx-digest-***@public.gmane.org
nuttx-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
nuttx-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Gregory N
2012-04-24 12:27:13 UTC
Permalink
Post by Meier Lorenz
Following up on this, I seem to not be able to push data through the link. Greg, could you post your defconfig entries for the F4 board you were using? The default values in the defconfigs I've been looking at (eval and discovery) conflict with the comments in the comment section above. I would not be surprised if I set them wrong.
I'm not sure exactly what you are looking for. I don't have the exact USB configuration that I used during testing (on the STM32FDiscovery, by the way). As I recall all I used the stm32f4discovery/nsh configuration and all I did was CONFIG_USBDEV=y and CONFIG_CDCACM=y.

If you reuse other configurations, be careful with the endpoints. Most hardware supports 8 or 16 endpoints, but the STM32 F3 OTG FS supports only 4. You can only use endpoints 1, 2, and 3.

My understanding from your earlier emails is that USB does work for you ("I can also report USB to be operational") but that it fails when you configure the USB as a CDC/ACM console. This is the same problem that was reported by Antti a couple of weeks ago.

I have never used the STM32 F4 driver as a USB serial console. That configuration is/was untested. It was untested but know appears not to work. But other than the things that I have written about configuring the CDC console, I don't have any configuration solutions to give you.

Antti reported that the USB device did not even respond to the basic device enumeration in this case. I thought that this might be due to some difference in the initialization. For the NSH + USB + serial console case, the USB initialization is done in apps/examples/cdcacm. Of the NSH + USB + USB console, apps/examples/cdcacm should not be used and the USB initialization occurs in apps/nshlib/nsh_usbdev.c. Hmm.. but that look the same to me.

Perhaps if you could be more specific and, for example, describe what conflicts you seeing, then perhaps I could offer more.

Greg
avrbasic
2012-04-24 17:08:10 UTC
Permalink
Hi

once more, when trying to use cdcacm as console on F4, the nsh prompt is returned on EP0, before the enumeration.

first setup, get 0x0A that is <CR> as return data not descriptor data.
it beats me how the uart data payload is pushed into EP0 fifo??


with example

SERCON
all works
ah, SERDIS does not work, it will scroll register trace for ever, something is not completing, well that is minor for us, as we want the usb console to be always enabled

Antti
Post by Gregory N
Post by Meier Lorenz
Following up on this, I seem to not be able to push data through the link. Greg, could you post your defconfig entries for the F4 board you were using? The default values in the defconfigs I've been looking at (eval and discovery) conflict with the comments in the comment section above. I would not be surprised if I set them wrong.
I'm not sure exactly what you are looking for. I don't have the exact USB configuration that I used during testing (on the STM32FDiscovery, by the way). As I recall all I used the stm32f4discovery/nsh configuration and all I did was CONFIG_USBDEV=y and CONFIG_CDCACM=y.
If you reuse other configurations, be careful with the endpoints. Most hardware supports 8 or 16 endpoints, but the STM32 F3 OTG FS supports only 4. You can only use endpoints 1, 2, and 3.
My understanding from your earlier emails is that USB does work for you ("I can also report USB to be operational") but that it fails when you configure the USB as a CDC/ACM console. This is the same problem that was reported by Antti a couple of weeks ago.
I have never used the STM32 F4 driver as a USB serial console. That configuration is/was untested. It was untested but know appears not to work. But other than the things that I have written about configuring the CDC console, I don't have any configuration solutions to give you.
Antti reported that the USB device did not even respond to the basic device enumeration in this case. I thought that this might be due to some difference in the initialization. For the NSH + USB + serial console case, the USB initialization is done in apps/examples/cdcacm. Of the NSH + USB + USB console, apps/examples/cdcacm should not be used and the USB initialization occurs in apps/nshlib/nsh_usbdev.c. Hmm.. but that look the same to me.
Perhaps if you could be more specific and, for example, describe what conflicts you seeing, then perhaps I could offer more.
Greg
Gregory N
2012-04-24 17:42:25 UTC
Permalink
Post by avrbasic
first setup, get 0x0A that is <CR> as return data not descriptor data.
it beats me how the uart data payload is pushed into EP0 fifo??
I don't understand how that could happen. I am inclined to believe that it is only coincidental.

To debug this, I would use something like the stm3240g-eval/nsh2 configuration.

That has two things that can help you debug the problem:

I has a telnet terminal that you can use to debug.

It has a RAMMLOG device device that can collect debug data. When you turn on the RAMLOG device, it works a little Linux syslog-ing. If you type 'dmesg' in the NSH telnet session, you can see all of the debug output.

CONFIG_SYSLOG=y - Enables the System Logging feature.
CONFIG_RAMLOG=y - Enable the RAM-based logging feature.
CONFIG_RAMLOG_SYSLOG=y - This enables the RAM-based logger as the
system logger.

So if you also enable:

CONFIG_DEBUG=y
CONFIG_DEBUG_VERBOSE=y
CONFIG_DEBUG_USB=y

You should be able to see the USB debug output in the Telnet window.

apps/nshlib/nsh_usbdev.c does not enable the heavy duty USB trace features as does apps/examples/cdcacm. Those trace features could also set by adding this to nsh_usbdev.c:

usbtrace_enable(0xffff);

If I were working on the problem, that is what I would do.

Greg
avrbasic
2012-04-24 18:00:37 UTC
Permalink
you talk about telnet, but we have no stm32f4 board with network..

i could enable ram log, but how do i see the result as i do not have console at all?
not possible, the only way would be to send debug to uart while nsh console is usb
but i see no way of doing this?

antti
Post by Gregory N
Post by avrbasic
first setup, get 0x0A that is <CR> as return data not descriptor data.
it beats me how the uart data payload is pushed into EP0 fifo??
I don't understand how that could happen. I am inclined to believe that it is only coincidental.
To debug this, I would use something like the stm3240g-eval/nsh2 configuration.
I has a telnet terminal that you can use to debug.
It has a RAMMLOG device device that can collect debug data. When you turn on the RAMLOG device, it works a little Linux syslog-ing. If you type 'dmesg' in the NSH telnet session, you can see all of the debug output.
CONFIG_SYSLOG=y - Enables the System Logging feature.
CONFIG_RAMLOG=y - Enable the RAM-based logging feature.
CONFIG_RAMLOG_SYSLOG=y - This enables the RAM-based logger as the
system logger.
CONFIG_DEBUG=y
CONFIG_DEBUG_VERBOSE=y
CONFIG_DEBUG_USB=y
You should be able to see the USB debug output in the Telnet window.
usbtrace_enable(0xffff);
If I were working on the problem, that is what I would do.
Greg
Gregory N
2012-04-24 18:15:36 UTC
Permalink
Hi, Antti,
Post by avrbasic
you talk about telnet, but we have no stm32f4 board with network..
i could enable ram log, but how do i see the result as i do not have console at all?
not possible, the only way would be to send debug to uart while nsh console is usb
but i see no way of doing this?
There is no simple re-configuration to do this, but something like the following hack might work:

1. Disable CONFIG_CDCACM_CONSOLE
2. Re-enable CONFIG_UARTx_SERIAL_CONSOLE
3. In apps/nshlib/nsh.h, set define HAVE_USB_CONSOLE unconditionally
4. In apps/nshlib/nsh_usbdev.c change "/dev/console" to "/dev/ttyACM0"

What does that do? CDC/ACM is no long dev/console (1), the serial port is again the console (2). But NSH is forced to use the USB CDC/ACM for the I/O anyway (2) and finally it opens the normal USB device and uses that for the console (4).

So NSH should still be using the USB as through it were the console (it isn't), but debug output will now go out the "real" console /dev/console which will again be serial.

It might take a little tinkering but in concept that should work with no Telnet. Also there may be missing output from any logic that executes on the NSH thread because it does:

(void)fclose(stdin);
(void)fclose(stdout);
(void)fclose(stderr);

But 99.9% of the USB is interrupt driven so you should still get good debug output. You could even delet the lines about from nsh_usbdev.c temporarily.

Greg


Greg
avrbasic
2012-04-25 06:17:07 UTC
Permalink
Hi

it works a bit BETTER that way, but:

startup, all fine, enumeration ok
class IN 21 OK
class IN 21 OK
class OUT 22 OK
Post by Gregory N
open serial port from host >>
class in 21 OK
class out 20 (8 bytes payload) >> NAK, NAK
after 12 seconds host gives up sending nak, and thats it

Antti
Post by Gregory N
Hi, Antti,
you talk about telnet, but we have no stm32f4 board with network..
i could enable ram log, but how do i see the result as i do not have console at all?
not possible, the only way would be to send debug to uart while nsh console is usb
but i see no way of doing this?
1. Disable CONFIG_CDCACM_CONSOLE
2. Re-enable CONFIG_UARTx_SERIAL_CONSOLE
3. In apps/nshlib/nsh.h, set define HAVE_USB_CONSOLE unconditionally
4. In apps/nshlib/nsh_usbdev.c change "/dev/console" to "/dev/ttyACM0"
avrbasic
2012-04-25 08:05:56 UTC
Permalink
small update, with uart logging and all trace enabled the usb console
is not any more crashing usb traffic

when typing in usb console, the chars are sent to nuttx/nsh they symbols are consumed also, all is fine in usb analyzer logs
there is output from NSH, but the usb comms actually work
well at leas one way, usb uart to nuttx does go to "somewhere" not sure if it is handled also or trashed, as i do not see any debug out
its seems the nsh does not see the input, tried to make pwm buzzer
beep, nothing happened. but with no output hard to tell whats happening


Antti
Post by avrbasic
Hi
startup, all fine, enumeration ok
class IN 21 OK
class IN 21 OK
class OUT 22 OK
Post by Gregory N
open serial port from host >>
class in 21 OK
class out 20 (8 bytes payload) >> NAK, NAK
after 12 seconds host gives up sending nak, and thats it
Antti
Post by Gregory N
Hi, Antti,
you talk about telnet, but we have no stm32f4 board with network..
i could enable ram log, but how do i see the result as i do not have console at all?
not possible, the only way would be to send debug to uart while nsh console is usb
but i see no way of doing this?
1. Disable CONFIG_CDCACM_CONSOLE
2. Re-enable CONFIG_UARTx_SERIAL_CONSOLE
3. In apps/nshlib/nsh.h, set define HAVE_USB_CONSOLE unconditionally
4. In apps/nshlib/nsh_usbdev.c change "/dev/console" to "/dev/ttyACM0"
Gregory N
2012-04-25 13:32:25 UTC
Permalink
Hi, Antti,
Post by avrbasic
small update, with uart logging and all trace enabled the usb console
is not any more crashing usb traffic
So we made no code changes it begins to work? We just basically reconfigured the path that is taken by debug output so that it no long goes to the USB serial drvier and the USB driver begins to work again?

Hmmm.. So did you have debug output enabled before when you only had the USB serial console? If so, all of that debug output will try to go out the USB connection .. but before there is any USB connection. There is very likely some condition that would break the driver in that case. Is that what you were doing?

If so, then the longer range fix is the use the RAMLOG as the system logger as I mentioned in a previous email. Then all debug output will go to a circular buffer (and not to the USB device). You can look at the RAMLOG using the NSH 'dmesg' command.

Greg
avrbasic
2012-04-25 13:44:21 UTC
Permalink
Hi Greg,

1) examples/cdaacm >> all works (except serdis loops forever..)
2) full verbose logging to uart, usbconsole DOES NOT crash usb comms, typing in host console goes to DEV0, not appearing in nsh, but also no usb comm error
3) normal use of usb console issue at serial port open from host, EP0 OUT gets bad/no response..

i be checking more right now

Antti
Post by Gregory N
Hi, Antti,
Post by avrbasic
small update, with uart logging and all trace enabled the usb console
is not any more crashing usb traffic
So we made no code changes it begins to work? We just basically reconfigured the path that is taken by debug output so that it no long goes to the USB serial drvier and the USB driver begins to work again?
Hmmm.. So did you have debug output enabled before when you only had the USB serial console? If so, all of that debug output will try to go out the USB connection .. but before there is any USB connection. There is very likely some condition that would break the driver in that case. Is that what you were doing?
If so, then the longer range fix is the use the RAMLOG as the system logger as I mentioned in a previous email. Then all debug output will go to a circular buffer (and not to the USB device). You can look at the RAMLOG using the NSH 'dmesg' command.
Greg
Gregory N
2012-04-25 14:50:36 UTC
Permalink
Post by avrbasic
1) examples/cdaacm >> all works (except serdis loops forever..)
What do you mean by works? Did you try transferring data. I test with Linux and do this:

On the Linux host: cat /dev/ttyACM0
On the target: echo "This is a test" >/dev/ttyACM0

And

On the target: cat /dev/ttyACM0
On the Linux host: echo "This is a test" >/dev/ttyACM0

If you cannot pass data in that environment, it certainly won't work with NSH.
Post by avrbasic
2) full verbose logging to uart, usbconsole DOES NOT crash usb comms, typing in host console goes to DEV0, not appearing in nsh, but also no usb comm error
A better initial test would be to use /apps/examples/usbterm. See apps/examples/README.txt for information.
Post by avrbasic
3) normal use of usb console issue at serial port open from host, EP0 OUT gets bad/no response..
i be checking more right now
The work that I had that involved developing this driver has evaporated. So working on this is no longer on my critical path at all. I might be able to make some time this week to look at it, but don't count on it.

Greg
avrbasic
2012-04-25 15:03:44 UTC
Permalink
Post by Gregory N
Post by avrbasic
1) examples/cdaacm >> all works (except serdis loops forever..)
On the Linux host: cat /dev/ttyACM0
On the target: echo "This is a test" >/dev/ttyACM0
THIS works, the text is seen on the host, well i dont have linux host.. but i see it in PC terminal app
Post by Gregory N
And
On the target: cat /dev/ttyACM0
On the Linux host: echo "This is a test" >/dev/ttyACM0
OK, sending worked (to dev0),
i did try the cat thing, but i assume the data arrived as well
can test with the cat and then send data.. to be sure
Post by Gregory N
If you cannot pass data in that environment, it certainly won't work with NSH.
Post by avrbasic
2) full verbose logging to uart, usbconsole DOES NOT crash usb comms, typing in host console goes to DEV0, not appearing in nsh, but also no usb comm error
A better initial test would be to use /apps/examples/usbterm. See apps/examples/README.txt for information.
hm yes probably.. the EP0 OUT issue could be masked there..
Post by Gregory N
Post by avrbasic
3) normal use of usb console issue at serial port open from host, EP0 OUT gets bad/no response..
i be checking more right now
The work that I had that involved developing this driver has evaporated. So working on this is no longer on my critical path at all. I might be able to make some time this week to look at it, but don't count on it.
Greg
sound bad :( .. it looks some mess with EP0 OUT stuff, happening at when open windows com port.. pretty hard to debug, at the failing place i did not see anything at all in verbose register log... just nothing

the drivers seems to be like ALMOST there, just to fix the EP0 OUT issue...
Gregory N
2012-04-25 15:10:50 UTC
Permalink
Post by avrbasic
Post by Gregory N
On the target: cat /dev/ttyACM0
On the Linux host: echo "This is a test" >/dev/ttyACM0
OK, sending worked (to dev0),
i did try the cat thing, but i assume the data arrived as well
can test with the cat and then send data.. to be sure
When cat'ing received data on the target, the output will be be determined in part by the buffering setup. You might have to send data to the target and then get a block of buffered data out.
Post by avrbasic
sound bad :( .. it looks some mess with EP0 OUT stuff, happening at when open windows com port.. pretty hard to debug, at the failing place i did not see anything at all in verbose register log... just nothing
the drivers seems to be like ALMOST there, just to fix the EP0 OUT issue...
I don't understand what the EP0 OUT issue is.

Greg
avrbasic
2012-04-25 15:15:16 UTC
Permalink
i will try usb term now
Post by Gregory N
Post by avrbasic
1) examples/cdaacm >> all works (except serdis loops forever..)
On the Linux host: cat /dev/ttyACM0
On the target: echo "This is a test" >/dev/ttyACM0
And
On the target: cat /dev/ttyACM0
On the Linux host: echo "This is a test" >/dev/ttyACM0
this yields some debug log, but i do not see the symbols sent from PC to the NSH

stm32_epout_complete: EP3: len=64 xfrd=1
EP3 request complete: 0001
Class RD request complete: 0004
cdcacm_recvpacket: head=4 tail=4 nrdq=4 reqlen=1
Endpoint submit(): 0003
stm32_epout_request: EP3: len=64
stm32_getreg: 50000b70->0000003f
stm32_putreg: 50000b70<-00080040
stm32_getreg: 50000b60->000b8040
stm32_putreg: 50000b60<-840b8040
stm32_putreg: 50000014<-00080000
stm32_getreg: 50000014->448094a8
stm32_getreg: 50000018->000c2812
Interrupt 1 exit: 0000
Interrupt 1 entry: 0000
stm32_getreg: 50000014->448094a8
stm32_getreg: 50000014->448094a8
stm32_getreg: 50000018->000c2812
Interrupt 1 exit: 0000
Class API call 7: 0000
Class API call 7: 0001
Class API call 7: 0000
Class API call 7: 0001
Class API call 7: 0000
Class API call 7: 0001

this is end of log if one char is sent from the host to nsh
Gregory N
2012-04-25 15:21:52 UTC
Permalink
Post by avrbasic
stm32_epout_complete: EP3: len=64 xfrd=1
EP3 request complete: 0001
Class RD request complete: 0004
Here one byte is received without error
Post by avrbasic
cdcacm_recvpacket: head=4 tail=4 nrdq=4 reqlen=1
Endpoint submit(): 0003
Here is returns the read request to wait for the next incoming packet.
Post by avrbasic
this is end of log if one char is sent from the host to nsh
Looks fine. It just says it received one character on EP3. I would imagine that the data is sitting the stdout buffer.

Greg
avrbasic
2012-04-25 15:28:36 UTC
Permalink
yes, I do not know how to make to appear :)
i guessed your cat line would do it, but apparently it does not as nothing happens in nsh window..

compiling usbterm now.

Greg you have SUPER JOB with the driver porting, I wish I could have helped more, but right now the last issues seem to be something in the very inner circles of the nuttx, so its not easy to step in here. Its not an STM32F4 issue, at the failing place there are just no register writes happening. I assume the lower driver does not expect EP0 OUT at that point and hence timeouts..

but this only happens when usb console is selected, at the time when host open port. SERCON works fine, but then well the init sequence is much different the usb console is enable at much later time

Antti
Post by Gregory N
Post by avrbasic
stm32_epout_complete: EP3: len=64 xfrd=1
EP3 request complete: 0001
Class RD request complete: 0004
Here one byte is received without error
Post by avrbasic
cdcacm_recvpacket: head=4 tail=4 nrdq=4 reqlen=1
Endpoint submit(): 0003
Here is returns the read request to wait for the next incoming packet.
Post by avrbasic
this is end of log if one char is sent from the host to nsh
Looks fine. It just says it received one character on EP3. I would imagine that the data is sitting the stdout buffer.
Greg
avrbasic
2012-04-25 15:51:32 UTC
Permalink
USBTERM and NSH usb console behave the same way...

when PC open port>

class in 21
class in 21
class out 20 with 7 byte to EP0 endpoint

NACK for too long time out host side, all freeze

most likely issue is of course me messing something up :(
cant just find what

Antti
Post by Gregory N
Post by avrbasic
stm32_epout_complete: EP3: len=64 xfrd=1
EP3 request complete: 0001
Class RD request complete: 0004
Here one byte is received without error
Post by avrbasic
cdcacm_recvpacket: head=4 tail=4 nrdq=4 reqlen=1
Endpoint submit(): 0003
Here is returns the read request to wait for the next incoming packet.
Post by avrbasic
this is end of log if one char is sent from the host to nsh
Looks fine. It just says it received one character on EP3. I would imagine that the data is sitting the stdout buffer.
Greg
avrbasic
2012-04-25 14:48:01 UTC
Permalink
getting round and round :(

STM32F4 usb console SHOWSTOPPER BUG: ALWAYS when second class OUT comes, it happens when PC open port, then this transaction fails, it times out on NAK, terminates in 6..13 seconds, never succeeds. NEVER passed past this, no matter what combination i used.

I got now to see NSH prompt being sent out to usb in the usb analyzer log, well it was before i tried open serial port on PC, so i did not see it pc terminal, but data was sent to usb console

in some case also did see the data sent from PC NSH to be sent, eg consumed..

so all comm NOT USING EP0 work, but EP0 class out, fails..

i am not sure how to use ramlog without telnet? i can log either
to uart then i can see, or to ram, but if usb console is not working i can not see what is in ramlog anyway..

trying still a little bit
Antti
Post by Gregory N
Hi, Antti,
Post by avrbasic
small update, with uart logging and all trace enabled the usb console
is not any more crashing usb traffic
So we made no code changes it begins to work? We just basically reconfigured the path that is taken by debug output so that it no long goes to the USB serial drvier and the USB driver begins to work again?
Hmmm.. So did you have debug output enabled before when you only had the USB serial console? If so, all of that debug output will try to go out the USB connection .. but before there is any USB connection. There is very likely some condition that would break the driver in that case. Is that what you were doing?
If so, then the longer range fix is the use the RAMLOG as the system logger as I mentioned in a previous email. Then all debug output will go to a circular buffer (and not to the USB device). You can look at the RAMLOG using the NSH 'dmesg' command.
Greg
Loading...