This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Data abort when running usb_host_msc on Beaglebone Black

Hello everyone! I'm trying to get the usb_host_msc example to run on the Beaglebone Black. The example works fine until I try to issue the ls, cat or cd commands. Any of those end up triggering a Data Abort exception somewhere inside the disk_status function. Since StarterWare simply places an endless loop as a Data Abort handler, I wrote a small function which examines the instructions around the one pointed at by LR and prints their opcodes using ConsoleUtilsPrintf. The results were surprising: the instruction pointed at by LR, as well as the 3 instructions that preceeded it showed junk opcodes, and so did the 7 or so that followed it.

I'm compiling with the Linaro gcc-arm-none-eabi-4_7-2012q4 recommended by the Wiki and the project Makefiles. I'm recording the app binaries into an SD card and booting using U-Boot. Here's the script I'm using for preparing the SD card (it was originally written by Ben Gras to record RTEMS executables):

# we store all generated files here.
TMP_BASE_NAME=tmp_sdcard_dir
TMPDIR=$TMP_BASE_NAME.$$

FATIMG=$TMPDIR/bbxm_boot_fat.img
OFFSET=2048
FATSIZE_KB=2880
FATSIZE=`expr $FATSIZE_KB \* 2`
SIZE=`expr $FATSIZE + $OFFSET`
UENV=uEnv.txt

rm -rf $TMPDIR
mkdir -p $TMPDIR

if [ $# -ne 2 ]
then	echo "Usage: $0 <executable> <image name>"
	exit 1
fi
executable=$1

app=app.img

if [ ! -f "$executable" ]
then	echo "Expecting executable as arg; $executable not found."
	exit 1
fi

set -e

IMG=$2

# Make an empty image
dd if=/dev/zero of=$IMG bs=512 seek=$SIZE count=1
# Make an ms-dos FS image
rm -f $FATIMG
export MTOOLSRC=$TMPDIR/mtools-conf
echo "drive a:
       file=\"$FATIMG\"
       fat_bits=16
" >$MTOOLSRC
mformat -C -f $FATSIZE_KB a:

# Prepare the executable.
base=`basename $executable`
arm-none-eabi-objcopy $executable -O binary $TMPDIR/$base.bin
gzip -9 $TMPDIR/$base.bin
mkimage -A arm -T standalone -a 0x80000000 -e 0x80000000 -n APP -d $TMPDIR/$base.bin.gz $TMPDIR/$app
echo "setenv bootdelay 5
uenvcmd=run boot
boot=fatload mmc 0 0x80800000 $app ; bootm 0x80800000" >$TMPDIR/$UENV

# Copy the uboot and app image onto the FAT image
mcopy -bsp -i $FATIMG $MLO_PATH/MLO ::MLO
mcopy -bsp -i $FATIMG $UBOOT_PATH/u-boot.img ::u-boot.img
mcopy -bsp -i $FATIMG $TMPDIR/$app ::$app
mcopy -bsp -i $FATIMG $TMPDIR/$UENV ::$UENV

# Just a single FAT partition (type C) that uses all of the image
partition $IMG $OFFSET 'c:0*+'

# Put the FAT image into the SD image
dd if=$FATIMG of=$IMG seek=$OFFSET

# cleanup
rm -rf $TMP_BASE_NAME.*

echo "Result is in $IMG."

I finish by recording the resulting image to the SD card using dd.
Now, the weird thing is that this only happens with Rev. C boards. I tried doing this on a Rev A5C and got a Prefetch Abort inside U-Boot.
Any help would be appreciated. Thanks a lot!

  • I've been doing some more testing. Apparently, the MLO/U-Boot I'm copying into the SD card isn't actually being used since it's using the ones from the onboard eMMC (I actually deleted them from the SD card and it's still booting). Now, I read online that by holding the S2 button as the board is powering up I could actually force it to boot from the SD card instead of the eMMC. The weird thing is that every time I try to do that, the LEDs will stay off and the console will only output the letter 'C' many times. This happens the newest MLO/U-Boot, and it also happened when I tested the beagleboneblack-save-emmc files provided here.


    I'm pretty sure it's not a faulty SD card because I tested it with two different cards and both had the same output.

    EDIT: I've managed to sort out the 'CCC..' issue by formatting the SD card using gparted, marking the FAT32 partition with the 'boot' flag, and manually copying the MLO, u-boot.img, uEnv.txt and app files. However, as soon as I boot from the SD card U-Boot will complain about a missing zImage and jump back to the eMMC (booting the default Debian image). Oddly enough, the script I posted before created a FAT32 partition which had the 'boot' flag enabled, yet it showed the 'CCC..' output.


    I also tried to compile the 'bootloader' project and generate a binary image as indicated here. I used both arm-none-eabi-objcopy and tiimage to generate the 'MLO' file from boot.out, and 'app' from usb_host_msc.out, after which I copied both to the SD card. When trying to boot I saw no output whatsoever, not even the 'CCC..' thing from before. The same thing happens if I compile MLO/U-Boot from source.

  • The USB_msc_out example seems to work for me. Getting the card formatted correctly is an important step, but I think you have already done that. Here's what I did:

    Step 1

    - Import the bootloader CCS project C:\ti\AM335X_StarterWare_02_00_01_01\build\armv7a\cgt_ccs\am335x\beaglebone\bootloader into CCS and build.

    - This created ti_boot.bin in C:\ti\AM335X_StarterWare_02_00_01_01\binary\armv7a\cgt_ccs\am335x\beaglebone\bootloader\Release_MMCSD.

    - Placed ti_boot.bin on SD card and renamed MLO.

    Step 2

    - Import C:\ti\AM335X_StarterWare_02_00_01_01\build\armv7a\cgt_ccs\am335x\beaglebone\usb_host_msc into CCS and build.

    - This created usb_host_msc_ti.bin in C:\ti\AM335X_StarterWare_02_00_01_01\binary\armv7a\cgt_ccs\am335x\beaglebone\usb_host_msc\Release.

    - Place usb_host_msc_ti.bin on SD card and rename app.

    Step 3

    - Insert SD card into BBB and put a USB stick in the USB host port.

    - Connect a FTDI cable to the  JI header and open a terminal emulation program for that COM port.

    - While holding down the S2 button, apply power to the board and release S2.

    - The example should start-up as in the below screenshot.

    If you still have problems, it might be related to the SD card formatting.

    Lali

  • Thanks for your answer.

    When I compiled the bootloader project (either with CCS or gcc), I didn't see a *_ti.bin file. Instead, I saw a .out file from which I generated the binary using either objcopy or tiimage.

    Other than that, I followed the exact same steps as you did, and didn't see any output on the console.

  • Does the bootloader CCS project trigger the post-build steps like this? This should generate the .bin

  • Here's the CCS output:

    **** Build of configuration Release for project usb_host_msc ****
    
    /opt/ti/ccsv6/utils/bin/gmake -k -j -s all 
    Building file: /home/martin/Documents/AM335X_StarterWare_02_00_01_01/third_party/fatfs/src/ff.c
    Invoking: ARM Compiler
    Finished building: /home/martin/Documents/AM335X_StarterWare_02_00_01_01/third_party/fatfs/src/ff.c
     
    Building target: ../../../../../../../binary/armv7a/cgt_ccs/am335x/beaglebone/usb_host_msc/Release/usb_host_msc.out
    Invoking: ARM Linker
    <Linking>
    warning #10366-D: automatic library build: using library
       "/opt/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.4/lib/rtsv7A8_A_le_n_eabi.lib"
       for the first time, so it must be built.  This may take a few minutes.
    Finished building target: ../../../../../../../binary/armv7a/cgt_ccs/am335x/beaglebone/usb_host_msc/Release/usb_host_msc.out
     
    
     
    
    **** Build Finished ****

    While it doesn't seem to be performing the post-build steps, I remember that the first time I tried to build using CCS I had to manually remove the '.bat' extension from tiobj2bin in the CCS text box you showed.


    Just in case, I tried using tiobj2bin to generate MLO and app, and I still see no output.

  • The CCC..shows up when a bootloader cannot be found. If you remove the SD card, hold down S2 and apply power, then release S2, do you get CCC...on the J1 console?

    This essentially forces the BBB to look for the MLO in the SD card, but since the SD is missing, it will print the CCC.. on the console.

    If that is the case, then there is something wrong with your MLO image or your SD card formatting. Can you try formatting the SD card on a Linux machine?

    Lali
  • It seems like you didn't read any of my posts, since I explained I managed to get rid of the 'CCC..' by doing the S2 button thing you just told me to. I'm doing all of my development on an Ubuntu 14.04 machine; I'm using CCS just to check if it's not an issue with my gcc.
  • I did read your posts. I mentioned the CCC. . procedure again since you mentioned on your subsequent post

    "When trying to boot I saw no output whatsoever, not even the 'CCC..' thing from before"

    I'm trying to get a hold of what exactly you are seeing so that I can better assist you, since you said that you had followed the exact procedure as what had been suggested.