From a7dc83b70dcae37535b51f581c47f6d126ed4de8 Mon Sep 17 00:00:00 2001 From: Gregory Nutt Date: Thu, 27 Apr 2017 09:26:12 -0600 Subject: [PATCH] Update a README file. --- configs/nucleo-f072rb/README.txt | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/configs/nucleo-f072rb/README.txt b/configs/nucleo-f072rb/README.txt index 3f4eecaabf..de1713e5ab 100644 --- a/configs/nucleo-f072rb/README.txt +++ b/configs/nucleo-f072rb/README.txt @@ -8,12 +8,42 @@ Nucleo-F072RB README Contents ======== + - Status - Nucleo-64 Boards - LEDs - Buttons - Serial Console - Configurations +Status +====== + 2017-04-27: There are many problems. On start up, I have to reset + several times before I get NSH prompt (or parts of it). Apparently the + STM32 is either hanging (perhaps in clockconfig()) or perhaps it has + taken a hard fault before it is able to generate debug output? + + There are many hardfaults during initial serial output. This change + seems to eliminate those hardfaults: + + @@ -2163,7 +2163,7 @@ static void stm32f0serial_txint(FAR struct uart_dev_s *dev, bool enable) + * interrupts disabled (note this may recurse). + */ + + - uart_xmitchars(dev); + +// uart_xmitchars(dev); + #endif + } + else + + Which implies that the hardfaults are due to runaway recursion in the + serial driver? This suggest some error in either determining when there + is TX data available or in disabling TX interrupts. + + But this not a solution. Even without the hard faults, it may hang + attempting to output the NSH greeting and prompt or hang unable to + receive input. These symptoms suggest some issue with TX and RX + interrupt handling. + Nucleo-64 Boards ================