Hello Adam, Make sure you compile with debug info enabled and no optimization. Then, since you mentioned you have a Segger J-Link JTAG probe, I highly recommend you use Segger’s debugger Ozone (free J-Link probes) — you’ll be able to easily single-step and determine what’s going wrong…
Regards, -david > On Dec 22, 2019, at 7:57 PM, Gregory Nutt <spudan...@gmail.com> wrote: > > Check the configuration that you are using. What is the UART used in the > NuttX configuration for the serial console? What is the UART that connects > to the debug port? > > Do you have a jtag debugger? There should be instructions in the README > explaining how to single step into the OS. You should be able to determine > what is failing. Check the README for the SAMA5D3x-ek too. That is a more > mature configuration. > > So key places to set breakpoints: > > * When you reset, you shard be starting in __start. > * At the completion of low level debug, it will call nx_start() > * nx_start() will call up_initialize() to finish the hardware > initialization. > * When nx_start()finishes, it will call nsh_main() which should put up > the the NSH prompt > > Do you have networking enabled. You problem should strip down the > configuration so that as little as possible is enabled. Disable networking, > disable USB, etc. > > Greg > > On 12/22/2019 1:20 AM, Adam Feuer wrote: >> Ok, maybe more progress. I re-flashed the SPI NOR flash with new files from >> the linux4sam website. Now I can see the serial terminal on the debug port >> during boot. I can stop the boot process using U-Boot, and use U-Boot to >> load a nuttx.bin image. This process is suggested in the board README. >> >> But the system hangs when I execute the go command: >> >> U-Boot 2019.04-linux4sam_6.2 (Oct 25 2019 - 00:36:06 +0000) >> >> CPU: SAMA5D36 >> Crystal frequency: 12 MHz >> CPU clock : 528 MHz >> Master clock : 132 MHz >> DRAM: 256 MiB >> NAND: 256 MiB >> MMC: Atmel mci: 0, Atmel mci: 1 >> Loading Environment from NAND... OK >> In: serial@ffffee00 >> Out: serial@ffffee00 >> Err: serial@ffffee00 >> Net: >> Error: ethernet@f0028000 address not set. >> eth-1: ethernet@f0028000 >> Error: ethernet@f802c000 address not set. >> , eth-1: ethernet@f802c000 >> Hit any key to stop autoboot: 0 >> => mmc rescan >> => fatls mmc 0:1 >> .Spotlight-V100/ >> 1658616 nuttx >> 106620 nuttx.bin >> >> 2 file(s), 1 dir(s) >> >> => fatload mmc 0 0x20008000 nuttx.bin >> 106620 bytes read in 15 ms (6.8 MiB/s) >> => go 0x20008040 >> ## Starting application at 0x20008040 ... >> >> The README file says I should get a NuttX shell here instead of a hang. >> Does anyone have any ideas how to debug? >> >> cheers >> adam >> >> On Sat, Dec 21, 2019 at 9:17 PM Adam Feuer <a...@adamfeuer.com> wrote: >> >>> Hi, >>> >>> NuttX newbie here. >>> >>> I'm trying to load NuttX onto a SAMA5D3-Xplained board. I am trying to >>> follow the board's README file. I am using the Gnu ARM embedded toolchain >>> v9 >>> <https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads> >>> and a Segger J-Link Base JTAG debugger. I have an FTDI USB-serial adapter >>> connected to the board's debug serial port. I compiled NuttX with the >>> options suggested and debug symbols. My .config file is attached. >>> >>> Compiling seems to work and produces executables with debug symbols. I am >>> trying to find a way to boot the board. The README suggests several >>> options, one is via the debugger. I can boot into linux from an SD Card >>> using the D36 Linux4Sam instructions >>> <https://www.linux4sam.org/bin/view/Linux4SAM/Sama5d3XplainedMainPage> >>> and log in using the USB serial port, so I know the board works. >>> >>> I can debug using the Segger debugger halting and starting the CPU while >>> running Linux. The README says, boot the board, halt the CPU, load the >>> nuttx ELF binary, load the symbols. That seems to work. The Segger doesn't >>> support 'mon pc 0x20008040' like the README suggests, but lists the default >>> start point as 0x20008040... so I just do 'mon go'. I expect a NSH on the >>> debug serial port or the USB serial port, but there's no response either >>> places. >>> >>> My question is: >>> Should I be able to see a NSH console on the debug serial port? Or the USB >>> serial port? I don't see either devices when I look at the host system's >>> /dev/ directory. >>> >>> cheers >>> adam >>> >>> ps. Here's an excerpt of my gdb session: >>> >>> (gdb) mon halt >>> (gdb) load nuttx >>> Loading section .text, size 0x19f94 lma 0x20008000 >>> Loading section .ARM.exidx, size 0x8 lma 0x20021f94 >>> Loading section .data, size 0xe0 lma 0x20021f9c >>> Start address 0x20008040, load size 106620 >>> (gdb) file nuttx >>> A program is being debugged already. >>> Are you sure you want to change the file? (y or n) y >>> Load new symbol table from "nuttx"? (y or n) y >>> Reading symbols from nuttx... >>> (gdb) mon go >>> >>> >>> >>> -- >>> Adam Feuer <a...@adamfeuer.com> >>> Seattle, WA, USA >>> >>
