Problem using USART Console and USB-CDC together on STM32F4 Discovery
Hello, I am trying to enable USB CDC support with base NSH Serial in a STM32F4 Discovery board. When I build using usbnsh configuration, it works. When I build using nsh configuration (in my case, replacing USART2 to USART1), it works. Now, when I try to add USB CDC support in nsh configuration, I cannot see the nsh prompt on the serial anymore. And USB is not initializing either. Here is the defconfig file that I am using. Am I missing something? # CONFIG_ARCH_FPU is not set # CONFIG_NSH_ARGCAT is not set # CONFIG_NSH_CMDOPT_HEXDUMP is not set # CONFIG_NSH_CMDPARMS is not set # CONFIG_STM32_CCMEXCLUDE is not set CONFIG_ARCH="arm" CONFIG_ARCH_BOARD="stm32f4discovery" CONFIG_ARCH_BOARD_STM32F4_DISCOVERY=y CONFIG_ARCH_BUTTONS=y CONFIG_ARCH_CHIP="stm32" CONFIG_ARCH_CHIP_STM32=y CONFIG_ARCH_CHIP_STM32F407VG=y CONFIG_ARCH_STACKDUMP=y CONFIG_BOARD_LATE_INITIALIZE=y CONFIG_BOARD_LOOPSPERMSEC=16717 CONFIG_BUILTIN=y CONFIG_CDCACM=y CONFIG_EXAMPLES_HELLO=y CONFIG_FS_PROCFS=y CONFIG_HAVE_CXX=y CONFIG_HAVE_CXXINITIALIZE=y CONFIG_INTELHEX_BINARY=y CONFIG_MAX_TASKS=16 CONFIG_MM_REGIONS=2 CONFIG_NFILE_DESCRIPTORS=8 CONFIG_NSH_BUILTIN_APPS=y CONFIG_NSH_FILEIOSIZE=512 CONFIG_NSH_LINELEN=64 CONFIG_NSH_READLINE=y CONFIG_PREALLOC_TIMERS=4 CONFIG_RAM_SIZE=114688 CONFIG_RAM_START=0x2000 CONFIG_RAW_BINARY=y CONFIG_RR_INTERVAL=200 CONFIG_SCHED_WAITPID=y CONFIG_SDCLONE_DISABLE=y CONFIG_START_DAY=6 CONFIG_START_MONTH=12 CONFIG_START_YEAR=2011 CONFIG_STM32_DMA1=y CONFIG_STM32_JTAG_SW_ENABLE=y CONFIG_STM32_OTGFS=y CONFIG_STM32_PWR=y CONFIG_STM32_SPI1=y CONFIG_STM32_USART1=y CONFIG_SYSTEM_CDCACM=y CONFIG_SYSTEM_NSH=y CONFIG_USART1_RXBUFSIZE=128 CONFIG_USART1_SERIAL_CONSOLE=y CONFIG_USART1_TXBUFSIZE=128 CONFIG_USBDEV=y CONFIG_USER_ENTRYPOINT="nsh_main" Best regards, Flavio -- Flavio de Castro Alves Filho flavio.al...@gmail.com Twitter: http://twitter.com/#!/fraviofii LinkedIn profile: www.linkedin.com/in/flaviocastroalves
Re: Tasks software watchdog timer
Hi Sara, thank you very much for this detailed explanation! I am still thinking of what is the best approach for our application, that is simple and reliable enough. Nevertheless, I see that there is a general interest in this feature. May I propose again to add this in the kernel itself? So the scheduler can directly monitor the various tasks? Or is there any good reason not to? Στις Πέμ, 18 Μαρ 2021 στις 2:38 μ.μ., ο/η Sara da Cunha Monteiro de Souza < saramonteirosouz...@gmail.com> έγραψε: > Hi Fotis, > > I think I was very brief on my answer. > So I decided to draw this draft to detail the watcher/watched example > and then you decide if it is suitable for you or not. > Note: Unfortunately, I am not an expert on signaling nor > scheduling to foresee all possible scenarios here and answer your > questions. > > In the below draft, you can see that we have one thread on one side, the > watcher. > And 4 threads on the other side, the watched tasks. > Any task who wants to be watched, can get the pid and the signal number of > the watcher > through a file created upon a mounted pseudo filesystem. > After getting it, the task may send a signal with an argument that > represents a request > code for one of the following actions: > - Subscribe to be watched. > - Unsubscribe to be watched. > - Feed the dog. > From the moment a task is subscribe, it needs to periodically send a > signal with > the feed the dog request to let the watcher know it is alive. > Once it is unsubscribed, the watcher no longer takes care of it. > > On the watcher side, it has a signal handler to receive this signal and > perform > the actions like: subscribe one more task in its internal list. > And it previous configure a hardware watchdog timer to trigger an interrupt > handler at timeout. > This interrupt handler signals *another* signal handler that will get all > the subscribed > tasks, see which of them sent a signal to feed the dog in the last "cyle" > and it will > print all the offending tasks. > > > Em qua., 17 de mar. de 2021 às 20:31, Gregory Nutt > escreveu: > >> >> > I would like to ask, are there cases where the timer may not fire? >> > Is it guaranteed to fire, for example, if the thread is in a dead lock, >> >> The signal will be delivered to some thread in the task group, so in >> that sense it will "fire". However, it may be the case that the the >> dead locked thread cannot respond to the signal. There are many >> possible scenarios. >> >> If you setup a signal handler to run and the task is deadlocked waiting >> on a semaphore that receives the signal, the semaphore wait will return >> EINTR and the signal handler will run. But, I can imagine other cases >> where the task might not respond to the signal. >> >> In a multi-threaded task group, it may may not be the waiting thread >> that receives the signal, however. Multi-threaded signal delivery is >> complex and non-obvious. >> >> > or if a higher priority thread has caused CPU starvation, or similar >> cases? >> >> Certainly the signal handling will typically pend and be delayed. POSIX >> requires that signal events be queued only at least one deep; NuttX >> queues signal action events but not other signal events (as I recall). >> The behavior will depend on the sigprocmask and might not pend at all! >> >> Signal handling is complex and this was written from my recollection >> which may be flawed. >> >>
Re: Problem using USART Console and USB-CDC together on STM32F4 Discovery
Updating: * with the great help from Allan, I could verify that that using usart2 it works fine - stm32f4discovery uses usart2 as console - my board, similar to stm32f4discovery, uses usart1 as console * there is a conflict between the usart1 pins and usb device for stm32f4discovery configuration in nuttx - according to the kit, the same pins (pa9 and pa10) are used for USB host device detection What I have done: * replaced the vbus pin (pa9) to another not used pin * searched for references about pa10 on the source code, and I couldn't find anything For now, I can see the nuttshell prompt on the serial, but it is not accepting inputs from the keyboard. And USB device is not working. PC is not detecting the device. The debug outputs are all turned on, and it shows only the ABC. I am new on nuttx and I would some advice on how to debug this early stage initialization of the software, to identify what's running wrong. Best regards, Flavio Em sáb, 20 de mar de 2021 08:11, Flavio Castro Alves Filho < flavio.al...@gmail.com> escreveu: > Hello, > > I am trying to enable USB CDC support with base NSH Serial in a > STM32F4 Discovery board. > > When I build using usbnsh configuration, it works. > When I build using nsh configuration (in my case, replacing USART2 to > USART1), it works. > > Now, when I try to add USB CDC support in nsh configuration, I cannot > see the nsh prompt on the serial anymore. And USB is not initializing > either. > > Here is the defconfig file that I am using. Am I missing something? > > # CONFIG_ARCH_FPU is not set > # CONFIG_NSH_ARGCAT is not set > # CONFIG_NSH_CMDOPT_HEXDUMP is not set > # CONFIG_NSH_CMDPARMS is not set > # CONFIG_STM32_CCMEXCLUDE is not set > CONFIG_ARCH="arm" > CONFIG_ARCH_BOARD="stm32f4discovery" > CONFIG_ARCH_BOARD_STM32F4_DISCOVERY=y > CONFIG_ARCH_BUTTONS=y > CONFIG_ARCH_CHIP="stm32" > CONFIG_ARCH_CHIP_STM32=y > CONFIG_ARCH_CHIP_STM32F407VG=y > CONFIG_ARCH_STACKDUMP=y > CONFIG_BOARD_LATE_INITIALIZE=y > CONFIG_BOARD_LOOPSPERMSEC=16717 > CONFIG_BUILTIN=y > CONFIG_CDCACM=y > CONFIG_EXAMPLES_HELLO=y > CONFIG_FS_PROCFS=y > CONFIG_HAVE_CXX=y > CONFIG_HAVE_CXXINITIALIZE=y > CONFIG_INTELHEX_BINARY=y > CONFIG_MAX_TASKS=16 > CONFIG_MM_REGIONS=2 > CONFIG_NFILE_DESCRIPTORS=8 > CONFIG_NSH_BUILTIN_APPS=y > CONFIG_NSH_FILEIOSIZE=512 > CONFIG_NSH_LINELEN=64 > CONFIG_NSH_READLINE=y > CONFIG_PREALLOC_TIMERS=4 > CONFIG_RAM_SIZE=114688 > CONFIG_RAM_START=0x2000 > CONFIG_RAW_BINARY=y > CONFIG_RR_INTERVAL=200 > CONFIG_SCHED_WAITPID=y > CONFIG_SDCLONE_DISABLE=y > CONFIG_START_DAY=6 > CONFIG_START_MONTH=12 > CONFIG_START_YEAR=2011 > CONFIG_STM32_DMA1=y > CONFIG_STM32_JTAG_SW_ENABLE=y > CONFIG_STM32_OTGFS=y > CONFIG_STM32_PWR=y > CONFIG_STM32_SPI1=y > CONFIG_STM32_USART1=y > CONFIG_SYSTEM_CDCACM=y > CONFIG_SYSTEM_NSH=y > CONFIG_USART1_RXBUFSIZE=128 > CONFIG_USART1_SERIAL_CONSOLE=y > CONFIG_USART1_TXBUFSIZE=128 > CONFIG_USBDEV=y > CONFIG_USER_ENTRYPOINT="nsh_main" > > > Best regards, > > Flavio > > -- > Flavio de Castro Alves Filho > > flavio.al...@gmail.com > Twitter: http://twitter.com/#!/fraviofii > LinkedIn profile: www.linkedin.com/in/flaviocastroalves >
Re: Problem using USART Console and USB-CDC together on STM32F4 Discovery
On 3/20/21, Flavio Castro Alves Filho wrote: > Updating: > > * with the great help from Allan, I could verify that that using usart2 it > works fine > - stm32f4discovery uses usart2 as console > - my board, similar to stm32f4discovery, uses usart1 as console > > * there is a conflict between the usart1 pins and usb device for > stm32f4discovery configuration in nuttx > - according to the kit, the same pins (pa9 and pa10) are used for USB > host device detection > > What I have done: > > * replaced the vbus pin (pa9) to another not used pin > * searched for references about pa10 on the source code, and I couldn't > find anything > > For now, I can see the nuttshell prompt on the serial, but it is not > accepting inputs from the keyboard. > > And USB device is not working. PC is not detecting the device. > Of course, you need to run in the NuttX terminal: nsh> sercon DCD register : sercon: Registering CDC/ACM serial driver sercon: Successfully registered the CDC/ACM serial driver stm32_usbsuspend: resume: 0 nsh> ls /dev /dev: console null ttyACM0 ttyS0 nsh> After doing it the USB CDC/ACM will be detected. BR, Alan
Re: Problem using USART Console and USB-CDC together on STM32F4 Discovery
Hello Allan, I believe that rx pin from usart1 (PA10) is not yet operational. I could not find in code why. Best regards, Flavio Em sáb, 20 de mar de 2021 14:18, Alan Carvalho de Assis escreveu: > On 3/20/21, Flavio Castro Alves Filho wrote: > > Updating: > > > > * with the great help from Allan, I could verify that that using usart2 > it > > works fine > > - stm32f4discovery uses usart2 as console > > - my board, similar to stm32f4discovery, uses usart1 as console > > > > * there is a conflict between the usart1 pins and usb device for > > stm32f4discovery configuration in nuttx > > - according to the kit, the same pins (pa9 and pa10) are used for USB > > host device detection > > > > What I have done: > > > > * replaced the vbus pin (pa9) to another not used pin > > * searched for references about pa10 on the source code, and I couldn't > > find anything > > > > For now, I can see the nuttshell prompt on the serial, but it is not > > accepting inputs from the keyboard. > > > > And USB device is not working. PC is not detecting the device. > > > > Of course, you need to run in the NuttX terminal: > > nsh> sercon > DCD register : > sercon: Registering CDC/ACM serial driver > sercon: Successfully registered the CDC/ACM serial driver > stm32_usbsuspend: resume: 0 > > nsh> ls /dev > /dev: > console > null > ttyACM0 > ttyS0 > nsh> > > After doing it the USB CDC/ACM will be detected. > > BR, > > Alan >
