Loading ...
Sorry, an error occurred while loading the content.
 

Re: STM32F4 USB issue: debug log disable...!

Expand Messages
  • Gregory N
    Hi, Antti, ... What is the status of this fix? Any progress? Do you have a fix yet? Greg
    Message 1 of 29 , May 3, 2012
      Hi, Antti,

      > DEBUG OFF, adding ONE DELAY HERE
      > ////////////////////
      > stm32_putreg(regval, STM32_OTGFS_DOEPTSIZ0);
      >
      > up_udelay(2000); // single delay required, sercon will work then
      >
      > /* Then clear NAKing and enable the transfer */
      > regval = stm32_getreg(STM32_OTGFS_DOEPCTL0);
      > regval |= (OTGFS_DOEPCTL0_CNAK | OTGFS_DOEPCTL0_EPENA);
      > stm32_putreg(regval, STM32_OTGFS_DOEPCTL0);
      >
      > //////////
      >
      > works 100% in USBTERM, and
      > with sercon method on NSH,
      >
      > when trying it as usb console NSH, then I get
      >
      > NAK forever on first get descriptor.. hmm
      > same when add delay on all reg writes. I better take clean .c
      > file and test again.
      >
      > but we are closer to find the bugs now I think.
      > the delay in the code above is not proper fix of course, but it should help to find out where problem or part of it is

      What is the status of this fix? Any progress? Do you have a fix yet?

      Greg
    • Meier Lorenz
      Hi, I cannot confirm the results: I do get all data from the device on the host, but I do not receive any data from the host on the device. My host OS is Mac
      Message 2 of 29 , May 3, 2012
        Hi,

        I cannot confirm the results: I do get all data from the device on the host, but I do not receive any data from the host on the device. My host OS is Mac OS X Snow Leopard.

        I have the "fixes" Antti discussed on the mailing list, but I'm not sure wether I run the same USB defconfig. Antti, could you maybe share your full USB defconfig, not only the 3-4 lines of the main configuration flags? Thanks!

        Cheers,
        Lorenz

        Am 04.05.2012 um 03:05 schrieb Gregory N:



        Hi, Antti,

        > DEBUG OFF, adding ONE DELAY HERE
        > ////////////////////
        > stm32_putreg(regval, STM32_OTGFS_DOEPTSIZ0);
        >
        > up_udelay(2000); // single delay required, sercon will work then
        >
        > /* Then clear NAKing and enable the transfer */
        > regval = stm32_getreg(STM32_OTGFS_DOEPCTL0);
        > regval |= (OTGFS_DOEPCTL0_CNAK | OTGFS_DOEPCTL0_EPENA);
        > stm32_putreg(regval, STM32_OTGFS_DOEPCTL0);
        >
        > //////////
        >
        > works 100% in USBTERM, and
        > with sercon method on NSH,
        >
        > when trying it as usb console NSH, then I get
        >
        > NAK forever on first get descriptor.. hmm
        > same when add delay on all reg writes. I better take clean .c
        > file and test again.
        >
        > but we are closer to find the bugs now I think.
        > the delay in the code above is not proper fix of course, but it should help to find out where problem or part of it is

        What is the status of this fix? Any progress? Do you have a fix yet?

        Greg
      • Gregory N
        Antti, are you still monitoring these thread? ... I just re-built and retested but I do not see any problem. The USB CD/ACM driver worked fine for me. We
        Message 3 of 29 , May 25, 2012
          Antti, are you still monitoring these thread?

          I have found some time to look at this problem that you reported... that USB CDC/ACM does not work with debug off or with the USB console:

          > DEBUG OFF, adding ONE DELAY HERE
          > ////////////////////
          > stm32_putreg(regval, STM32_OTGFS_DOEPTSIZ0);
          >
          > up_udelay(2000); // single delay required, sercon will work then
          >
          > /* Then clear NAKing and enable the transfer */
          > regval = stm32_getreg(STM32_OTGFS_DOEPCTL0);
          > regval |= (OTGFS_DOEPCTL0_CNAK | OTGFS_DOEPCTL0_EPENA);
          > stm32_putreg(regval, STM32_OTGFS_DOEPCTL0);
          >
          > //////////
          >
          > works 100% in USBTERM, and
          > with sercon method on NSH,
          >
          > when trying it as usb console NSH, then I get
          >
          > NAK forever on first get descriptor.. hmm

          I just re-built and retested but I do not see any problem. The USB CD/ACM driver worked fine for me. We must have something different in our setup or in our hardware or in the host that we are using. Here is a description of what I am using:

          Hardware: STM32F4Discovery
          NuttX version: SVN on May 5, 2012 (NuttX-6.18 plus changes)
          USB host: Linux (OpenSUSE 12.3)
          Toolchain: CodeSourcery for Windows
          Configuration: configs/stm32f4discovery/nsh plus the following changes in the .config file:

          -CONFIG_STM32_CODESOURCERYW=n
          -CONFIG_STM32_CODESOURCERYL=y
          +CONFIG_STM32_CODESOURCERYW=y
          +CONFIG_STM32_CODESOURCERYL=n

          -CONFIG_USBDEV=n
          +CONFIG_USBDEV=y

          -CONFIG_CDCACM=n
          +CONFIG_CDCACM=y

          Note that (1) debug is OFF and (2) there are no delays or any other kind of modification to the NuttX code. Under those conditions the USB CDC/ACM device is recognized without issue by Linux (when the NSH sercon command is entered) and at least short data transfers work fine. Everything works fine for me.

          I will set up and test a USB console version report those results later.

          Greg
        • Meier Lorenz
          Hi all, Here is my setup / results: NuttX: Hardware: Custom M4 board, but 1:1 same on the USB pins with the F4 discovery NuttX version: SVN rev 4751 (plus some
          Message 4 of 29 , May 25, 2012
            Hi all,

            Here is my setup / results:

            NuttX:

            Hardware: Custom M4 board, but 1:1 same on the USB pins with the F4 discovery
            NuttX version: SVN rev 4751 (plus some minor patches and not in the USB layer)
            USB host: Mac OS X (Lion / 10.7)
            Toolchain: Official ARM GCC build (https://launchpad.net/gcc-arm-embedded, version string: (GNU Tools for ARM Embedded Processors) 4.6.2 20120316 (release) [ARM/embedded-4_6-branch revision 185452])
            Configuration: Copy of the F4 discovery with modifications for the custom board, plus the following changes in the .config file:

            Defconfig changes:

            -CONFIG_USBDEV=n
            +CONFIG_USBDEV=y

            -CONFIG_CDCACM=n
            +CONFIG_CDCACM=y

            Tests performed:

            host->device:

            device: cat /dev/ttyACM0
            host: echo "This is a test" > /dev/tty.usbmodem1

            No response, no transmission, interestingly Mac OS reports an IO error:

            user$ echo "This is a test" > /dev/tty.usbmodem1
            ^C-bash: /dev/tty.usbmodem1: Input/output error


            device->host

            host: screen /dev/tty.usbmodem1
            device: echo ABC > /dev/ttyACM0

            Success, test data is transmitted


            So I guess there is still an issue with all non-Linux based OS? Greg, do you have a Windows or Mac machine within reach? Thanks for getting this so far, there seems so little missing (maybe not in debugging time, of course).

            Cheers,
            Lorenz

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

            Am 25.05.2012 um 20:01 schrieb Gregory N:



            Antti, are you still monitoring these thread?

            I have found some time to look at this problem that you reported... that USB CDC/ACM does not work with debug off or with the USB console:

            > DEBUG OFF, adding ONE DELAY HERE
            > ////////////////////
            > stm32_putreg(regval, STM32_OTGFS_DOEPTSIZ0);
            >
            > up_udelay(2000); // single delay required, sercon will work then
            >
            > /* Then clear NAKing and enable the transfer */
            > regval = stm32_getreg(STM32_OTGFS_DOEPCTL0);
            > regval |= (OTGFS_DOEPCTL0_CNAK | OTGFS_DOEPCTL0_EPENA);
            > stm32_putreg(regval, STM32_OTGFS_DOEPCTL0);
            >
            > //////////
            >
            > works 100% in USBTERM, and
            > with sercon method on NSH,
            >
            > when trying it as usb console NSH, then I get
            >
            > NAK forever on first get descriptor.. hmm

            I just re-built and retested but I do not see any problem. The USB CD/ACM driver worked fine for me. We must have something different in our setup or in our hardware or in the host that we are using. Here is a description of what I am using:

            Hardware: STM32F4Discovery
            NuttX version: SVN on May 5, 2012 (NuttX-6.18 plus changes)
            USB host: Linux (OpenSUSE 12.3)
            Toolchain: CodeSourcery for Windows
            Configuration: configs/stm32f4discovery/nsh plus the following changes in the .config file:

            -CONFIG_STM32_CODESOURCERYW=n
            -CONFIG_STM32_CODESOURCERYL=y
            +CONFIG_STM32_CODESOURCERYW=y
            +CONFIG_STM32_CODESOURCERYL=n

            -CONFIG_USBDEV=n
            +CONFIG_USBDEV=y

            -CONFIG_CDCACM=n
            +CONFIG_CDCACM=y

            Note that (1) debug is OFF and (2) there are no delays or any other kind of modification to the NuttX code. Under those conditions the USB CDC/ACM device is recognized without issue by Linux (when the NSH sercon command is entered) and at least short data transfers work fine. Everything works fine for me.

            I will set up and test a USB console version report those results later.

            Greg
          • Gregory Nutt
            ... You need to do this many times because there is buffering.  I had to buffer about 20 This is a test lines then they all appear. ... Maybe you didn t
            Message 5 of 29 , May 25, 2012
              > host: echo "This is a test" > /dev/tty.usbmodem1

              You need to do this many times because there is buffering.  I had to buffer about 20 "This is a test lines" then they all appear.

              > No response, no transmission, interestingly Mac OS reports an IO error:

              Maybe you didn't send enough data to get past whatever buffereing is occurring?

              > So I guess there is still an issue with all non-Linux based OS? Greg, do you have a Windows or Mac machine within reach? Thanks for getting this so far, there seems so little missing (maybe not in debugging time, of course).

              Nope.  No Macs and I don't know anything about Windows USB setup.

              Greg

            • Meier Lorenz
              Hi Greg, Indeed, got the data now through! So there is about a 200 byte buffer in between? But this can be somehow adjusted, right? Since I ve used
              Message 6 of 29 , May 25, 2012
                Hi Greg,

                Indeed, got the data now through! So there is about a 200 byte buffer in between?

                But this can be somehow adjusted, right? Since I've used libopencm3-CDC with single byte transmissions?

                So how do we proceed from here?

                Cheers,
                Lorenz

                Am 26.05.2012 um 00:16 schrieb Gregory Nutt:



                > host: echo "This is a test" > /dev/tty.usbmodem1

                You need to do this many times because there is buffering. I had to buffer about 20 "This is a test lines" then they all appear.

                > No response, no transmission, interestingly Mac OS reports an IO error:

                Maybe you didn't send enough data to get past whatever buffereing is occurring?

                > So I guess there is still an issue with all non-Linux based OS? Greg, do you have a Windows or Mac machine within reach? Thanks for getting this so far, there seems so little missing (maybe not in debugging time, of course).

                Nope. No Macs and I don't know anything about Windows USB setup.

                Greg
              • Gregory Nutt
                Well, that test is only intended to demonstrate data integrity so I never concerned myself with why the buffering is occurring.  It the data makes it through
                Message 7 of 29 , May 25, 2012
                  Well, that test is only intended to demonstrate data integrity so I never concerned myself with why the buffering is occurring.  It the data makes it through both ways, USB is good.

                  Do you have any of Antti's delays added in the code?  I did not need them.  His problem was with Windows and in his case, the device was not recognized without adding some delays in strategic points.

                  I am working through issues with USB console now.  There are some problems and I haven't got my arms around all of them yet.  There was a check in that (for me) fixed receipt for data from the target by the host terminal -- at least with debug on.  But right now, all of the data that I send to the USB console is 'E'.  The command 'ls' looks like 'EE'.  Since we have shown that the data transfer is okay in the other test, I find this result surprising.

                  The changes that I made to the current SVN (r4771) are only only in my .config file:

                  $ diff -u configs/stm32f4discovery/nsh/defconfig .config
                  -CONFIG_STM32_CODESOURCERYW=n
                  -CONFIG_STM32_CODESOURCERYL=y
                  +CONFIG_STM32_CODESOURCERYW=y
                  +CONFIG_STM32_CODESOURCERYL=n

                  -CONFIG_DEBUG=n
                  -CONFIG_DEBUG_VERBOSE=n
                  +CONFIG_DEBUG=y
                  +CONFIG_DEBUG_VERBOSE=y
                  -CONFIG_DEBUG_USB=n
                  +CONFIG_DEBUG_USB=y

                  -CONFIG_USBDEV=n
                  +CONFIG_USBDEV=y

                  -CONFIG_CDCACM=n
                  +CONFIG_CDCACM=y

                  -CONFIG_NSH_USBCONSOLE=n
                  +CONFIG_NSH_USBCONSOLE=y

                  Greg

                • erikvanderzalm@rocketmail.com
                  Hello Greg, I am trying to get the USB console working on a STM32F4discovery board. When I connect to linux the enumeration is ok. The board is detected and I
                  Message 8 of 29 , May 27, 2012
                    Hello Greg,

                    I am trying to get the USB console working on a STM32F4discovery board.

                    When I connect to linux the enumeration is ok. The board is detected and I can connect to the virtual serial port. When I connect to the port I get no communication.
                    On the ellisys usb explorer I can see that linux sends the typed characters.

                    When I connect to windows7 the enumeration is ok. It is detected and the virtual com port is created. I can not connect to this port. (Timeout)

                    When I connect to osx the enumeration fails. In the USB log a can see that the board gets an address. Then it is reset and when it gets the same address is does not accept this address.

                    I needed I can make some log files.

                    Erik

                    --- In nuttx@yahoogroups.com, Gregory Nutt <spudarnia@...> wrote:
                    >
                    > Well, that test is only intended to demonstrate data integrity so I never concerned myself with why the buffering is occurring.  It the data makes it through both ways, USB is good.
                    >
                    > Do you have any of Antti's delays added in the code?  I did not need them.  His problem was with Windows and in his case, the device was not recognized without adding some delays in strategic points.
                    >
                    > I am working through issues with USB console now.  There are some problems and I haven't got my arms around all of them yet.  There was a check in that (for me) fixed receipt for data from the target by the host terminal -- at least with debug on.  But right now, all of the data that I send to the USB console is 'E'.  The command 'ls' looks like 'EE'.  Since we have shown that the data transfer is okay in the other test, I find this result surprising.
                    >
                    > The changes that I made to the current SVN (r4771) are only only in my .config file:
                    >
                    > $ diff -u configs/stm32f4discovery/nsh/defconfig .config
                    > -CONFIG_STM32_CODESOURCERYW=n
                    > -CONFIG_STM32_CODESOURCERYL=y
                    > +CONFIG_STM32_CODESOURCERYW=y
                    > +CONFIG_STM32_CODESOURCERYL=n
                    >
                    >
                    > -CONFIG_DEBUG=n
                    > -CONFIG_DEBUG_VERBOSE=n
                    > +CONFIG_DEBUG=y
                    > +CONFIG_DEBUG_VERBOSE=y
                    > -CONFIG_DEBUG_USB=n
                    > +CONFIG_DEBUG_USB=y
                    >
                    >
                    > -CONFIG_USBDEV=n
                    > +CONFIG_USBDEV=y
                    >
                    >
                    > -CONFIG_CDCACM=n
                    > +CONFIG_CDCACM=y
                    >
                    >
                    > -CONFIG_NSH_USBCONSOLE=n
                    > +CONFIG_NSH_USBCONSOLE=y
                    >
                    >
                    > Greg
                    >
                  • Gregory N
                    ... Yes, the input (USB OUT) to the STM32F4Discovery is good. And from what I have seen on Linux, the output (USB IN) is good too UNTIL there are queued
                    Message 9 of 29 , May 27, 2012
                      > When I connect to windows7 the enumeration is ok. It is detected and the virtual com port is created. I can not connect to this port. (Timeout)

                      Yes, the input (USB OUT) to the STM32F4Discovery is good. And from what I have seen on Linux, the output (USB IN) is good too UNTIL there are queued ongoing, write data transfers: After the first write transfer is queue, the driver never recovers and only NAKs attempts to read by the host.

                      There are some minor fixes in SVN but they do not fix the overall problem. Lorenz Meier and I have been working this problem outside the forum. I will update you with some of the more detailed emails so that you will have the same information.

                      We really need to get this bug solved so any help is appreciated.

                      > When I connect to osx the enumeration fails. In the USB log a can see that the board gets an address. Then it is reset and when it gets the same address is does not accept this address.

                      I don't have OSX so I have no comment. Windows may have a similar issue (Linux does work fine). In this same message thread, there is a email that says that if you put a delay at a specific point in the code, then you can connect on Windows. Have you tried adding that delay? I don't want to add a delay in the base code; I would prefer to understand the root cause of the OSX/Windows problem before making any changes.

                      Greg
                    • Gregory N
                      I just checked in a check that resolves all of the problems that I had with the USB CDC/ACM NSH console. I am still testing only on Linux so I don t know
                      Message 10 of 29 , May 28, 2012
                        I just checked in a check that resolves all of the problems that I had with the USB CDC/ACM NSH console. I am still testing only on Linux so I don't know anything about OSX or Windows issues.

                        The check-in contains two basic changes:

                        1. There was a busy/active status flag that was not being handled correctly when write requests were queued.

                        2. And we are missing some TxFIFO interrupts. Here is a nasty hack in the code now that allows it to work. I still don't understand the correct fix, but this hack allows the driver to work okay.

                        The hack is to poll for TxFIFO interrupts. The original logic would setup the TxFIFO interrupt when there was insufficient space in the TxFIFO for the next packet. That did not work properly.. but replacing this with a poll seems to work fine.

                        Putting a polling loop like this inside of an interrupt handler is a really bad idea. Certainly you should not do this in a production USB driver or in environments where you really care about performance.

                        So if someone can offer a proper solution for the hack, it would be much appreciated. The hack is delineated by conditional compilation on ENABLE_DTXFSTS_POLLHACK in stm32_otgfsdev.c.

                        Greg
                      • Meier Lorenz
                        Hi Greg, I can report success in that I managed to reproduce your results on Mac OS X 10.7, I have a working USB serial console. I can t make any comments on
                        Message 11 of 29 , May 29, 2012
                          Hi Greg,

                          I can report success in that I managed to reproduce your results on Mac OS X 10.7, I have a working USB serial console. I can't make any comments on reliability and higher transmission speeds yet, but the basic typing and printing works.

                          For convenience I made a similar hack as in the UART driver (with the difference that it is for now always active), see below. It kind of points towards the need of an additional abstraction layer between UART/USB drivers and the console? Or we add termios support to the USB CDC driver.

                          The diff below is by now means a proposal, I just copy it here for reference in case somebody else want to hack along and wants a temporary solution for the current work-in-progress state.

                          Again, thank you so much for this effort! I'll be testing with 4-6 boards in parallel this week and I'll keep you posted about our findings. I can't promise great code improvements though, mostly due to a lack of knowledge about the USB stack (and the current lack of time to properly read that up).

                          Cheers,
                          Lorenz


                          diff --git a/nuttx/drivers/usbdev/cdcacm.c b/nuttx/drivers/usbdev/cdcacm.c
                          index 97c9d7c..e6f38e9 100644
                          --- a/nuttx/drivers/usbdev/cdcacm.c
                          +++ b/nuttx/drivers/usbdev/cdcacm.c
                          @@ -269,6 +269,11 @@ static uint16_t cdcacm_fillrequest(FAR struct cdcacm_dev_s *priv, uint8_t *reqbu

                          while (xmit->head != xmit->tail && nbytes < reqlen)
                          {
                          + /* XXX Nasty, nasty hack: Prepend \r if \n is to be sent */
                          + if (xmit->buffer[xmit->tail] == '\n') {
                          + *reqbuf++ = '\r';
                          + nbytes++;
                          + }
                          *reqbuf++ = xmit->buffer[xmit->tail];
                          nbytes++;



                          Am 28.05.2012 um 19:13 schrieb Gregory N:



                          I just checked in a check that resolves all of the problems that I had with the USB CDC/ACM NSH console. I am still testing only on Linux so I don't know anything about OSX or Windows issues.

                          The check-in contains two basic changes:

                          1. There was a busy/active status flag that was not being handled correctly when write requests were queued.

                          2. And we are missing some TxFIFO interrupts. Here is a nasty hack in the code now that allows it to work. I still don't understand the correct fix, but this hack allows the driver to work okay.

                          The hack is to poll for TxFIFO interrupts. The original logic would setup the TxFIFO interrupt when there was insufficient space in the TxFIFO for the next packet. That did not work properly.. but replacing this with a poll seems to work fine.

                          Putting a polling loop like this inside of an interrupt handler is a really bad idea. Certainly you should not do this in a production USB driver or in environments where you really care about performance.

                          So if someone can offer a proper solution for the hack, it would be much appreciated. The hack is delineated by conditional compilation on ENABLE_DTXFSTS_POLLHACK in stm32_otgfsdev.c.

                          Greg
                        • erikvanderzalm@rocketmail.com
                          Hello Greg, I can connect to the board on OSX. But when a virtual machine is running it fails. The driver does not like a usb reset. (This is given by the
                          Message 12 of 29 , May 29, 2012
                            Hello Greg,

                            I can connect to the board on OSX.
                            But when a virtual machine is running it fails.

                            The driver does not like a usb reset. (This is given by the virtual machine to connect to windows)

                            It also fails when I disconnect the cable and reconnect it.

                            Best regards,

                            Erik

                            --- In nuttx@yahoogroups.com, "Meier Lorenz" <lm@...> wrote:
                            >
                            > Hi Greg,
                            >
                            > I can report success in that I managed to reproduce your results on Mac OS X 10.7, I have a working USB serial console. I can't make any comments on reliability and higher transmission speeds yet, but the basic typing and printing works.
                            >
                            > For convenience I made a similar hack as in the UART driver (with the difference that it is for now always active), see below. It kind of points towards the need of an additional abstraction layer between UART/USB drivers and the console? Or we add termios support to the USB CDC driver.
                            >
                            > The diff below is by now means a proposal, I just copy it here for reference in case somebody else want to hack along and wants a temporary solution for the current work-in-progress state.
                            >
                            > Again, thank you so much for this effort! I'll be testing with 4-6 boards in parallel this week and I'll keep you posted about our findings. I can't promise great code improvements though, mostly due to a lack of knowledge about the USB stack (and the current lack of time to properly read that up).
                            >
                            > Cheers,
                            > Lorenz
                            >
                            >
                            > diff --git a/nuttx/drivers/usbdev/cdcacm.c b/nuttx/drivers/usbdev/cdcacm.c
                            > index 97c9d7c..e6f38e9 100644
                            > --- a/nuttx/drivers/usbdev/cdcacm.c
                            > +++ b/nuttx/drivers/usbdev/cdcacm.c
                            > @@ -269,6 +269,11 @@ static uint16_t cdcacm_fillrequest(FAR struct cdcacm_dev_s *priv, uint8_t *reqbu
                            >
                            > while (xmit->head != xmit->tail && nbytes < reqlen)
                            > {
                            > + /* XXX Nasty, nasty hack: Prepend \r if \n is to be sent */
                            > + if (xmit->buffer[xmit->tail] == '\n') {
                            > + *reqbuf++ = '\r';
                            > + nbytes++;
                            > + }
                            > *reqbuf++ = xmit->buffer[xmit->tail];
                            > nbytes++;
                            >
                            >
                            >
                            > Am 28.05.2012 um 19:13 schrieb Gregory N:
                            >
                            >
                            >
                            > I just checked in a check that resolves all of the problems that I had with the USB CDC/ACM NSH console. I am still testing only on Linux so I don't know anything about OSX or Windows issues.
                            >
                            > The check-in contains two basic changes:
                            >
                            > 1. There was a busy/active status flag that was not being handled correctly when write requests were queued.
                            >
                            > 2. And we are missing some TxFIFO interrupts. Here is a nasty hack in the code now that allows it to work. I still don't understand the correct fix, but this hack allows the driver to work okay.
                            >
                            > The hack is to poll for TxFIFO interrupts. The original logic would setup the TxFIFO interrupt when there was insufficient space in the TxFIFO for the next packet. That did not work properly.. but replacing this with a poll seems to work fine.
                            >
                            > Putting a polling loop like this inside of an interrupt handler is a really bad idea. Certainly you should not do this in a production USB driver or in environments where you really care about performance.
                            >
                            > So if someone can offer a proper solution for the hack, it would be much appreciated. The hack is delineated by conditional compilation on ENABLE_DTXFSTS_POLLHACK in stm32_otgfsdev.c.
                            >
                            > Greg
                            >
                          • erikvanderzalm@rocketmail.com
                            Hello Greg, Adding the USBRST to the interrupt mask, and clearing the interrupt after the USBRST handler fixes the enumeration on OSX with virtual machine.
                            Message 13 of 29 , May 29, 2012
                              Hello Greg,

                              Adding the USBRST to the interrupt mask, and clearing the interrupt after the USBRST handler fixes the enumeration on OSX with virtual machine.


                              The following parts are the changed code.
                              ---------------------------------------
                              /* Enable the interrupts in the INTMSK */

                              regval = (OTGFS_GINT_RXFLVL | OTGFS_GINT_USBSUSP | OTGFS_GINT_ENUMDNE |
                              OTGFS_GINT_IEP | OTGFS_GINT_OEP | OTGFS_GINT_USBRST | regval);


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

                              /* USB reset interrupt */

                              if ((regval & OTGFS_GINT_USBRST) != 0)
                              {
                              usbtrace(TRACE_INTDECODE(STM32_TRACEINTID_DEVRESET), (uint16_t)regval);

                              /* Perform the device reset */

                              stm32_usbreset(priv);
                              usbtrace(TRACE_INTEXIT(STM32_TRACEINTID_USB), 0);
                              + stm32_putreg(OTGFS_GINT_USBRST, STM32_OTGFS_GINTSTS);
                              return OK;
                              }


                              --- In nuttx@yahoogroups.com, "erikvanderzalm@..." <erik@...> wrote:
                              >
                              > Hello Greg,
                              >
                              > I can connect to the board on OSX.
                              > But when a virtual machine is running it fails.
                              >
                              > The driver does not like a usb reset. (This is given by the virtual machine to connect to windows)
                              >
                              > It also fails when I disconnect the cable and reconnect it.
                              >
                              > Best regards,
                              >
                              > Erik
                              >
                              > --- In nuttx@yahoogroups.com, "Meier Lorenz" <lm@> wrote:
                              > >
                              > > Hi Greg,
                              > >
                              > > I can report success in that I managed to reproduce your results on Mac OS X 10.7, I have a working USB serial console. I can't make any comments on reliability and higher transmission speeds yet, but the basic typing and printing works.
                              > >
                              > > For convenience I made a similar hack as in the UART driver (with the difference that it is for now always active), see below. It kind of points towards the need of an additional abstraction layer between UART/USB drivers and the console? Or we add termios support to the USB CDC driver.
                              > >
                              > > The diff below is by now means a proposal, I just copy it here for reference in case somebody else want to hack along and wants a temporary solution for the current work-in-progress state.
                              > >
                              > > Again, thank you so much for this effort! I'll be testing with 4-6 boards in parallel this week and I'll keep you posted about our findings. I can't promise great code improvements though, mostly due to a lack of knowledge about the USB stack (and the current lack of time to properly read that up).
                              > >
                              > > Cheers,
                              > > Lorenz
                              > >
                              > >
                              > > diff --git a/nuttx/drivers/usbdev/cdcacm.c b/nuttx/drivers/usbdev/cdcacm.c
                              > > index 97c9d7c..e6f38e9 100644
                              > > --- a/nuttx/drivers/usbdev/cdcacm.c
                              > > +++ b/nuttx/drivers/usbdev/cdcacm.c
                              > > @@ -269,6 +269,11 @@ static uint16_t cdcacm_fillrequest(FAR struct cdcacm_dev_s *priv, uint8_t *reqbu
                              > >
                              > > while (xmit->head != xmit->tail && nbytes < reqlen)
                              > > {
                              > > + /* XXX Nasty, nasty hack: Prepend \r if \n is to be sent */
                              > > + if (xmit->buffer[xmit->tail] == '\n') {
                              > > + *reqbuf++ = '\r';
                              > > + nbytes++;
                              > > + }
                              > > *reqbuf++ = xmit->buffer[xmit->tail];
                              > > nbytes++;
                              > >
                              > >
                              > >
                              > > Am 28.05.2012 um 19:13 schrieb Gregory N:
                              > >
                              > >
                              > >
                              > > I just checked in a check that resolves all of the problems that I had with the USB CDC/ACM NSH console. I am still testing only on Linux so I don't know anything about OSX or Windows issues.
                              > >
                              > > The check-in contains two basic changes:
                              > >
                              > > 1. There was a busy/active status flag that was not being handled correctly when write requests were queued.
                              > >
                              > > 2. And we are missing some TxFIFO interrupts. Here is a nasty hack in the code now that allows it to work. I still don't understand the correct fix, but this hack allows the driver to work okay.
                              > >
                              > > The hack is to poll for TxFIFO interrupts. The original logic would setup the TxFIFO interrupt when there was insufficient space in the TxFIFO for the next packet. That did not work properly.. but replacing this with a poll seems to work fine.
                              > >
                              > > Putting a polling loop like this inside of an interrupt handler is a really bad idea. Certainly you should not do this in a production USB driver or in environments where you really care about performance.
                              > >
                              > > So if someone can offer a proper solution for the hack, it would be much appreciated. The hack is delineated by conditional compilation on ENABLE_DTXFSTS_POLLHACK in stm32_otgfsdev.c.
                              > >
                              > > Greg
                              > >
                              >
                            • Gregory N
                              ... That hack should not be necessary. Read the side effects under the nsh, 5. Using the USB console. If you switch to CONFIG_NSH_USBCONSOLE=n
                              Message 14 of 29 , May 29, 2012
                                > I can report success in that I managed to reproduce your results on Mac OS X 10.7, I have a working USB serial console. ...

                                > For convenience I made a similar hack as in the UART driver (with the difference that it is for now always active), see below. ...

                                That hack should not be necessary. Read the "side effects" under the nsh, 5. Using the USB console. If you switch to

                                CONFIG_NSH_USBCONSOLE=n
                                CONFIG_CDCACM_CONSOLE=y

                                Then you should have the behavior that you want with no hacks. Try it.

                                Greg
                              • Gregory N
                                Hi, Erik, ... Good find. That makes perfect sense. ... Hmmm.. but the final | regval) ... That doesn t belong there does it? regval does not contain
                                Message 15 of 29 , May 29, 2012
                                  Hi, Erik,

                                  > Adding the USBRST to the interrupt mask, and clearing the interrupt after the USBRST handler fixes the enumeration on OSX with virtual machine.

                                  Good find. That makes perfect sense.

                                  > The following parts are the changed code.
                                  > ---------------------------------------
                                  > /* Enable the interrupts in the INTMSK */
                                  >
                                  > regval = (OTGFS_GINT_RXFLVL | OTGFS_GINT_USBSUSP | OTGFS_GINT_ENUMDNE |
                                  > OTGFS_GINT_IEP | OTGFS_GINT_OEP | OTGFS_GINT_USBRST | regval);

                                  Hmmm.. but the final "| regval)" ... That doesn't belong there does it? regval does not contain anything meaningful at that point and could cause other unexptected interrupts to become enabled.

                                  This is what I just checked in. Let me know if I introduced any new issues.

                                  $ svn diff trunk/nuttx/arch/arm/src/stm32/stm32_otgfsdev.c
                                  Index: trunk/nuttx/arch/arm/src/stm32/stm32_otgfsdev.c
                                  ===================================================================
                                  --- trunk/nuttx/arch/arm/src/stm32/stm32_otgfsdev.c (revision 4782)
                                  +++ trunk/nuttx/arch/arm/src/stm32/stm32_otgfsdev.c (working copy)
                                  @@ -3443,6 +3443,7 @@

                                  stm32_usbreset(priv);
                                  usbtrace(TRACE_INTEXIT(STM32_TRACEINTID_USB), 0);
                                  + stm32_putreg(OTGFS_GINT_USBRST, STM32_OTGFS_GINTSTS);
                                  return OK;
                                  }

                                  @@ -5104,7 +5105,7 @@
                                  /* Enable the interrupts in the INTMSK */

                                  regval = (OTGFS_GINT_RXFLVL | OTGFS_GINT_USBSUSP | OTGFS_GINT_ENUMDNE |
                                  - OTGFS_GINT_IEP | OTGFS_GINT_OEP | regval);
                                  + OTGFS_GINT_IEP | OTGFS_GINT_OEP | OTGFS_GINT_USBRST);

                                  #ifdef CONFIG_USBDEV_ISOCHRONOUS
                                  regval |= (OTGFS_GINT_IISOIXFR | OTGFS_GINT_IISOOXFR);

                                  Greg
                                Your message has been successfully submitted and would be delivered to recipients shortly.