Content in EngineerZone

Implementing and exploring PING on LwIP.

analogvm-admin@analog-vm.hosted.jivesoftware.com — Thu, 21 Jul 2011 08:01:47 GMT

PING is an interesting and useful diagnostic tool for IP networks. It is supported via command-line by Operating Systems such as Windows or Linux. Implementing PING is generally trivial. An example implemention of the PING command as well as PING request detection on LwIP/Blackfin is provided. This is only a reference implementation, and need not be the best way to implement the same. A quick overview of the PING protocol & the ICMP packets are provided, citing Wikipedia links.

As mentioned in Wikipedia: (http://en.wikipedia.org/wiki/Ping) "Ping operates by sending Internet Control Message Protocol (ICMP) echo request packets to the target host and waiting for an ICMP response. In the process it measures the time from transmission to reception (round-trip time) and records any packet loss. The results of the test are printed in form of a statistical summary of the response packets received, including the minimum, maximum, and the mean round-trip times, and sometimes the standard deviation of the mean."

In contrast to data transfer protocols such as UDP and TCP, ICMP packets (http://en.wikipedia.org/wiki/Ping#ICMP_packet) are generally used for quickly diagnosing connection errors in the network path. As an example, an administrator may PING to a particular IP address to know whether he can reach a client or a server in the network path. In embedded system development, user may perform this as the first step to ensure that he can communicate from PC to the IP stack running on his board, through a cross over cable.

PING command operates as a two stage process:

1. Send Echo request with ICMP.

The program is required to create an ICMP message with ICMP header Type field = 0x8 (echo request). The stack will provide the IP header and the Ethernet header. Application needs to insert the Echo Request in to Type field of ICMP packet.

2. Catch Echo reply with ICMP.

The input comes as a whole IP layer packet that contains the IP header as well as ICMP header. Application can look for ICMP header Type field = 0x0 (echo reply).

The IP stack automatically handles PING requests. There is generally no need for user intervention to detect PING from Host. However, by simply opening a RAW socket, user can also detect whether a host is trying to PING or not. To do this, user can wait for data from that RAW socket through recvfrom(), and then extract the entire IP header and ICMP header to look for echo request in the ICMP header Type field.

PING command and PING detection can be implemented with the help of RAW BSD-style sockets. RAW sockets are special types of sockets that allow the application layer to manipulate the lower layers. Note that the application needs to know the embedded protocol correctly when RAW sockets are used; fortunately ICMP packets are easy to understand.

ICMP packets (images from Wikipedia):

The above implementation on a BF527 EZ-KIT Lite running LwIP stack is provided as an attachement herewith (tested with VDSP.5.0.9).

The code works the following way:

1. Issue PING from Host to Blackfin. Echo request from host is detected and printed on VDSP console window. Blackfin also responds to this request via echo replies, which is printed on Host console.

2. Issue PING command to the same detected Host from Blackfin/LwIP. PC responds to echo requests from Blackfin.

Notes from the code:

1. Creating RAW socket:

rawSocket = socket(AF_INET, SOCK_RAW, IP_PROTO_ICMP);

2. Inserting ICMP echo request data:

icmp_packet.type = ECHO_REQ;
icmp_packet.code = 0;
icmp_packet.checksum = 0;
icmp_packet.id = PING_ID;
icmp_packet.seqno = htons(++ping_seq_num);
icmp_packet.checksum = inet_chksum((u16 *)&icmp_packet, sizeof(ICMP_PACKET));

3. Calculating timeout with clock():

echo_rx_timestamp = catch_echo_reply(rawSocket, &sockSrc, &pTTL);
echo_time_elapsed = (echo_rx_timestamp - echo_tx_timestamp);
clockspersec = CLOCKS_PER_SEC;
echo_time_elapsed = (echo_time_elapsed / clockspersec) * 1000;

4. Packet Headers:

typedef struct IP_PACKET
{
u8   VIHL;                  // Version and IHL
u8 TOS;                   // Type Of Service
u16 TotLen;              // Total Length
u16 ID;                    // Identification
u16 FlagOff;             // Flags and Fragment Offset
u8 TTL;                    // Time To Live
u8 Protocol;             // Protocol
u16 Checksum;        // Checksum
struct in_addr ipsrc;   // Internet Address - Source
struct in_addr ipdst;   // Internet Address - Destination
} IP_PACKET;

typedef struct ICMP_PACKET
{
u8 type;                   // Type
u8 code;                  // Code
u16 checksum;        // Checksum
u16 id;                    // Identification
u16 seqno;              // Sequence
char data[32];           // Data
} ICMP_PACKET;

5. Giving back TTL and time for transfer to application:

*pTTL = echo_reply_info.ip_packet.TTL;
echo_rx_timestamp = clock();

6. Giving back echo detect to application:

pingserver_info.type = echo_request_info.icmp_packet.type;
pingserver_info.ipsrc = echo_request_info.ip_packet.ipsrc;

7. Inserting user data to the echo request:

Insert_Data = &icmp_packet.data[0];
strcpy(Insert_Data,"Blackfin Processor");

8. Time To Live:

Each time an IP device such as a router receives a ping packet, it decrements the TTL counter by one. Should the packet's TTL reach zero, the device discards the packet. Note the TTL values: when sent from Blackfin the default is 255, as specified in the header ..\Blackfin\lib\src\lwip\src\include\lwip

When sent from a windows Host default is usually 128.

Wireshark (http://www.wireshark.org/) is a free and open-source packet analyzer. A sample wireshark output of the above implementation is given below. Notice the Echo request & Echo reply, and the user data.

Bug status: "[#6961] Eclipse: Unable to exclude .C files"

analogvm-admin@analog-vm.hosted.jivesoftware.com — Fri, 04 May 2012 09:01:08 GMT

Has someone looked at this bug: https://blackfin.uclinux.org/gf/project/toolchain/tracker/?action=TrackerItemEdit&tracker_item_id=6961&start=0

I need to export and re-build few VDSP/CCES libraries to GCC/CCES, so a fix would help do things properly.

Regards

Prasanth

What are the descriptor models available for BF60x EMAC DMA?

analogvm-admin@analog-vm.hosted.jivesoftware.com — Tue, 27 Mar 2012 15:35:36 GMT

BF60x EMAC has a a dedicated DMA Controller inside the peripheral. The two available descriptor models are shown below. In Ring structure, it is possible to define a specific gap size between two consecutive descriptors.

What are the power management features of BF60x EMAC?

analogvm-admin@analog-vm.hosted.jivesoftware.com — Tue, 27 Mar 2012 15:09:44 GMT

BF60x EMAC has no particular power management features built-in, in contrast to legacy parts such as BF537/BF527. This includes magic frames and wake up frames.

There is support for wake up using PHYINT signal (a GPIO in BF60x) generated by the external PHY chip. However, since the signal is treated as a GPIO wake up, any device may drive this GPIO, and not just an Ethernet PHY.

What is the FIFO size of BF60x Link Port receiver?

analogvm-admin@analog-vm.hosted.jivesoftware.com — Tue, 27 Mar 2012 15:02:34 GMT

The Link Port receiver has a 4-deep FIFO. However, this depth of size 4 can be utilized only in a worst case scenario, where the ACK reaches the transmitter very late due to board delays. In all other cases the receiver must be thought of having only a 3-deep FIFO. Below image gives a FIFO level representation of how the ACK is generated. Gray areas indicate filled data and white areas indicate free space. The ACK is pulled low as soon as 1st byte of the 3rd location (last but one) is received.

FAQ: Getting Started with SDP-B using GCC Toolchain

analogvm-admin@analog-vm.hosted.jivesoftware.com — Tue, 14 Feb 2012 18:58:06 GMT

Getting Started with SDP-B using GCC toolchain:

The SDP (System Demonstration Platform) is a collection of controller boards, interposer boards, and daughter boards used for easy, low cost evaluation of ADI components and reference circuits. The controller boards provide a means of communicating to the PC from the system being evaluated or demonstrated. The SDP-B is a Blackfin, ADSP-BF527, based controller board. The SDP-B has on board JTAG, SDRAM, Flash memory and an LED making it an attractive package for those looking at low cost development platforms on Blackfin. This, combined with the open source GNU tool-chain and a low-cost emulator, reduces the cost factor significantly. SDP-B is available at: USD 99 ^[1] and the Low-cost emulator ICE-100B is available at: USD 150 ^[2], so one could kick-off 600Mhz Blackfin based development in just USD 250 ^{[1] [2]}. User can also opt between Windows or Linux host development platforms.

This article is a quick start guide for those who want to evaluate SDP-B in a GCC environment. A pdf version of the article is available as attachment. SDP-B Rev-B & Windows host is used for testing purpose. Refer to the reference section for various related links.

The SDP-B board features:

• Analog Devices ADSP-BF527 Blackfin processor

• Core performance up to 600 MHz

• 208-ball CSP-BGA package

• 24 MHz CLKIN oscillator

• 5 Mb of internal RAM memory

• 32 Mb flash memory

Numonyx M29W320EB (Rev B) or

Numonyx M25P32 (Rev 1.3)

• SDRAM memory

Micron MT48LC16M16A2P-6A - 16 Mb x 16 bits (256 Mb/32 MB)

• 3 × 120-pin small foot print connectors

Hirose FX8-120P-SV1(91), 120-pin header

• JTAG header footprint

• USB 2.0 device interface to host PC.

• Blackfin processor peripherals exposed

SPI

SPORT

TWI/I2C

GPIO

PPI

Asynchronous parallel

Timers

Development System:

SDP-B is a USB powered board ^[3], so one needs to have a USB mini-cable to power on the system. Typical development environment consists of a JTAG-based emulator and a GUI-based Debugger. ICE-100B is a low cost emulator from ADI that has direct support for the GCC toolchain. Another USB-cable is required to hook up the emulator to the JTAG connector in SDP-B board. Eclipse is an open source IDDE, which presents a complete debugger front-end to the developer. It can support almost any debugging requirement such as build code, execute, stop-at-breakpoints, single-step through code, view memory, MMRs etc.

GNU Debugger:

GDB (GNU Debugger) is the debugger utility for debugging applications built using GCC toolchain. User should be aware of the basic infrastructure that enables Eclipse to debug applications via gdb. A typical setup is given below.

Eclipse needs to use gdbproxy in order to talk to the target device. Gdbproxy, as the name indicates, is a proxy server or a stub which in turn uses urJTAG software for the actual JTAG operations.

Installation of bare metal toolchain and Eclipse:

The latest release of the toolchain and the utilities (blackfin-toolchain-win32-) can be downloaded from the following link:

http://blackfin.uclinux.org/gf/project/toolchain/frs/

Once all files are installed, the emulator driver must be installed through *.inf file modifications. This file can be found in the toolchain installation path: “..\GNU Toolchain\2010R1\gnICE-drivers”. Next, modify the *.inf to include support for ICE-100B, as given below:

*Sample .inf file**
;[Devices] ;%gnICE_JTAG% = USB_Install, USB\VID_0456&PID_f000&MI_00 ;%gnICE+_JTAG% = USB_Install, USB\VID_0456&PID_f001&MI_00 "GNU ICE100B" = USB_Install, USB\VID_064b&PID_0225&REV_0100 [Devices.NTX86] %gnICE_JTAG% = USB_Install, USB\VID_0456&PID_f000&MI_00 %gnICE+_JTAG% = USB_Install, USB\VID_0456&PID_f001&MI_00 "GNU ICE100B" = USB_Install, USB\VID_064b&PID_0225&REV_0100 [Devices.NTAMD64] %gnICE_JTAG% = USB_Install, USB\VID_0456&PID_f000&MI_00 %gnICE+_JTAG% = USB_Install, USB\VID_0456&PID_f001&MI_00 "GNU ICE100B" = USB_Install, USB\VID_064b&PID_0225&REV_0100

Sample *.inf file

;[Devices]
;%gnICE_JTAG% = USB_Install, USB\VID_0456&PID_f000&MI_00
;%gnICE+_JTAG% = USB_Install, USB\VID_0456&PID_f001&MI_00
"GNU ICE100B" = USB_Install, USB\VID_064b&PID_0225&REV_0100
[Devices.NTX86]
%gnICE_JTAG% = USB_Install, USB\VID_0456&PID_f000&MI_00
%gnICE+_JTAG% = USB_Install, USB\VID_0456&PID_f001&MI_00
"GNU ICE100B" = USB_Install, USB\VID_064b&PID_0225&REV_0100
[Devices.NTAMD64]
%gnICE_JTAG% = USB_Install, USB\VID_0456&PID_f000&MI_00
%gnICE+_JTAG% = USB_Install, USB\VID_0456&PID_f001&MI_00
"GNU ICE100B" = USB_Install, USB\VID_064b&PID_0225&REV_0100

Connecting JTAG first time:

Connect emulator.
Connect USB cable from emulator to PC.
When PC asks for driver software, install the same from the path: “..\GNU Toolchain\2010R1\gnICE-drivers"

4. Restart PC.

5. Check whether the device is listed in the device manager such as below.

Running gdbproxy:

Before any actual program can be debugged, the gdbproxy must successfully detect the jtag device. Gdbproxy maybe untouched after the connection is established. Example log is given below, after running this command:

Running gdbproxy
C:\Program Files\Analog Devices\GNU Toolchain\2010R1\elf\bin>bfin-gdbproxy.exe Remote proxy for GDB, v0.7.2, Copyright (C) 1999 Quality Quorum Inc. MSP430 adaption Copyright (C) 2002 Chris Liechti and Steve Underwood Blackfin adaption Copyright (C) 2008 Analog Devices, Inc. GDBproxy comes with ABSOLUTELY NO WARRANTY; for details use `--warranty' option. This is Open Source software. You are welcome to redistribute it under certain conditions. Use the '--copying' option for details. Found USB cable: ICE-100B ICE-100B firmware version is 2.0.6 IR length: 5 Chain length: 1 Device Id: 00100010011111100000000011001011 (0x227E00CB) Manufacturer: Analog Devices, Inc. (0x0CB) Part(0): BF527 (0x27E0) Stepping: 2 Filename: c:\program files\analog devices\gnu toolchain\svn-20101128\elf\b in\../share/urjtag/analog/bf527/bf527 warning: bfin: no board selected, BF527 is detected notice: bfin: jc: waiting on TCP port 2001 notice: bfin: jc: (you must connect GDB before using jtag console) notice: bfin-gdbproxy.exe: waiting on TCP port 2000

Running gdbproxy

C:\Program Files\Analog Devices\GNU Toolchain\2010R1\elf\bin>bfin-gdbproxy.exe

GDBproxy comes with ABSOLUTELY NO WARRANTY; for details use `--warranty' option. This is Open Source software. You are welcome to redistribute it under certain conditions. Use the '--copying' option for details.

Found USB cable: ICE-100B

ICE-100B firmware version is 2.0.6

IR length: 5

Chain length: 1

Device Id: 00100010011111100000000011001011 (0x227E00CB)

Manufacturer: Analog Devices, Inc. (0x0CB)

Part(0): BF527 (0x27E0)

Stepping: 2

Filename: c:\program files\analog devices\gnu toolchain\svn-20101128\elf\b

in\../share/urjtag/analog/bf527/bf527

warning: bfin: no board selected, BF527 is detected

notice: bfin: jc: waiting on TCP port 2001

notice: bfin: jc: (you must connect GDB before using jtag console)

notice: bfin-gdbproxy.exe: waiting on TCP port 2000

Creating project in Eclipse (only sample screenshots and explanations):

Start with new C project and appropriate toolchain:

Click on next until you arrive at processor definition:

A new project is now created with default file template. Remember that there are no low level drivers for stdio functions; you need to create your own implementation with newlib library for this. So delete the following code for now:

stdio related code to be removed
#include <stdio.h> puts("!!!Hello World!!!"); /* prints !!!Hello World!!! */

stdio related code to be removed

#include <stdio.h>

puts("!!!Hello World!!!"); /* prints !!!Hello World!!! */

Right click on the project tab and build the code. Eclipse throws out verbose like below:

build console output
** Build of configuration Debug for project SDP_test_project ** make all 'Building file: ../src/SDP_test_project.c' 'Invoking: Blackfin ELF C Compiler' bfin-elf-gcc -O0 -g3 -Wall -c -fmessage-length=0 -mcpu=bf527-any -MMD -MP -MF"src/SDP_test_project.d" -MT"src/SDP_test_project.d" -o"src/SDP_test_project.o" "../src/SDP_test_project.c" 'Finished building: ../src/SDP_test_project.c' ' ' 'Building target: SDP_test_project' 'Invoking: Blackfin ELF C Linker' bfin-elf-gcc -mcpu=bf527-any -o"SDP_test_project" ./src/SDP_test_project.o 'Finished building target: SDP_test_project' ' '

build console output

**** Build of configuration Debug for project SDP_test_project ****

make all

'Building file: ../src/SDP_test_project.c'

'Invoking: Blackfin ELF C Compiler'

bfin-elf-gcc -O0 -g3 -Wall -c -fmessage-length=0 -mcpu=bf527-any -MMD -MP -MF"src/SDP_test_project.d" -MT"src/SDP_test_project.d" -o"src/SDP_test_project.o" "../src/SDP_test_project.c"

'Finished building: ../src/SDP_test_project.c'

' '

'Building target: SDP_test_project'

'Invoking: Blackfin ELF C Linker'

bfin-elf-gcc -mcpu=bf527-any -o"SDP_test_project" ./src/SDP_test_project.o

'Finished building target: SDP_test_project'

' '

If the status is reporting as finished building, we have an executable ready for testing.

Debugging with Eclipse:

Next step is to create a debug configuration for the project. Right click on project and choose Debug Configurations. Create a new configuration under “bare metal application on JTAG device”. Go to Debugger tab and change the port number to 2000. Click on “apply” and “debug”. Sample screenshots are given below.

A screenshot for successful debug will look like below. Terminate with red-button and re-launch with Debug tab right click for every new build.

Explore the toolchain settings for project and the MMR window:

Minimal test of SDP-B hardware with GCC:

The following code blinks LED1 in the SDP:

LED blink code	LED blink code contd...
#include <cdefBF527.h> void writeToSdpLatch(unsigned char latchData); void flashLed(void); void waitMilliSec(void); void configEBIU(void); void configFlashEnable(void); #define PIN_PG0 0x0001 unsigned char latchValue = 0; int main() { configFlashEnable(); configEBIU(); while(1) { flashLed(); } return 0; } void configFlashEnable() { pPORTGIO_DIR \|= PIN_PG0; pPORTGIO_SET = PIN_PG0; asm("ssync;"); latchValue = 0; } void configEBIU() { pEBIU_AMGCTL = 0x00F9; pEBIU_AMBCTL0 = 0x7BB07BB0; pEBIU_AMBCTL1 = 0x7BB07BB0; asm*("ssync;"); latchValue = 0; }	void writeToSdpLatch(unsigned char latchData) { // write to latch (bank 2) ((unsigned* char)0x20200000) = latchData; asm("ssync;"); } void* flashLed(void) { unsigned char i = 0; for (i=0; i<5; i++) { latchValue = latchValue \| 0x08; writeToSdpLatch(latchValue); waitMilliSec(); latchValue = latchValue & 0xF7; writeToSdpLatch(latchValue); waitMilliSec(); } } void waitMilliSec() { int j = 0; for(j=0;j<1000000;j++) asm("NOP;"); }

LED blink code

LED blink code contd...

#include <cdefBF527.h>

void writeToSdpLatch(unsigned char latchData);

void flashLed(void);

void waitMilliSec(void);

void configEBIU(void);

void configFlashEnable(void);

#define PIN_PG0 0x0001

unsigned char latchValue = 0;

int main()

{

configFlashEnable();

configEBIU();

while(1)

{

flashLed();

}

return 0;

}

void configFlashEnable()

{

*pPORTGIO_DIR |= PIN_PG0;

*pPORTGIO_SET = PIN_PG0;

asm("ssync;");

latchValue = 0;

}

void configEBIU()

{

*pEBIU_AMGCTL = 0x00F9;

*pEBIU_AMBCTL0 = 0x7BB07BB0;

*pEBIU_AMBCTL1 = 0x7BB07BB0;

asm("ssync;");

latchValue = 0;

}

void writeToSdpLatch(unsigned char latchData)

{

// write to latch (bank 2)

*((unsigned char*)0x20200000) = latchData;

asm("ssync;");

}

void flashLed(void)

{

unsigned char i = 0;

for (i=0; i<5; i++)

{

latchValue = latchValue | 0x08;

writeToSdpLatch(latchValue);

waitMilliSec();

latchValue = latchValue & 0xF7;

writeToSdpLatch(latchValue);

waitMilliSec();

}

void waitMilliSec()

{

int j = 0;

for(j=0;j<1000000;j++)

asm("NOP;");

}

Creating LDR file:

Once the project has been debugged via emulator, one needs to create the corresponding LDR (Loader) file in order to use in a standalone system. A standalone system consists of a boot source, typically a non-volatile memory from where the LDR file is read by the on-chip BOOT-ROM in Blackfin. The BOOT-ROM copies the various code and data objects in to various memories available in the system. Once BOOT-ROM has finished this operation, it jumps to the start of application to perform further execution.

In GCC environment, this LDR file is created via ld-utils provided in “\GNU Toolchain\2010R1\elf\bin” folder in the installation directory. Command bfin-elf-ldr.exe along with its parameters needs to be run in order to burn the ldr in the correct way to the flash. For example, the following command operates on the executable named SDP_LED_BLINK and creates an LDR file called LEDblink.ldr for BF527 supporting a 16-bit Flash device.

creating ldr file
C:\Program Files\Analog Devices\GNU Toolchain\2010R1\elf\bin>bfin-elf-ldr.exe -T bf527 -v -c --bits 16 LEDblink.ldr SDP_LED_BLINK --bmode para Creating LDR LEDblink.ldr ... Adding DXE 'SDP_LED_BLINK' ... [jump block to 0xFFA00000] [ELF block: 1104 @ 0xFF800000] [ELF block: 1620 @ 0xFFA00000] OK! Done!

creating ldr file

C:\Program Files\Analog Devices\GNU Toolchain\2010R1\elf\bin>bfin-elf-ldr.exe -T bf527 -v -c --bits 16 LEDblink.ldr SDP_LED_BLINK --bmode para

Creating LDR LEDblink.ldr ...

Adding DXE 'SDP_LED_BLINK' ... [jump block to 0xFFA00000] [ELF block: 1104 @ 0xFF800000] [ELF block: 1620 @ 0xFFA00000] OK!

Done!

Automating LDR creation with Eclipse

Create a new configuration under Run -> External Configuration, and appropriate parameters.

Add this tool to the Builder list so that Eclipse calls this automatically.

Upon successful build, eclipse throws the output as below:

Loading LDR file via urJTAG software:

Perform the following command sequence with urJTAG command prompt in order to load an ldr file. The tool supports auto-completion pre-load from history. Example sequence used for burning the LED_blink_ ldr:

urJTAG command sequence
C:\Program Files\Analog Devices\GNU Toolchain\2010R1\elf\bin>bfin-jtag.exe UrJTAG 0.10 #5733 Copyright (C) 2002, 2003 ETC s.r.o. Copyright (C) 2007, 2008, 2009 Kolja Waschk and the respective authors UrJTAG is free software, covered by the GNU General Public License, and you arewelcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for UrJTAG. warning: UrJTAG may damage your hardware! Type "quit" to exit, "help" for help. jtag> cable ICE-100B ICE-100B firmware version is 2.0.6 jtag> detect IR length: 5 Chain length: 1 Device Id: 00100010011111100000000011001011 (0x227E00CB) Manufacturer: Analog Devices, Inc. (0x0CB) Part(0): BF527 (0x27E0) Stepping: 2 Filename: c:\program files\analog devices\gnu toolchain\svn-20101128\elf\b in\../share/urjtag/analog/bf527/bf527 jtag> initbus bf527_sdp jtag> detectflash 0x20000000 Query identification string: Primary Algorithm Command Set and Control Interface ID Code: 0x0002 (AMD/Fujitsu Standard Command Set) Alternate Algorithm Command Set and Control Interface ID Code: 0x0000 (null) Query system interface information: Vcc Logic Supply Minimum Write/Erase or Write voltage: 2700 mV Vcc Logic Supply Maximum Write/Erase or Write voltage: 3600 mV Vpp [Programming] Supply Minimum Write/Erase voltage: 11500 mV Vpp [Programming] Supply Maximum Write/Erase voltage: 12500 mV Typical timeout per single byte/word program: 16 us Typical timeout for maximum-size multi-byte program: 0 us Typical timeout per individual block erase: 1024 ms Typical timeout for full chip erase: 0 ms Maximum timeout for byte/word program: 256 us Maximum timeout for multi-byte program: 0 us Maximum timeout per individual block erase: 8192 ms Maximum timeout for chip erase: 0 ms Device geometry definition: Device Size: 4194304 B (4096 KiB, 4 MiB) Flash Device Interface Code description: 0x0002 (x8/x16) Maximum number of bytes in multi-byte program: 1 Number of Erase Block Regions within device: 2 Erase Block Region Information: Region 0: Erase Block Size: 8192 B (8 KiB) Number of Erase Blocks: 8 Region 1: Erase Block Size: 65536 B (64 KiB) Number of Erase Blocks: 63 Primary Vendor-Specific Extended Query: Major version number: 1 Minor version number: 1 Address Sensitive Unlock: Required Erase Suspend: Read/write Sector Protect: 1 sectors per group Sector Temporary Unprotect: Not supported Sector Protect/Unprotect Scheme: 29BDS640 mode (Software Command Locking) Simultaneous Operation: Not supported Burst Mode Type: Supported Page Mode Type: Not supported ACC (Acceleration) Supply Minimum: 11500 mV ACC (Acceleration) Supply Maximum: 12500 mV Top/Bottom Sector Flag: Bottom boot device jtag> endian little jtag> flashmem 0x20000000 LEDblink.ldr Chip: AMD Flash Manufacturer: ST/Samsung Chip: Unknown (ID 0x2257) Protected: 0000 program: flash_unlock_block 0x20000000 IGNORE block 0 unlocked flash_erase_block 0x20000000 flash_erase_block 0x20000000 DONE erasing block 0: 0 addr: 0x200005CC verify: addr: 0x200005CC Done. jtag> instruction BYPASS jtag> shift ir jtag> quit C:\Program Files\Analog Devices\GNU Toolchain\2010R1\elf\bin>

urJTAG command sequence

C:\Program Files\Analog Devices\GNU Toolchain\2010R1\elf\bin>bfin-jtag.exe

UrJTAG 0.10 #5733

UrJTAG is free software, covered by the GNU General Public License, and you arewelcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for UrJTAG.

warning: UrJTAG may damage your hardware!

Type "quit" to exit, "help" for help.

jtag> cable ICE-100B

ICE-100B firmware version is 2.0.6

jtag> detect

IR length: 5

Chain length: 1

Device Id: 00100010011111100000000011001011 (0x227E00CB)

Manufacturer: Analog Devices, Inc. (0x0CB)

Part(0): BF527 (0x27E0)

Stepping: 2

Filename: c:\program files\analog devices\gnu toolchain\svn-20101128\elf\b

in\../share/urjtag/analog/bf527/bf527

jtag> initbus bf527_sdp

jtag> detectflash 0x20000000
Query identification string:
        Primary Algorithm Command Set and Control Interface ID Code: 0x0002 (AMD/Fujitsu Standard Command Set)
        Alternate Algorithm Command Set and Control Interface ID Code: 0x0000 (null)
Query system interface information:
        Vcc Logic Supply Minimum Write/Erase or Write voltage: 2700 mV
        Vcc Logic Supply Maximum Write/Erase or Write voltage: 3600 mV
        Vpp [Programming] Supply Minimum Write/Erase voltage: 11500 mV
        Vpp [Programming] Supply Maximum Write/Erase voltage: 12500 mV
        Typical timeout per single byte/word program: 16 us
        Typical timeout for maximum-size multi-byte program: 0 us
        Typical timeout per individual block erase: 1024 ms
        Typical timeout for full chip erase: 0 ms
        Maximum timeout for byte/word program: 256 us
        Maximum timeout for multi-byte program: 0 us
        Maximum timeout per individual block erase: 8192 ms
        Maximum timeout for chip erase: 0 ms
Device geometry definition:
        Device Size: 4194304 B (4096 KiB, 4 MiB)
        Flash Device Interface Code description: 0x0002 (x8/x16)
        Maximum number of bytes in multi-byte program: 1
        Number of Erase Block Regions within device: 2
        Erase Block Region Information:
                Region 0:
                        Erase Block Size: 8192 B (8 KiB)
                        Number of Erase Blocks: 8
                Region 1:
                        Erase Block Size: 65536 B (64 KiB)
                        Number of Erase Blocks: 63
Primary Vendor-Specific Extended Query:
        Major version number: 1
        Minor version number: 1
        Address Sensitive Unlock: Required
        Erase Suspend: Read/write
        Sector Protect: 1 sectors per group
        Sector Temporary Unprotect: Not supported
        Sector Protect/Unprotect Scheme: 29BDS640 mode (Software Command Locking)

        Simultaneous Operation: Not supported
        Burst Mode Type: Supported
        Page Mode Type: Not supported
        ACC (Acceleration) Supply Minimum: 11500 mV
        ACC (Acceleration) Supply Maximum: 12500 mV
        Top/Bottom Sector Flag: Bottom boot device
jtag> endian little
jtag> flashmem 0x20000000 LEDblink.ldr
Chip: AMD Flash
        Manufacturer: ST/Samsung
        Chip: Unknown (ID 0x2257)
        Protected: 0000
program:
flash_unlock_block 0x20000000 IGNORE

block 0 unlocked
flash_erase_block 0x20000000
flash_erase_block 0x20000000 DONE
erasing block 0: 0
addr: 0x200005CC
verify:
addr: 0x200005CC
Done.
jtag> instruction BYPASS
jtag> shift ir
jtag> quit

C:\Program Files\Analog Devices\GNU Toolchain\2010R1\elf\bin>

Notes:

[1] – Refer to SDP web page in Analog Devices website for up to date information on pricing and availability.

http://www.analog.com/sdp

[2] - Refer to ICE 100B web page in Analog Devices website for up to date information on pricing and availability.

http://www.analog.com/en/processors-dsp/blackfin/emulator-100/processors/product.html

[3] - While the SDP can be powered over USB, when there are daughter boards attached the daughter boards should normally power the SDP. This is because of the variability of the USB power (+/-10% and current dependent on what other devices share the bus).

Reference:

SDP: http://www.analog.com/sdp

SDP Wiki: http://wiki.analog.com/resources/eval/sdp

Blackfin Processor: http://www.analog.com/blackfin

Open Source documentation: http://docs.blackfin.uclinux.org/

GCC bare metal documention: http://docs.blackfin.uclinux.org/doku.php?id=toolchain:bare_metal

GCC Files and development: http://blackfin.uclinux.org/gf/project/toolchain

Eclipse: http://www.eclipse.org/

Discussion Forums:

SDP: http://ez.analog.com/community/circuits_from_the_lab/sdp

Blackfin: http://ez.analog.com/community/dsp/blackfin-processors

Open Source development: http://ez.analog.com/community/dsp/open-source

FAQ: GDB commands for newbie.

analogvm-admin@analog-vm.hosted.jivesoftware.com — Tue, 14 Feb 2012 18:57:14 GMT

Can you provide some quick GDB commands for a newbie?

--------------------------------------------------------------------------

This is a quick FAQ written in a typical debug sequence and is only meant for beginners. I just extracted the contents of the uploaded file in Doc Site:

http://docs.blackfin.uclinux.org/lib/exe/fetch.php?media=presentations:toolchain:gdb_for_dummies.pdf

Fact Sheet

What is GDB? http://shop.fsf.org/product/debugging-gdb-gnu-source-level-debugger/

“GDB, the GNU Project debugger, allows you to see what is going on `inside' another program while it executes -- or what another program was doing at the moment it crashed. GDB can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act:

Start your program, specifying anything that might affect its behavior.
Make your program stop on specified conditions.
Examine what has happened, when your program has stopped.
Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another. ”

What is GDB Server? http://en.wikipedia.org/wiki/Gdbserver

“gdb-server is a computer program that makes it possible to remotely debug other programs.Running on the same system as the program to be debugged, it allows the GNU Debugger to connect from another system; that is, only the executable to be debugged needs to be resident on the target system, while the source code and a copy of the binary file to be debugged reside on the developer’s local computer. The connection can be either TCP or a serial line”

What is GDB Proxy? https://docs.blackfin.uclinux.org/doku.php?id=toolchain:debug:gdbproxy

When debugging under the gdb environment, the debugger needs to know what target to connect to. This target is a tiny server daemon, typically running on the host computer. It is equivalent to a gdbserver, although it does not run on the target hardware. This server is called gdbproxy and is derived from rproxy-0.7.

What is Eclipse? http://en.wikipedia.org/wiki/Eclipse_(software)

Eclipse is a multi-language software development environment comprising an integrated development environment (IDE) and an extensible plug-in system. It is written mostly in Java and can be used to develop applications in Java and, by means of various plug-ins, other programming languages including Ada, C, C++, COBOL, Perl, PHP, Python, R. Ruby (including Ruby on Rails framework), Scala, Clojure, and Scheme.

What is GDB/mi Interface? http://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html#GDB_002fMI

GDB/MI is a line based machine oriented text interface to GDB and is activated by specifying using the --interpreter command line option (see Mode Options). It is specifically intended to support the development of systems which use the debugger as just one small component as a larger system {Eclipse}.

Lets learn from a simple no-hardware code as below. All following gdb commands are sequentially tested…

Sample code for debugging
int global_data = 1111; void func1(); void func2(); int main(void); int main(void) { func1(); return 0; } void func1() { int local_data = 1234; global_data = 5678; func2(); } void func2() { }

Sample code for debugging

int global_data = 1111;

void func1();

void func2();

int main(void);

int main(void)

{

func1();

return 0;

}

void func1()

{

int local_data = 1234;

global_data = 5678;

func2();

}

void func2()

{

}

Start the GDB first:
C:\Program Files\Analog Devices\GNU Toolchain\2010R1\elf\bin>bfin-elf-gdb.exe gdb_debugging GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i386-mingw32msvc --target=bfin-elf"... (gdb) target remote localhost:2000 Remote debugging using localhost:2000 main () at ../src/gdb_debugging.c:9 9 func1(); (gdb) load Loading section .rodata, size 0x8 lma 0xff800000 Loading section .eh_frame, size 0x4 lma 0xff800008 Loading section .ctors, size 0x8 lma 0xff80000c Loading section .dtors, size 0x8 lma 0xff800014 Loading section .jcr, size 0x4 lma 0xff80001c Loading section .data, size 0x40c lma 0xff800020 Loading section .text, size 0x510 lma 0xffa00000 Loading section .init, size 0x12 lma 0xffa00510 Loading section .fini, size 0xe lma 0xffa00522 Start address 0xffa00000, load size 2396 Transfer rate: 140941 bits/sec, 266 bytes/write.

Start the GDB first:

C:\Program Files\Analog Devices\GNU Toolchain\2010R1\elf\bin>bfin-elf-gdb.exe gdb_debugging

GNU gdb 6.6

GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "show warranty" for details.

This GDB was configured as "--host=i386-mingw32msvc --target=bfin-elf"...

(gdb) target remote localhost:2000

Remote debugging using localhost:2000

main () at ../src/gdb_debugging.c:9

9 func1();

(gdb) load

Loading section .rodata, size 0x8 lma 0xff800000

Loading section .eh_frame, size 0x4 lma 0xff800008

Loading section .ctors, size 0x8 lma 0xff80000c

Loading section .dtors, size 0x8 lma 0xff800014

Loading section .jcr, size 0x4 lma 0xff80001c

Loading section .data, size 0x40c lma 0xff800020

Loading section .text, size 0x510 lma 0xffa00000

Loading section .init, size 0x12 lma 0xffa00510

Loading section .fini, size 0xe lma 0xffa00522

Start address 0xffa00000, load size 2396

Transfer rate: 140941 bits/sec, 266 bytes/write.

Insert some break points – at the entry of each function:
(gdb) break main Breakpoint 1 at 0xffa00274: file ../src/gdb_debugging.c, line 9. (gdb) break func1 Breakpoint 2 at 0xffa00284: file ../src/gdb_debugging.c, line 17. (gdb) break func2 Breakpoint 3 at 0xffa002ac: file ../src/gdb_debugging.c, line 28.

Insert some break points – at the entry of each function:

(gdb) break main

Breakpoint 1 at 0xffa00274: file ../src/gdb_debugging.c, line 9.

(gdb) break func1

Breakpoint 2 at 0xffa00284: file ../src/gdb_debugging.c, line 17.

(gdb) break func2

Breakpoint 3 at 0xffa002ac: file ../src/gdb_debugging.c, line 28.

Run the code and it should hit breakpoints.
(gdb) continue Continuing. Breakpoint 1, main () at ../src/gdb_debugging.c:9 9 func1(); (gdb) continue Continuing. Breakpoint 2, func1 () at ../src/gdb_debugging.c:17 17 int local_data = 1234;

Run the code and it should hit breakpoints.

(gdb) continue

Continuing.

Breakpoint 1, main () at ../src/gdb_debugging.c:9

9 func1();

(gdb) continue

Continuing.

Breakpoint 2, func1 () at ../src/gdb_debugging.c:17

17 int local_data = 1234;

Let’s play with breakpoints. See the information of the breakpoints, how it can be disabled.
(gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0xffa00274 in main at ../src/gdb_debugging.c:9 breakpoint already hit 1 time 2 breakpoint keep y 0xffa00284 in func1 at ../src/gdb_debugging.c:17 breakpoint already hit 1 time 3 breakpoint keep y 0xffa002ac in func2 at ../src/gdb_debugging.c:28 (gdb) disable 2 (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0xffa00274 in main at ../src/gdb_debugging.c:9 breakpoint already hit 1 time 2 breakpoint keep n 0xffa00284 in func1 at ../src/gdb_debugging.c:17 breakpoint already hit 1 time 3 breakpoint keep y 0xffa002ac in func2 at ../src/gdb_debugging.c:28

Let’s play with breakpoints. See the information of the breakpoints, how it can be disabled.

(gdb) info breakpoints

Num Type Disp Enb Address What

1 breakpoint keep y 0xffa00274 in main at ../src/gdb_debugging.c:9

breakpoint already hit 1 time

2 breakpoint keep y 0xffa00284 in func1 at ../src/gdb_debugging.c:17

breakpoint already hit 1 time

3 breakpoint keep y 0xffa002ac in func2 at ../src/gdb_debugging.c:28

(gdb) disable 2

(gdb) info breakpoints

Num Type Disp Enb Address What

1 breakpoint keep y 0xffa00274 in main at ../src/gdb_debugging.c:9

breakpoint already hit 1 time

2 breakpoint keep n 0xffa00284 in func1 at ../src/gdb_debugging.c:17

breakpoint already hit 1 time

3 breakpoint keep y 0xffa002ac in func2 at ../src/gdb_debugging.c:28

Where are we now?
gdb) where #0 func1 () at ../src/gdb_debugging.c:17 #1 0xffa00278 in main () at ../src/gdb_debugging.c:9

Where are we now?

gdb) where

#0 func1 () at ../src/gdb_debugging.c:17

#1 0xffa00278 in main () at ../src/gdb_debugging.c:9

Single stepping the code…
(gdb) step 19 global_data = 5678;

Single stepping the code…

(gdb) step

19 global_data = 5678;

Let’s print the local variable..
(gdb) info local local_data = 1234

Let’s print the local variable..

(gdb) info local

local_data = 1234

And the global variable…
(gdb) print/x global_data $1 = 0x457

And the global variable…

(gdb) print/x global_data

$1 = 0x457

Check out the dis-assembly
(gdb) disassemble 0xffa00280 0xffa002a0 Dump of assembler code from 0xffa00280 to 0xffa002a0: 0xffa00280 <func1+0>: LINK 0x10; /* (16) / 0xffa00284 <func1+4>: R0 = 0x4d2 (X); / R0=0x0x4d2(1234) / 0xffa00288 <func1+8>: [FP -0x4] = R0; 0xffa0028a <func1+10>: P2.H = 0xff80; / (-128) P2=0x0xff800000<_global_impure_ptr> / 0xffa0028e <func1+14>: P2.L = 0x24; / ( 36) P2=0x0xff800024<global_data> / 0xffa00292 <func1+18>: R0 = 0x162e (X); / R0=0x0x162e(5678) */ 0xffa00296 <func1+22>: [P2] = R0; 0xffa00298 <func1+24>: CALL 0x0xffa002a4 <func2>; 0xffa0029c <func1+28>: UNLINK; End of assembler dump.

Check out the dis-assembly

(gdb) disassemble 0xffa00280 0xffa002a0

Dump of assembler code from 0xffa00280 to 0xffa002a0:

0xffa00280 <func1+0>: LINK 0x10; /* (16) */

0xffa00284 <func1+4>: R0 = 0x4d2 (X); /* R0=0x0x4d2(1234) */

0xffa00288 <func1+8>: [FP -0x4] = R0;

0xffa0028a <func1+10>: P2.H = 0xff80; /* (-128) P2=0x0xff800000<_global_impure_ptr> */

0xffa0028e <func1+14>: P2.L = 0x24; /* ( 36) P2=0x0xff800024<global_data> */

0xffa00292 <func1+18>: R0 = 0x162e (X); /* R0=0x0x162e(5678) */

0xffa00296 <func1+22>: [P2] = R0;

0xffa00298 <func1+24>: CALL 0x0xffa002a4 <func2>;

0xffa0029c <func1+28>: UNLINK;

End of assembler dump.

We run again…
(gdb) continue Continuing. Breakpoint 3, func2 () at ../src/gdb_debugging.c:28 28 }

We run again…

(gdb) continue

Continuing.

Breakpoint 3, func2 () at ../src/gdb_debugging.c:28

28 }

Look at the back-trace info of function calls and frame info.
(gdb) bt #0 func2 () at ../src/gdb_debugging.c:28 #1 0xffa0029c in func1 () at ../src/gdb_debugging.c:21 #2 0xffa00278 in main () at ../src/gdb_debugging.c:9 (gdb) backtrace full #0 func2 () at ../src/gdb_debugging.c:28 No locals. #1 0xffa0029c in func1 () at ../src/gdb_debugging.c:21 local_data = 1234 #2 0xffa00278 in main () at ../src/gdb_debugging.c:9 No locals. (gdb) frame #0 func2 () at ../src/gdb_debugging.c:28 28 }

Look at the back-trace info of function calls and frame info.

(gdb) bt

#0 func2 () at ../src/gdb_debugging.c:28

#1 0xffa0029c in func1 () at ../src/gdb_debugging.c:21

#2 0xffa00278 in main () at ../src/gdb_debugging.c:9

(gdb) backtrace full

#0 func2 () at ../src/gdb_debugging.c:28

No locals.

#1 0xffa0029c in func1 () at ../src/gdb_debugging.c:21

local_data = 1234

#2 0xffa00278 in main () at ../src/gdb_debugging.c:9

No locals.

(gdb) frame

#0 func2 () at ../src/gdb_debugging.c:28

28 }

Core register information...
(gdb) info registers r0 0x162e 5678 r1 0xff80042c -8387540 r2 0x0 0A r3 0x0 0 r4 0x8000 32768 r5 0x989680 10000000 r6 0x0 0 r7 0x0 0 p0 0xff800178 0xff800178 p1 0x1 0x1 p2 0xff800024 0xff800024 p3 0x3f1ff80 0x3f1ff80 p4 0x3f22148 0x3f22148 p5 0xffc03060 0xffc03060 sp 0xffb00f9c 0xffb00f9c fp 0xffb00f9c 0xffb00f9c i0 0xffe01300 -2092288 i1 0xffe00300 -2096384 i2 0x7d801048 2105544776 i3 0x7f900840 2140145728 m0 0x0 0 m1 0x0 0 m2 0xff807ffc -8355844 m3 0x0 0 b0 0x7fa7e73e 2141710142 b1 0xb5025ff6 -1258135562 b2 0x5b4597f7 1531287543 b3 0x4c3dac51 1279110225 l0 0x0 0 l1 0x0 0 l2 0x0 0 l3 0x0 0 a0x 0x0 0 a0w 0x3200000 52428800 a1x 0x0 0 a1w 0x2b53 11091 astat 0x2001025 33558565 rets 0xffa0029c 0xffa0029c <func1+28> lc0 0x0 0 lt0 0xffa0005c -6291364 lb0 0xffa0005d -6291363 lc1 0x0 0 lt1 0xffa00366 -6290586 lb1 0xffa00367 -6290585 cycles 0xa07d46a4 -1602402652 cycles2 0x0 0 usp 0xffb00ff4 0xffb00ff4 seqstat 0x0 0 syscfg 0x32 50 reti 0xffa000e8 -6291224 retx 0xffa004d6 -6290218 retn 0x986b21f 159822367 rete 0xffa002ac -6290772 pc 0xffa002ac 0xffa002ac <func2+8> cc 0x1 1 text_addr 0x0 0 text_end_addr 0x0 0 data_addr 0x0 0 fdpic_exec 0x0 0 fdpic_interp 0x0 0 ipend 0x0 0

Core register information...

(gdb) info registers

r0 0x162e 5678

r1 0xff80042c -8387540

r2 0x0 0A

r3 0x0 0

r4 0x8000 32768

r5 0x989680 10000000

r6 0x0 0

r7 0x0 0

p0 0xff800178 0xff800178

p1 0x1 0x1

p2 0xff800024 0xff800024

p3 0x3f1ff80 0x3f1ff80

p4 0x3f22148 0x3f22148

p5 0xffc03060 0xffc03060

sp 0xffb00f9c 0xffb00f9c

fp 0xffb00f9c 0xffb00f9c

i0 0xffe01300 -2092288

i1 0xffe00300 -2096384

i2 0x7d801048 2105544776

i3 0x7f900840 2140145728

m0 0x0 0

m1 0x0 0

m2 0xff807ffc -8355844

m3 0x0 0

b0 0x7fa7e73e 2141710142

b1 0xb5025ff6 -1258135562

b2 0x5b4597f7 1531287543

b3 0x4c3dac51 1279110225

l0 0x0 0

l1 0x0 0

l2 0x0 0

l3 0x0 0

a0x 0x0 0

a0w 0x3200000 52428800

a1x 0x0 0

a1w 0x2b53 11091

astat 0x2001025 33558565

rets 0xffa0029c 0xffa0029c <func1+28>

lc0 0x0 0

lt0 0xffa0005c -6291364

lb0 0xffa0005d -6291363

lc1 0x0 0

lt1 0xffa00366 -6290586

lb1 0xffa00367 -6290585

cycles 0xa07d46a4 -1602402652

cycles2 0x0 0

usp 0xffb00ff4 0xffb00ff4

seqstat 0x0 0

syscfg 0x32 50

reti 0xffa000e8 -6291224

retx 0xffa004d6 -6290218

retn 0x986b21f 159822367

rete 0xffa002ac -6290772

pc 0xffa002ac 0xffa002ac <func2+8>

cc 0x1 1

text_addr 0x0 0

text_end_addr 0x0 0

data_addr 0x0 0

fdpic_exec 0x0 0

fdpic_interp 0x0 0

ipend 0x0 0

Set some global data
(gdb) set global_data = 9999 (gdb) print global_data $2 = 9999

Set some global data

(gdb) set global_data = 9999

(gdb) print global_data

$2 = 9999

GDB/MI interface is meant for IDDE such as Eclipse. There are of course some simple useful commands. But beware – the console out seems terribly bad, when these commands are invoked directly.

Setting up as usual.
C:\Program Files\Analog Devices\GNU Toolchain\2010R1\elf\bin>bfin-elf-gdb.exe --interpreter=mi gdb_debugging ~"GNU gdb 6.6\n" ~"Copyright (C) 2006 Free Software Foundation, Inc.\n" ~"GDB is free software, covered by the GNU General Public License, and you are\n" ~"welcome to change it and/or distribute copies of it under certain conditions.\n" ~"Type \"show copying\" to see the conditions.\n" ~"There is absolutely no warranty for GDB. Type \"show warranty\" for details.\n" ~"This GDB was configured as \"--host=i386-mingw32msvc --target=bfin-elf\"...\n" (gdb) target remote localhost:2000 &"target remote localhost:2000\n" ~"Remote debugging using localhost:2000\n" ~"main () at ../src/gdb_debugging.c:9\n" ~"9\t\tfunc1();\n" ^done

Setting up as usual.

C:\Program Files\Analog Devices\GNU Toolchain\2010R1\elf\bin>bfin-elf-gdb.exe --interpreter=mi gdb_debugging

~"GNU gdb 6.6\n"

~"GDB is free software, covered by the GNU General Public License, and you are\n"

~"welcome to change it and/or distribute copies of it under certain conditions.\n"

~"Type \"show copying\" to see the conditions.\n"

~"There is absolutely no warranty for GDB. Type \"show warranty\" for details.\n"

~"This GDB was configured as \"--host=i386-mingw32msvc --target=bfin-elf\"...\n"

(gdb)

target remote localhost:2000

&"target remote localhost:2000\n"

~"Remote debugging using localhost:2000\n"

~"main () at ../src/gdb_debugging.c:9\n"

~"9\t\tfunc1();\n"

^done

Dis-assembly
(gdb) -data-disassemble -f gdb_debugging.c -l 15 -n 3 -- 0 ^done,asm_insns= [{address="0xffa00280",func-name="func1",offset="0",inst="LINK 0x10;\t\t/* (16) /"}, {address="0xffa00284",func-name="func1",offset="4",inst="R0 = 0x4d2 (X);\t\t/\t\tR0=0x0x4d2(1234) */"}, {address="0xffa00288",func-name="func1",offset="8",inst="[FP -0x4] = R0;"}]

Dis-assembly

(gdb)

-data-disassemble -f gdb_debugging.c -l 15 -n 3 -- 0

^done,asm_insns=

[{address="0xffa00280",func-name="func1",offset="0",inst="LINK 0x10;\t\t/* (16) */"},

{address="0xffa00284",func-name="func1",offset="4",inst="R0 = 0x4d2 (X);\t\t/*\t\tR0=0x0x4d2(1234) */"},

{address="0xffa00288",func-name="func1",offset="8",inst="[FP -0x4] = R0;"}]

Reading and writing data
(gdb) -data-read-memory 0xff800000 x 1 3 3 ^done,addr="0xff800000",nr-bytes="9",total-bytes="9",next-row="0xff800003",prev-row="0xff7ffffd",next-page="0xff800009",prev-page="0xff7ffff7", memory=[{addr="0xff800000",data=["0x00","0x00","0x00"]}, {addr="0xff800003",data=["0x00","0x43","0x00"]}, {addr="0xff800006",data=["0x00","0x00","0xff"]}] (gdb) -data-write-memory 0xff800000 x 1 0x11 ^done (gdb) -data-write-memory 0xff800001 x 1 0x22 ^done (gdb) -data-write-memory 0xff800001 x 1 0x33 ^done (gdb) -data-read-memory 0xff800000 x 1 3 3 ^done,addr="0xff800000",nr-bytes="9",total-bytes="9",next-row="0xff800003",prev-row="0xff7ffffd",next-page="0xff800009",prev-page="0xff7ffff7", memory=[{addr="0xff800000",data=["0x11","0x33","0x00"]}, {addr="0xff800003",data=["0x00","0x43","0x00"]}, {addr="0xff800006",data=["0x00","0x00","0xff"]}] (gdb)

Reading and writing data

(gdb)

-data-read-memory 0xff800000 x 1 3 3

^done,addr="0xff800000",nr-bytes="9",total-bytes="9",next-row="0xff800003",prev-row="0xff7ffffd",next-page="0xff800009",prev-page="0xff7ffff7",

memory=[{addr="0xff800000",data=["0x00","0x00","0x00"]},

{addr="0xff800003",data=["0x00","0x43","0x00"]},

{addr="0xff800006",data=["0x00","0x00","0xff"]}]

(gdb)

-data-write-memory 0xff800000 x 1 0x11

^done

(gdb)

-data-write-memory 0xff800001 x 1 0x22

^done

(gdb)

-data-write-memory 0xff800001 x 1 0x33

^done

(gdb)

-data-read-memory 0xff800000 x 1 3 3

^done,addr="0xff800000",nr-bytes="9",total-bytes="9",next-row="0xff800003",prev-row="0xff7ffffd",next-page="0xff800009",prev-page="0xff7ffff7",

memory=[{addr="0xff800000",data=["0x11","0x33","0x00"]},

{addr="0xff800003",data=["0x00","0x43","0x00"]},

{addr="0xff800006",data=["0x00","0x00","0xff"]}]

(gdb)

FAQ: How do I re-use projects built in VDSP in a GCC Bare metal environment?

analogvm-admin@analog-vm.hosted.jivesoftware.com — Tue, 14 Feb 2012 18:55:17 GMT

How do I re-use projects built in VDSP in a GCC Bare metal environment?

--------------------------------------------------------------------------------------

The ELF output format that Visual DSP++ toolchain produces is not compatible with the GNU toolchain output format. Therefore one cannot reuse executables or libraries built using one toolchain, with the other, unless the software is re built from scratch.

There are more examples and libraries built using the VDSP toolchain, compared to the GCC bare metal toolchain. This includes several peripheral device drivers and the various system services. Often one has to re-build these libraries or write from scratch, in order to use with GCC.

Quick answer:

Generate opcodes of the application, and use it directly from SDRAM.

Detailed answer:

Loader files or LDR files are specific formats supported by the on-chip BOOTROM in Blackfin, for booting standalone applications, often from a non-volatile boot source such as the parallel flash. The advantage of this format is that both VDSP & GCC toolchain produces the end LDR file in exactly the same format required by BOOTROM. If a user has an LDR file built via VDSP, it can be feasibly used in a GCC environment, by making use of direct code execution method & the BOOTROM callable APIs.

Boot source can either be a parallel flash or SDRAM. In case of parallel flash, user must create an LDR file using the splitter tool and burn it before actually using it in application. However, code execution from flash is considerably slower. When the boot source is an SDRAM, execution can become much faster. If the boot stream is residing in SDRAM, there is no real LDR programming required, other than including the file in the application. For creating the LDR image for direct execution, one must use the Splitter tool in Visual DSP++. This tool though it generates an LDR file, the file comprises of the opcodes of the particular program.

Now, since we can generate the opcodes, we actually don’t need the BOOTROM or SDRAM boot either. We could just perform a jump to the specific location.

BF527 is used as an example for the below for illustration. User needs to decide on the memory management carefully between the calling application, bootrom (in case used) and the called application. Additionally, the registers must be properly stored and re-loaded by the calling application. The explanations here are only intended for illustrating the concept and need not be the best method in all cases; users are expected to read the Visual DSP++ Loader Manual, as well as the System Reset and Booting chapter in Hardware Reference Manual for in depth information. Throught the discussion we are assuming that the calling application is the one built with GCC toolchain, and the called application is the one pre-built using VDSP.

Preparing the application:

1. If running from SDRAM directly without involving BOOTROM:

Ensure that all code is mapped to SDRAM, Memory segment should be ROM type.

MEM_SDRAM0 { TYPE(ROM) WIDTH(8) START(0x00000010) END(0x0010FFFF) }

2. If running from SDRAM via BOOTOM, Include a first boot block like this:

.section bootblock;

.global _firstblock;

.byte_firstblock[16]= 0x06,0xD0,0x5B,0xAD,0x20,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00;

Changes in ldf:

RESOLVE(_firstblock,0x00000010)

RESOLVE(_main,0x00000020)

Ensure that all code is mapped to SDRAM& Memory segment should be in ROM type.

MEM_SDRAM0 { TYPE(ROM) WIDTH(8) START(0x00000010) END(0x0010FFFF) }

3. If running from Flash, Include a first boot block like this:

.section bootblock;

.global _firstblock;

.var _firstblock[4] = 0xAD7BD006,0x20000020, 0x00000010, 0x00000010;

Changes in ldf:

RESOLVE(_firstblock,0x20000000)

RESOLVE(_main,0x20000020)

Ensure that all code is mapped to Flash-ROM type (Async space). Burn this LDR using Flash programming tools.

Called Application - exit:

Since we are actually intending a return from the called application, it could just hardcode an address and return like this:

asm("P0.L = LO(0xFFA04000);");

asm("P0.H = HI(0xFFA04000);");

asm("JUMP (P0);");

Note that it is the responsibility of the called application to terminate Interrupts, DMA or anything with consequence to the calling application.

Loader properties:

The Loader exe (elf-loader) can have the following options to generate the splitter output:

‘elfloader.exe" .\Debug\LED_BLink_BF527_EZ-KIT.dxe -romsplitter -f ASCII -Width 16 -maskaddr 29 -si-revision 0.2 -proc ADSP-BF527

Use Project Options – Splitter to define the correct properties. When using Flash boot, the output can be in intel hex and when using the SDRAM, the output can be in ASCII format.

When using ASCII format, the generated file contains a sequence such as this:

00000010

000000DE

00010101

00000000

...

We only need to take the byte data stream, as the initial data is meant for post processing tools. So one can delete the following:

00000010 /* 32-bit logical address field */

000000DE /* 32-bit logical length field */

00010101 /* 32-bit control word: 2x address multiply 02 bytes logical width, 01 byte physical width */

00000000 /* reserved */

Use -meminit with basiccrt.s file for initializing data memory sections specified in the LDF.

Using the pre-built LDRs with GCC:

Use additional linker settings to map using a new use Loader Script: -T ldscript.ld -Wl,-Map=Linker.map

When the opcode are used directly, define the locations such that the application starts exactly at the location intended when preparing the LDR:

MEM_SDRAM : ORIGIN = 0x00000010, LENGTH = 1* 1024 * 1024

Since the loaded application is returning to a hardcoded instruction address, make sure that this location has the instructions for returning back to the calling application.

MEM_L1_CODE_CACHE : ORIGIN = 0xFFA04000, LENGTH = 0xC000

.textspecial :

{

*(.textspecial .textspecial.*)

} >MEM_L1_CODE_CACHE

When the LDR is already burnt to Flash, a direct jump to bootrom callable location 0xef000008 will do. When the LDR or application opcodes are residing in SDRAM, one would need to do:

__attribute__((__section__(".sdram.data")))

unsigned char ldr_dat [] =

{

#include "led_blink.ldr"

};

SDRAM Controller must be programmed before using the SDRAM. Pre-boot inside bootrom can do this when using SDRAM-boot or user can also program like below:

*pEBIU_SDRRC = 0x0407;

*pEBIU_SDBCTL = 0x25;

*pEBIU_SDGCTL = 0x0091998D;

Below are some implementations for calling the application and returning from called application gracefully:

ret_from_boot() – function for returning from boot-rom to the . It should be hardcoded at 0xFFA04000.

perform_boot_bfrom() - function for jumping in to boot-rom for SDRAM boot.

perform_boot_direct() - function for jumping in to SDRAM location to execute code directly.

Sample house-keeping routines in GCC
unsigned int sp_val; __attribute__((__section__(".textspecial"))) void ret_from_boot() { asm(" P0.L = _sp_val; \ P0.H = _sp_val; \ R0 = [P0]; \ SP = R0; \ FP = [SP++]; \ RETS = [SP++]; \ (R7:0, P5:0) = [ SP ++ ] \ RETS = R0;"); } __attribute__((__section__(".textspecial"))) void perform_boot_bfrom() { asm(" UNLINK;\ LINK 64;\ [ -- SP] = (R7:0, P5:0) \ [ -- SP] = RETS; \ [ -- SP] = FP; \ P0.L = (_sp_val);\ P0.H = (_sp_val);\ R0 = SP;\ [P0] = R0;\ R0.L = (0x6000);\ R0.H = (0xFF90);\ SP = R0;\ FP = R0;\ R0.H = 0x0000;\ R0.L = 0x0010;\ R1 = 0;\ R2 = 0;\ P0.H = 0xEF00;\ P0.L = 0x0008;\ JUMP (P0);"); } __attribute__((__section__(".textspecial"))) void perform_boot_direct() { asm(" UNLINK;\ LINK 64;\ [ -- SP] = (R7:0, P5:0) \ [ -- SP] = RETS; \ [ -- SP] = FP; \ P0.L = (_sp_val);\ P0.H = (_sp_val);\ R0 = SP;\ [P0] = R0;\ R0.L = (0x6000);\ R0.H = (0xFF90);\ SP = R0;\ FP = R0;\ P0.H = 0x0000;\ P0.L = 0x0020;\ JUMP (P0);"); }

Sample house-keeping routines in GCC

unsigned int sp_val;

__attribute__((__section__(".textspecial")))

void ret_from_boot()

{

asm(" P0.L = _sp_val; \

P0.H = _sp_val; \

R0 = [P0]; \

SP = R0; \

FP = [SP++]; \

RETS = [SP++]; \

(R7:0, P5:0) = [ SP ++ ] \

RETS = R0;");

}

__attribute__((__section__(".textspecial")))

void perform_boot_bfrom()

{

asm(" UNLINK;\

LINK 64;\

[ -- SP] = (R7:0, P5:0) \

[ -- SP] = RETS; \

[ -- SP] = FP; \

P0.L = (_sp_val);\

P0.H = (_sp_val);\

R0 = SP;\

[P0] = R0;\

R0.L = (0x6000);\

R0.H = (0xFF90);\

SP = R0;\

FP = R0;\

R0.H = 0x0000;\

R0.L = 0x0010;\

R1 = 0;\

R2 = 0;\

P0.H = 0xEF00;\

P0.L = 0x0008;\

JUMP (P0);");

}

__attribute__((__section__(".textspecial")))

void perform_boot_direct()

{

asm(" UNLINK;\

LINK 64;\

[ -- SP] = (R7:0, P5:0) \

[ -- SP] = RETS; \

[ -- SP] = FP; \

P0.L = (_sp_val);\

P0.H = (_sp_val);\

R0 = SP;\

[P0] = R0;\

R0.L = (0x6000);\

R0.H = (0xFF90);\

SP = R0;\

FP = R0;\

P0.H = 0x0000;\

P0.L = 0x0020;\

JUMP (P0);");

}

Using symbols from VDSP generated dxe:

To run code without symbols is tough, so the following might help in that case:

1. Generate symbol table via elfdump -n .symtab test.dxe

2. Reuse the VDSP generated symbols by directly defining values of these symbols in GCC LDSCRIPT.

3. Reuse the symbols (global data or functions) correctly as defined in the VDSP project.

4. Return from VDSP app via RTS.

One could extract just few required user-level symbols from the appropriate file mentioned in symbol table. Even then registers must be properly preserved.

Example code calling function label
perform_store(); load_vdsp_app(); // defined in ldscript - PROVIDE (_test_led_func = 0x20);

Example code calling function label

perform_store();

load_vdsp_app(); // defined in ldscript - PROVIDE (_test_led_func = 0x20);

operations required before calling application
__attribute__((__section__(".textspecial"))) void perform_store() { asm(" UNLINK;\ LINK 64;\ [ -- SP] = (R7:0, P5:0) \ [ -- SP] = RETS; \ [ -- SP] = FP; \ P0.L = (_sp_val);\ P0.H = (_sp_val);\ R0 = SP;\ [P0] = R0;\ R0.L = (0x6000);\ R0.H = (0xFF90);\ SP = R0;\ FP = R0;\ RTS;");\ }

How to Transfer Data Across Two EZ-KITs via USB

analogvm-admin@analog-vm.hosted.jivesoftware.com — Wed, 21 Dec 2011 15:34:17 GMT

The attached code sets up two ADSP-BF527 EZ-KITs with one acting as a USB Device and the other as a USB Host. This has been tested on revision 0.2 silicon with VisualDSP++ 5.0 Update 9. Application data transfer happens through BULK IN and OUT endpoints.You need to run the device first and then the host.

The device code uses ADI Bulk Class and has two BULK endpoints for data in and data out. The descriptors are programmed through the VSBulkConfigure() function in the adi_usb_bulkadi.c file when the application calls the command: ADI_USB_CMD_CLASS_CONFIGURE. The Device has to wait for a command block from the host to call the right API for write or read.

The Device has the opened endpoints information, but the host doesn't. The following may be employed to retrieve this data at the Host end:

1. The Host reuses the known/published Endpoint IDs to communicate with the Device:

g_ReadEpID = 0x5;
g_WriteEpID = 0x6;

2. It is however possible to retrieve the complete descriptor info, including which endpoints are configured at the Device. During enumeration, the event adi_usb_otg_SetConfiguration(1) is called to set the configuration number to be used by the Device. This function uses adi_usb_GetObjectFromID to get the configuration object which the Host is going to activate for the Device. The Host stores this configuration object as its active configuration Object. This configuration object can be used to find out which BULK Endpoints are currently used by the Device.

case ADI_USB_OTG_EVENT_ENUMERATION_COMPLETE:

         printf("\nenumeration event\n");
         usberrorcheck(adi_usb_otg_SetConfiguration(1));

         pDevO = (PDEVICE_OBJECT)pArg;
         pCfgO = pDevO->pConfigObj;
         pEpO = pCfgO->pActiveEpObj;
         pActiveEpO = pEpO;

         while(pActiveEpO != NULL)
         {
             /* BULK endpoints ONLY */
             if(pActiveEpO->pEndpointDesc->bAttributes == USB_BULK_MODE)
             {
                 if((pActiveEpO->pEndpointDesc->bEndpointAddress & 0x80))
                 {
                     g_ReadEpID   = pActiveEpO->ID;
                 }
                 else
                 {
                     g_WriteEpID   = pActiveEpO->ID;
                 }
             }

            pActiveEpO = pActiveEpO->pNextActiveEpObj;
         }

            g_bUsbenumerated = TRUE;
            break;

3.. Turn on the USB_OTG_PRINT_DESCRIPTOR and USB_DEBUG macros for USB driver libraries and rebuild them. This prints out the complete descriptor info to the console.

4. If the object IDs and endpoints (see the function ParseConfigurationMemory() in the adi_usb_otg.c file) are already known, you could do something similar to what the above macros do. If the info is not known, use method #2 to retrieve it and pass it to adi_usb_PrintDeviceDescriptor();

#ifdef DEBUG_DESCRIPTORS
   PDEVICE_OBJECT pDevO;
   PCONFIG_OBJECT pCo;
   PINTERFACE_OBJECT pIo;
   PENDPOINT_OBJECT pEpO1,pEpO2;

   adi_usb_GetObjectFromID(1,USB_DEVICE_OBJECT_TYPE,(void*)&pDevO);
   adi_usb_PrintDeviceDescriptor(pDevO); printf("\n\n");
   adi_usb_GetObjectFromID(1,USB_CONFIGURATION_OBJECT_TYPE,(void*)&pCo);
   adi_usb_PrintConfigDescriptor(pCo);printf("\n\n");
   adi_usb_GetObjectFromID(0,USB_INTERFACE_OBJECT_TYPE,(void*)&pIo);
   adi_usb_PrintInterfaceDescriptor(pIo);printf("\n\n");
   adi_usb_GetObjectFromID(g_ReadEpID,USB_ENDPOINT_OBJECT_TYPE,(void*)&pEpO1);
   adi_usb_PrintEndpointDescriptor(pEpO1);printf("\n\n");
   adi_usb_GetObjectFromID(g_WriteEpID,USB_ENDPOINT_OBJECT_TYPE,(void*)&pEpO2);
   adi_usb_PrintEndpointDescriptor(pEpO2);printf("\n\n");
#endif

Common functions like WriteMemory() and ReadMemory() are used for data transfer. The Host uses SendCommand() while the Device uses ReadCommand().

Please refer to the below references for further details and more accurate info of API usage.

--Prasanth.

Further reference:

Host example: ...\Blackfin\Examples\ADSP-BF527 EZ-KIT Lite\Services\File System\VDK\shell_browser

Device example: ...\Blackfin\Examples\ADSP-BF527 EZ-KIT Lite\Drivers\usb\bulk_loopback_app

Driver Docs: ...\Blackfin\docs\drivers\usb

USB Descriptors: http://www.beyondlogic.org/usbnutshell/usb5.shtml

Here are some screenshots:

Device:

Host:

Descriptors:

This FAQ was generated from the following discussion: How to transfer data across two EZ-KITs through USB?

Is There A Recommended DHCP Server Test for Blackfin and LwIP?

analogvm-admin@analog-vm.hosted.jivesoftware.com — Mon, 12 Dec 2011 16:44:34 GMT

DHCP (dynamic IP assignment) requires a network server / router. For quick tests with DHCP, this GUI based free software seems ideal:

http://www.dhcpserver.de/dhcpsrv.htm

http://www.dhcpserver.de/dhcpsetup.htm