Hi Merlin, On 2/17/20, Merlin Hansen <heymerlinhan...@gmail.com> wrote: > Hi, > > I'm new to NuttX and BBBW, any assistance would be appreciated. > > I followed Alan Assis' blog post on how to get NuttX running on the > BeagBone Black board. I have the wireless version but I don't know if that > is causing my issue. > https://acassis.wordpress.com/2019/01/09/compiling-nuttx-to-beagleboneblack/ >
Nice to know my post was useful for you, at least as a starting point. I received your email, but let's to keep the discussion open here, then it could be useful for other people. > The first think I noticed is that my nuttx.bin file is about 1/2 the size > of Alan's. In looking at the configuration, I only checked/changed what > the tutorial suggested and there really is not much else configured by > default. When I load and launch the code I get an immediate assert error > due to a seg fault. > What gcc toolchain are you using? Normally people use the gcc toolchain offer by ARM or the toolchain that comes from Debian/Ubuntu repositories. I'm using the later and don't have issues with it. In the past these toolchain were prone to fail NuttX compilation. > U-Boot SPL 2017.05-rc1-00002-g35aecb22fe (Apr 05 2017 - 16:51:58) > Trying to boot from MMC2 > > > U-Boot 2017.05-rc1-00002-g35aecb22fe (Apr 05 2017 - 16:51:58 -0500), Build: > jenkins-github_Bootloader > -Builder-541 > > CPU : AM335X-GP rev 2.1 > I2C: ready > DRAM: 512 MiB > Reset Source: Global warm SW reset has occurred. > Reset Source: Power-on reset has occurred. > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > Using default environment > > <ethaddr> not set. Validating first E-fuse MAC > BeagleBone Black: > Model: BeagleBoard.org BeagleBone Black Wireless: > BeagleBone: cape eeprom: i2c_probe: 0x54: > BeagleBone: cape eeprom: i2c_probe: 0x55: > BeagleBone: cape eeprom: i2c_probe: 0x56: > BeagleBone: cape eeprom: i2c_probe: 0x57: > Net: eth0: MII MODE > Could not get PHY for cpsw: addr 0 > cpsw > Press SPACE to abort autoboot in 2 seconds > => load mmc 0 0x8a000000 nuttx.bin > reading nuttx.bin > 97000 bytes read in 11 ms (8.4 MiB/s) > => go 0x8A000000 > ## Starting application at 0x8A000000 ... > arm_dataabort: Data abort. PC: 8a010e64 DFAR: 8a019b04 DFSR: 00000001 > up_assert: Assertion failed at file:armv7-a/arm_dataabort.c line: 175 task: > Idle Task > up_registerdump: R0: 8a01792d 8a019b68 00000000 fffffffe 00000000 00000000 > 8a019b30 00000000 > up_registerdump: R8: 00000000 9df2ded8 9ffa12e8 00000000 016e3664 8a019b04 > 8a010ca0 8a010e64 > up_registerdump: CPSR: 60000113 > up_dumpstate: Current sp: 8a0199f8 > up_dumpstate: Interrupt stack: > up_dumpstate: base: 8a0182ec > up_dumpstate: size: 00000800 > up_dumpstate: User stack: > up_dumpstate: base: 8a019b94 > up_dumpstate: size: 00000400 > up_dumpstate: ERROR: Stack pointer is not within the interrupt stack > up_stackdump: 8a017ae0: 00000001 0000003f 05445101 08082882 00000000 > 00000000 00000000 00000000 > > I downloaded the latest from bitbucket... version 8.2. > The good news is that NuttX is reporting the error, then you have info to search for the issue. Try to discovery which functions are at position 8a010ca0 8a010e64 (LR and PC), this way you will have a tip about where is issues is happening. > I have not done much to troubleshoot this as I am, admittedly, a little > lost. I did take a quick look at the code to get an idea where it was seg > faulting but it is not something obvious to me. > You can start analyzing the hardfault. > I'm currently assisting one of my faculty in evaluating the BBBW and NuttX > to be used in a RTOS course he is teaching. The idea is that if we can get > NuttX up and running on the BBBW then we can proceed with purchasing enough > boards for the class. > > Any assistance on determining if this is something I can correct would be > very much appreciated. > This is a nice idea Merlin, but there are other low cost boards with better NuttX support. In my video tutorials at NuttX Channel I started using the BluePill board (a STM32F103 board for less than U$ 2) and the moved to STM32F4Discovery. I think you could consider these options. BR, Alan
