Application Notes

1. Beginner's shopping list: You start from scratch and you are yet undecided on the evaluation hardware
   
2. First time programming and production testing
   
3. Remote control and Firmware maintenance of a webcam, IP phone, or similar embedded product
4. uClinux hardware driver development
   

1. Loading U-Boot into a virgin flash on BF537 STAMP or EZKIT
2. Loading and debugging uClinux with bfin-elf-gdb
3. Flash programming via GDB script (bfloader)
   

Note: For a list of up to date application notes and examples, please see forum.

1. Beginner's shopping list

• EZKIT BF-533 with VDSP (restricted features, additional costs implied for serious development)

• Recommended boards: Bluetechnix CM-BF527, CM-BF537 (www.bluetechnix.at), STAMP BF537 (blackfin.uclinux.org) and the popular SRV1 robot camera board (www.surveyor.com)
• GNU tools from blackfin.uclinux.org
• ICEbear and software tools

2. First time programming and production testing

• Write and read to/from all memory locations, including MMR registers (Peripheral access)
  
• Read and write CPU registers
• Stop and go, single stepping.
  

3. Remote control and Firmware maintenance

The ICEbear also allows to eavesdrop on a running system without interception (emulation) using a backend part (libbfpeek) on the target. This basically allows external monitoring of the running system under certain restrictions (possible loss of realtime functionality). For example, the filter coefficients of a fourier transform filter can be repeatedly plotted or even changed while the system is running. Or, if all UART interfaces are used, you can route the console through the JTAG port and chat with your hardware via a shell.
Assume, you are producing the hardware and software for a webcam solution. There are again three possible szenarios:

a) You are able to update the firmware via Ethernet, using a boot loader and an In-System-Programmable solution:

b) You want to allow an authorized dealer/technician to fully reprogram the firmware:

c) You want complete remote control, programming and debugging of a possible webcam development kit. Or, a technician might need to maintain or debug an installed device in place using a laptop.

4. uClinux hardware driver development

"Advanced" HOWTOs

1. Loading U-Boot into a virgin flash on BF537 STAMP or EZKIT

1. Connect a serial cable to the board and configure your terminal program with 57600 bps, 8N1.
   Make sure the boot mode is set to '0' on SW16.
2. Start gdbproxy:
   gdbproxy bfin
   
3. Load u-boot onto the STAMP using GDB (The GDBSCRIPTS variable has to be substituted by the location of your GDB scripts, normally in the subdirectory scripts/ or /usr/share/gdbscripts/ of your ICEbear software distribution).
   
       target remote :2000
    source $(GDBSCRIPTS)/mmr.gdb
    source $(GDBSCRIPTS)/init.gdb

    monitor reset     # initialize memory, can also use 'initmem_ezkit_bf537' (see init.gdb)
        set *$EBIU_SDGCTL = 0x0091998d
        set *$EBIU_SDBCTL = 0x0025
        set *$EBIU_SDRRC  = 0x03a0
    load u-boot

    # Load u-boot image into memory:
    restore u-boot.bin binary 0x100000

   The last 'restore' command will output something like:
   Restoring binary file u-boot.bin into memory (0x100000 to 0x10e1b4)
   
   For the memory copy command below, you need to know the u boot image size
   in memory IN WORDS! This calculates, for example, as:
   
   (0x101968c - 0x1000000 + 1) / 2
   
   Run u-boot with the 'c' command. You should now get some startup messages
   on the terminal screen.
4. Run the following commands in u-boot:
   
       bf537> protect off all
    bf537> erase all
    bf537> cp.w 0x100000 0x20000000 <size of binary file in words>


5. After successful copying of the image, you can reset the board and it will boot into u-boot from flash.
   

Note: This is not a practical way for production. You may rather want to flash u-boot.bin directly using the bfloader tools (see Appnote below). However, when porting u-boot to a new board this is the preferrable method to test proper flash support.

Important: When the SDRAM interface configuration is incorrect, the Blackfin CPU will throw a core fault when running the program after the 'load' command. Make sure you have the proper values configured for the default PLL configuration (see hardware manual of your Blackfin CPU).

2. Loading and debugging uClinux with bfin-elf-gdb

a) Kernel does not boot or output anything on the console

• Hit Ctrl-C to interrupt execution. Try the 'bt' command to see the stack backtrace. This normally shows you the top level functions within the error happened
• Try using the catch_exc.gdb script found in the ICEbear software directory (scripts/), in case there are hardware or memory access exceptions. Those often do not provide a reliable stack trace, so you will have to look at the RETX register ($retx in GDB) to find the instruction that caused the error
• If this does not help, manually step through the code. You may want to set a breakpoint in start_kernel(), assuming that all the startup code (starting from stext)  works and the memory is properly configured.
• You may want to set a breakpoint in panic(), since this function may be called before console output actually happens. Breaking in printk() is also quite helpful, but slightly more 'verbose'.
  

b) Hardware drivers fail, spurious kernel panics occur

• Make sure that peripheral errors are not masked out in the SIC_IMASK register ($SIC_IMASK in GDB). Use the dump_irq and dump_sic functions from the dump.gdb script to find out about the error source.
• Make sure again that the SDRAM is stable. If errors are not reproduceable or happen when running the code, but not when single stepping in emulation, this is most likely a timing issue.
• Try turning off the Blackfin's Cache in the uClinux configuration (and recompile). If the problem goes away, it might be again a timing issue or a silicon revision problem (BF533 revisions < 0.3 and BF537 < 0.1 were found to be problematic, for details see Chip errata at www.analog.com)
  

3. Flash programming via GDB script (bfloader)

Note: This information is outdated. Please use the standalone 'bfloader' tool found in the software area. The bfloader scripts are no longer maintained (but still available for demo).

1. Customize the loader backend (C source) to your flash's sizes, mappings (and commands, if necessary). You may want to use existing source code that already works with the VDSP flash loader. Warning: Some loader backends have found to be buggy and not being able to handle odd filesizes correctly (last byte missing)
   
2. Adapt path(s) to image(s) in flashload.sh
3. Check in .gdbinit whether calls to erase_blocks match the partitioning scheme (if you have one) of your flash. This for example applies to the above program_linux command.