Does NSH wait for an interrupt from the UART to read data? If so, maybe the SAMA5D27 isn't interrupting. I tried to enable PIOD interrupts, since UART2 is on PIOD, but got some compilation errors. I'll look at it more tomorrow.
cheers adam On Thu, Dec 26, 2019 at 11:46 PM Adam Feuer <a...@starcat.io> wrote: > I got this to appear on UART2: > > NuttShell (NSH) >> Welcome to NuttX on the SAMA5D27-XULT :) >> nsh> >> > > But it doesn't accept any input. > > Here's the changes I had to do to make it get this far: > > > https://github.com/apache/incubator-nuttx/compare/master...adamfeuer:feature/sama5d27-xult-improvements > > So NSH seems to be able to send output, but not read input. Any ideas > about this...? > > I guess to prepare for the GiantBoard I should try to get the NSH console > onto one of the FlexComs... > > cheers > adam > > On Thu, Dec 26, 2019 at 6:42 PM Adam Feuer <a...@starcat.io> wrote: > >> Greg, >> >> Ok, I wired up an FTDI USB converter to UART0... PB27 (UTXD0) and PB26 >> (UTXR0). That also didn't work. Hmmmm. >> >> I'll think about it some more. Thanks again for the help. >> >> cheers >> adam >> >> On Thu, Dec 26, 2019 at 6:30 PM Gregory Nutt <spudan...@gmail.com> wrote: >> >>> >>> > Ok, I used the menuconfig system to set the serial console to UART1, >>> 57600 >>> > baud rate. >>> > >>> > The system boots, hits the nsh_main breakpoint, I can continue to >>> fputs, >>> > and then if I continue, then break, the system stops in the idle loop. >>> So >>> > it seems like it's running, but the serial console isn't working, at >>> least >>> > on the DEBUG port. If I boot into Linux, I can get a console login on >>> the >>> > DEBUG port at 115200 baud. >>> > >>> > When I boot NuttX, I don't get any response from the serial terminal. >>> I can >>> > see I'm transmitting because the lights on my FTDI console blink. >>> > >>> > The SAMA5D27 pinout definitely says that UTXD1 is UART1; and that's >>> what >>> > the embedded debugger is connected to... so I'm confused. >>> > >>> > Any more ideas? >>> >>> Not really. >>> >>> It is in the IDLE loop because there is nothing to do. This is a >>> symptom of UART1 no working as it is supposed to. There are a few >>> things to check. Usually the problem is with pin configuration or with >>> jumper settings >>> >>> First, check the jumpers. In 5.4.14 it looks like you would need: >>> >>> Pin J9 *NOT* tied to ground >>> Jumper JP1 *NOT* installed >>> Jumper JP2 DEBUG_DIS ON >>> >>> Then double check the pin configurations. >>> >>> In the schematic, I see that the connection to the CDC/ACM VCOM is via >>> DBGU_UXTD1_PD3 and >>> DBGU_URXD1_PD2. >>> >>> The UART1 pins must defined in the board.h file. I see >>> >>> #define PIO_UART1_RXD PIO_UART1_RXD_1 >>> #define PIO_UART1_TXD PIO_UART1_TXD_1 >>> >>> And if I look in arch/arm/src/sama5/hardware/_sama5d2x_pinmap.h, I see >>> >>> PIO_UART1_RXD_1 is pin PD2 >>> PIO_UART1_TXD_1 is pin PD3 >>> >>> So that looks okay. >>> >>> You can try UART2 if you like. Sometimes EDGB VCOM interfaces are >>> mysterious. On UART2 you could at least look at what is the TX pin to >>> see if anything is coming out. Careful with pin configurations! >>> >>> Greg >>> >>> >> >> -- >> Adam Feuer <a...@starcat.io> >> > > > -- > Adam Feuer <a...@starcat.io> > -- Adam Feuer <a...@starcat.io>
