Hi all, Wow... Masayuki, excellent. I did not even have a chance to send in the more detailed information that Petro requested.
I just tested the latest from the repo and it now works and I have a nsh> prompt on the BBBW. Thank you all for the help and excellent response. Petro: I'm using a Raspberry Pi 4B for my development platform. So gcc-arm-none-eabi is my compiler/toolchain version gcc (Raspbian 8.3.0-6+rpi1) 8.3.0. Does that make sense? Alan: Thanks for the suggestion of the cheaper board... we are going to consider it. We picked the BBBW as it can also run Linux so it can be used in more ways than just running a RTOS for the one course. However small cheap boards is an attractive option. I'm wading through trying to understand the options for the STM32* boards, what accessories are needed, etc. If anyone has a good suggestion or list to make up a "complete package" I'd appreciate it. This is for a Computer Science course. As I know little about the STM32 boards I'm not sure which are the best models, what extra cables, etc. I need. But I'll keep reading. Cheers, Merlin. On Tue, Feb 18, 2020 at 8:03 PM Ishikawa, Masayuki (SHES) < masayuki.ishik...@sony.com> wrote: > Hi, All, > > I found root cause of this issue and just fixed. > Please see https://github.com/apache/incubator-nuttx/pull/303 > > Regards, > Masayuki > > On 2020/02/18 21:03, "Petro Karashchenko" <petro.karashche...@gmail.com> > wrote: > > Hello Merlin, > > Please send me compiler/toolchain version that you are using. > Also please attach produced binary and map file. > > I will try to reproduce your case locally. > > Some time ago when I was bringing up BBB I had similar issue, but at > that > point I considered it a compiler bug, because switching to -O0 "cured" > the > case and after I upgraded compiler I have never met this issue again. > > Regards, > Petro > > вт, 18 лют. 2020 о 01:40 Ishikawa, Masayuki (SHES) < > masayuki.ishik...@sony.com> пише: > > > Hi, > > > > > arm_dataabort: Data abort. PC: 8a010e64 DFAR: 8a019b04 DFSR: > 00000001 > > > > According to the Arm Technical Reference Manual, DFSR: 00000001 > means that > > alignment fault happened at PC:8a010e64 when accessing data at DFAR: > > 8a019b04. > > > > > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0464d/BABFFDFD.html > > > > You can find the code with the following commands. > > NOTE: you need to add CONFIG_DEBUG_SYMBOLS=y to defconfig > > > > $ arm-none-eabi-addr2line -afp -e nuttx 8a010e64 > > $ arm-none-eabi-objdump -S nuttx | grep 8a010e64 > > > > I think 8a019b04 is already aligned in 4bytes, so perhaps 8bytes > access > > happened. > > > > On 2020/02/17 15:14, "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/ > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > Cheers, > > Merlin. > > > > > > > > >
