Content in EngineerZone

BfSdcCalculation_Release.xlsx

analogvm-admin@analog-vm.hosted.jivesoftware.com — Thu, 17 Jan 2013 09:02:38 GMT

How Can I Boot A Blackfin Processor from an Atmel DataFlash SPI Memory Device?

analogvm-admin@analog-vm.hosted.jivesoftware.com — Wed, 28 Nov 2012 21:48:51 GMT

Atmel DataFlash memory devices require a slightly different command sequence to load data for booting. The boot kernel of some Blackfin processors (ADSP-BF531/BF532/BF533/BF538/BF539) has a special built-in mode to accommodate these needs. If the SPI master mode is selected, the boot kernel performs a device detection sequence by issuing a 0x03 command followed by a zero address to the SPI bus. The SPI then counts cycles until data other than 0xFF (due to the pull-up on MISO) is returned. If no data is returned after three address bytes are issued, the boot kernel assumes that an Atmel DataFlash device might be out there and activates the required reading mode.

The above method works fine with the AT45DBxxxB parts from Atmel. However, with Atmel’s later AT45DBxxxD family of parts, the behavior changes slightly. The AT45DBxxxD DataFlash devices respond to the 0x03 command. However, they do not meet standard SPI addressing modes because of the DataFlash’s default page size of 264, 528, or 1056 bytes (depending on the device density). As a result, the boot kernel will properly read the first page of the memory and fail in reading all other pages.

All newer AT45DBxxxD DataFlash devices support the "power-of-2" (Binary) addressing mode. In this mode, the page size is limited to standard sizes (256, 512, ... bytes). The part responds to 0x03 (and also to 0x0B) commands and, therefore, behaves like a standard 3-byte addressable SPI memory.

DataFlash devices in power-of-2 mode can boot all existing Blackfin processors.

A One-Time-Programmable Bit has to be programmed by a special command to place an off-the-shelf DataFlash device into this power-of-2 (binary) page mode. Recent DataFlash devices no longer require a subsequent power cycle in order for the power-of-2 mode to be activated once the bit has been programmed. Please consult the respective device datasheets for further details. Additionally, Atmel is offers factory-configured power-of-2 page size devices with trailing 'SL954 or SL955' part number signatures where the OTP bit is factory-programmed.

An applications article http://www.atmel.com is available for reference on ordering factory-configured power-of-2 page size devices.

More recent Blackfin boot kernels (those embedded on ADSP-BF51x, ADSP-BF50x, ADSP-BF592, ADSP-BF52x and ADSP-BF54x processors) no longer have special support for DataFlash memories. Instead, it is assumed that all customers are using the 'D' Family of devices and have the option to let the part operate in power-of-2 mode.

DataFlash® is a registered Trademark of Atmel Corporation.

FAQ: VisualDSP++ Workaround for SPI Boot Anomaly 05-00-0490

analogvm-admin@analog-vm.hosted.jivesoftware.com — Sat, 14 Apr 2012 01:12:21 GMT

Anomaly 05-00-0490 requires a very specific timing element that is unfortunately possible to encounter through normal boot ROM execution. While the software workaround is a simple fix, it is obviously not possible to modify the ROM code itself. However, all the processors susceptible to this anomaly also feature the ability to register a "custom boot handler"...if the custom boot handler is exactly the boot ROM code with these minor tweaks, this anomaly is avoided altogether (even for SPI_BAUD=2). The attached ZIP file contains the corrected code to be linked into your project as part of the initialization block to avoid anomaly 05-00-0490, as well as guidance for using it and augmenting it with other initialization customizations that your application may require (changing clock speeds, initializing the external memory interface, etc.).

However, additional protection beyond the custom boot handler is required to prevent the init block itself from encountering the same anomaly, which requires modification of the loader file (LDR) output image containing the application boot stream. The Workaround_Description.pdf file in the attached ZIP archive contains the details regarding the nature of the changes required and how to go about making the changes (based on which revision of VisualDSP++ is being used).

FAQ: I'm interested in the Blackfin processor family but don’t know where to start?

analogvm-admin@analog-vm.hosted.jivesoftware.com — Tue, 20 Mar 2012 10:21:23 GMT

Question: I'm interested in the Blackfin processor family and want to begin evaluating. Where should I begin?

Answer: Firstly, we suggest that you download the 'Getting Started with Blackfin Processors' manual from the following web page:

http://www.analog.com/en/embedded-processing-dsp/Blackfin/processors/get_started_with_Blackfin/fca.html

This manual introduces the Blackfin processor family, discusses the evaluation process, selecting the appropriate software and hardware, and presents the support options available from ADI.

You can begin using VisualDSP++, the debugging environment for ADI processors, right away by registering for, and downloading, a free 90-day Test Drive: www.analog.com/blackfin/testdrive

Note: A Test Drive license enables emulator debug sessions and simulator debug sessions only.

Once VisualDSP++ 5.0 is installed we recommend following the exercises in the 'VisualDSP++ 5.0 Getting Started Guide'. The Guide is available within VisualDSP++ HELP or from the ADI website at: www.analog.com/processors/manuals

This guide provides basic and advanced tutorials that highlight many VisualDSP++ features. By completing the step-by-step procedures, you will become familiar with the VisualDSP++ environment and learn how to use these features in your own digital signal processing (DSP) development projects.

On the Manuals page you will find all available Blackfin processor and software manuals. Under the Evaluation Kit Manuals section you will not only find manuals for all Blackfin EZ-KITs but Getting Started Guides for the ADSP-BF537 and ADSP-BF548 processors. These Getting Started Guides are intended to familiarizes users with the hardware capabilities of the evaluation system and demonstrates how to access these capabilities in the VisualDSP++ environment.

Should you have any further questions please visit the Blackfin Processors homepage: http://www.analog.com/blackfin

Or contact VisualDSP++ tools support online: http://www.analog.com/processors/support

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

Trouble Transferring16-Bit Data on Blackfin SPORT

analogvm-admin@analog-vm.hosted.jivesoftware.com — Wed, 30 Nov 2011 16:53:04 GMT

Q: We are using the BF533 and BF561 Blackfin processors in our project, and we cannot seem to transfer data over the SPORT data transmit pin DT0PRI when we configure the SPORT for 16-bit data or smaller. No data comes out at all! The same code works fine if the SPORT is configured for 17-bit data or larger, as the data is seen on the DT0PRI pin as expected. We are using core loads to the SPORT FIFO in C, as follows:

short myData[4] = 0x0001, 0x0002, 0x0003, 0x0004;

volatile char i;

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

*pSPORT0_TX = myData[i];

Can you explain what we are doing wrong?

A: The SPORT data registers (SPORTx_TX and SPORTx_RX) are the only registers in the Blackfin memory map that must support both 32-bit and 16-bit accesses, and the correct access width is dependent on the SLEN field in the SPORTx_TCR2 register. It is on the programmer to access the MMR with the correct width. The C headers that are provided with the tools set up macros to define the proper access widths for all the registers in MMR space, but this is not possible when the width can be either. As such, the default pSPORT0_TX macro is defined to support a 32-bit access, but we've provided special alternate macros to support 16-bit access to the same MMR address. If you look in the header file for your processor (e.g., the cdefbf561.h file for the BF561), you will see how the SPORT data registers are defined:

#define pSPORT0_TX         ((volatile unsigned long *)SPORT0_TX)
#define pSPORT0_RX        ((volatile unsigned long *)SPORT0_RX)
#define pSPORT0_TX32     ((volatile long *)SPORT0_TX)
#define pSPORT0_RX32     ((volatile long *)SPORT0_RX)
#define pSPORT0_TX16     ((volatile unsigned short *)SPORT0_TX)
#define pSPORT0_RX16     ((volatile unsigned short *)SPORT0_RX)

The "long" type creates a 32-bit access, whereas the "short" is a 16-bit access. You need to use the macro with the "16" suffix for 16-bit data and smaller. What is happening in the hardware when you have the 32-bit access is that the write is not making it to the FIFO because it is misaligned, so when the SPORT is enabled, there is nothing in the FIFO and nothing is transmitted.

FAQ: Using the Blackfin SDP-B as a BF527 Evaluation Platform

analogvm-admin@analog-vm.hosted.jivesoftware.com — Tue, 01 Nov 2011 16:04:00 GMT

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.

For more information see: http://www.analog.com/sdp

Question

I want to use the SDP-B board as a Blackfin Evaluation board; what are my options, what do I need, and where do I start?

===========================================

Answer

To use the SDP-B as a Blackfin BF527 evaluation platform, there are a couple of options available to you. You can use the GCC Tools, or the VisualDSP++ tools to develop for this target. This FAQ covers the use of the VisualDSP++ tools. If you plan on using the GCC Tools, please refer to the following FAQ in the Open Source Platform and Software community of the EngineerZone:

FAQ: Getting Started with SDP-B using GCC Toolchain

For further information see these Bare Metal instructions on the Blackfin uClinux page:

http://docs.blackfin.uclinux.org/doku.php?id=toolchain:bare_metal

To use the SDP-B with VisualDSP++ you will need to set up the SDP-B hardware by adding a JTAG Header (earlier SDP-B boards only), get a JTAG Emulator, install and license the VisualDSP++ tools, then configure the tools for use with the SDP-B. Finally, we have an example project as a starting point. Each of these steps is covered in detail below:

Set up the SDP-B Hardware

The first step in using the SDP-B with VisualDSP++ is to configure the hardware appropriately. Early revisions of the SDP-B board do not have a JTAG header, so you will need to solder a JTAG header onto J3 “JTAG” on the SDP-B PCB.

Get a JTAG Emulator

VisualDSP++ requires an ADI JTAG Emulator to communicate with the target, of which there are 3 options. The ADZS-USB-ICE, ADZS-HPUSB-ICE, and the ADZS-ICE-100B. More information is available here:

http://www.analog.com/processors/usb/emulator

http://www.analog.com/emulator-100

Get the VisualDSP++ Tools and a License

You can download VisualDSP++ 5.0, together with the latest update, from the following page of our website. Ensure that you download and install the latest update for SDP support:

http://www.analog.com/processors/tools/update

You can apply for a 90-day Blackfin test drive license for our tools via the link below, or purchase a full license from your local distributor, whose details are available from the second link below:

http://www.analog.com/blackfin/testdrive

http://www.analog.com/salesdir/continent.asp

For detailed instructions on installing and registering VisualDSP++ licenses, please see the VisualDSP++ 5.0 Licensing Guide here:

http://www.analog.com/vdsp50_lic_guide

Configure VisualDSP++ for the SDP-B

With the tools installed and licensed, you simply need to create a session via ‘Session’->’New Session’.

1. Click on the “Session” menu, select “New Session”.

2. Select “Blackfin” as the ‘Processor Family’, then select “ADSP-BF527” under ‘Choose a target processor’.

3. On the next page, Select “Emulator” as your connection type.

4. On the next page, select the Platform that matches your choice of Emulator.

5. Click “Finish” to create your Session, and connect to the target.

The next step is to ensure that the EBIU is correctly configured so that you have access to the SDRAM on the target. If you do not follow this step, you will encounter unpredictable behaviour and exceptions if you attempt to make use of SDRAM.

1. Go to ‘Settings: Session’, and check the box “Enable Customizations”.

2. Under ‘Custom board support file name’ click the Browse (“…”) button, browse to the VisualDSP++ installation directory (default “C:\Program Files\Analog Devices\VisualDSP 5.0\”), then to “…\Blackfin\Examples\BF527-SDP-HW\BF527-SDP-HW.XML”, and choose “Open”.

3. Click “OK” and the VisualDSP++ tools should inform you that “Your changes won’t take effect until you disconnect and reconnect to the target, or restart the IDDE. Would you like to disconnect and reconnect to the target now?”. Select “Yes”, the VisualDSP++ will disconnect and reconnect, and you are ready to work with the SDP under VisualDSP++.

Example Project

Attached is an example project as a starting point. This project is for the SDP-B Board only, and does not consider the Break-out Board. In short, the program does the following:

1. Basic C code Initialization of EBIU.

2. Initialization of SDRAM Controller via System Services.

3. Configuration of PLL via boot-rom API.

4. Configuration of SCLK and CCLK via system services.

5. Initialization of GPIO via system services.

6. Read of Unique-ID & Part Number from OTP Memory.

7. Initialization and toggle of LED1.

8. Initialization of USB libraries for std-out via USB.

To use this project, unzip the "SDP_POST.zip", then unzip the "SDP_INITCODE.zip" contained within. Open the Project in VisualDSP++ and go to Project Options: Load and set the "Initialization File" by browsing to the "SDP_INITCODE.dxe" extracted from this zip file.

When the Windows 'New Hardware Wizard' starts, direct it to the driver in the VisualDSP++ installation at "...\Blackfin\Examples\usb\host\windows\drivers\"

FAQ: How do I restore the original SDP image to flash on my SDP board?

analogvm-admin@analog-vm.hosted.jivesoftware.com — Tue, 01 Nov 2011 16:03:59 GMT

For more information see:www.analog.com/sdp

Before proceeding, determine which version of the SDP-B board you have, and contact private support through the link below to obtain the Loader Image (*.ldr) for your target.

http://www.analog.com/processors/support

Please ensure you have followed the steps in FAQ: Using the Blackfin SDP-B as a BF527 Evaluation Platform to set up your development environment to use the SDP-B with VisualDSP++, then follow the steps below.

To restore the SDP-B image to flash you will also need the Flash Programmer Interface Application *.dxe file for the EEPROM. The Rev B. board uses the M29W320EB Parallel Flash part, while the Rev 1.3 uses the M25P32 Serial Flash. Please ensure you use the correct Flash Programmer Interface Application DXE.

You can use the Flash Programmer Interface Applications for the BF527 EZ-KIT Lite, with a little modification, on the SDP-B. These are located in the VisualDSP++ installation under the directory "...\Blackfin\Examples\ADSP-BF527 EZ-KIT Lite\Flash Programmer\". The required Modifications are as follows:

Parallel Flash (SDP-B Rev. B)

To enable access to the flash you need to clear the PortG registers as follows:

*pPORTG_FER &= ~0x0001;

*pPORTGIO_CLEAR = 0x0001;

*pPORTGIO_DIR |= 0x0001;

Serial Flash (SDP-B Rev 1.3)

The only difference between the M25P32 Serial Flash on the SDP-B and the M25P16 Serial Flash on the EZ-KIT Lite is capacity; the former is 32MB while the latter is 16MB. You can use the default BF527 EZ-KIT Lite Serial Flash driver, though this will only give access to the lower 16MB of the Flash. Access to the full 32MB requires a single change.

Note: This requires modifying the actual device driver at "...\Blackfin\lib\src\drivers\flash\M25P16\adi_m25p16.c" - i.e. this will affect all Flash Programmer Interface Applications that use this driver, including the one for the BF527 EZ-KIT Lite, if they are rebuilt against the modified source file.

Simply change the following line:

#define NUM_SECTORS 32

#define NUM_SECTORS 64

Using the Flash Programmer to Restore the Image

Within the VisualDSP++ IDDE, connect to your SDP-B session, then open the Flash Programmer Utility via ‘Tools: Flash Programmer’
Under ‘Driver File’ click “Browse”
Navigate to the location of the Flash Programmer Interface Application *.dxe file. Click “Open” to choose this file
Click “Load Driver” and, after a few moments, the Flash Information and Driver Information should be populated, and the message “Success: Driver Loaded” displayed in the Message Center
Click on the “Programming” tab
Select “Erase Affected” under ‘Pre-program erase options’, and “Intel Hex” under ‘File Format’
Select “Browse” under ‘Data File’
Navigate to the location of the SDP-B Flash Image *.ldr file, and click “Open” to choose this file
If you wish, check the box to “Verify while programming”, then click “Program”
Once the programming has completed, select “OK” to close the programmer, quit VisualDSP++ and power-cycle the target. The SDP-B image will boot from flash and you will be able to use your target as part of the SDP-B Evaluation platform once again.

FAQ: How do I reconcile Blackfin SPI serial clock phase control (CPHA) settings with potentially conflicting hardware/software slave select modes, when both these attributes are managed by the same control bit?

analogvm-admin@analog-vm.hosted.jivesoftware.com — Wed, 21 Sep 2011 08:23:16 GMT

By definition, the clock phase control bit is used to manage whether data is sampled on the leading or trailing clock edge. But this bit is also used to manage whether the slave select output pin is driven by hardware or software. These two attributes are sometimes in contention. (Note that in hardware slave select mode, the select line is toggled between bytes which can cause an unintentional slave device reset.)

Most Blackfin SPI hardware implementations provide both serial clock phase (CPHA) and serial clock polarity (CPOL) control bits within the SPI_CTL control register. These two serial clock control bits configure the SPI protocol to use one of four industry standard SPI clocking modes to suite external slave device timing requirements.

But the serial clock phase (CPHA) control bit also controls programming of the slave select pin to be generated either: automatically, i.e., using the SPI hardware slave select mode (where CPHA=0); or, in the software mode by application software (where CPHA=1). Note that in the software mode, the application will directly manipulate an explicit flag pin around each SPI transfer. So in addition to controlling the clock phase, the CPHA bit also controls selection of the hardware/software slave select mode.

Because the hardware slave select mode (CPHA=0) may (depending on protocol speed) deassert and reassert the slave device select line between each byte of the transfer, some slave devices may interpret this transition as a slave reset request which may interfere with a block transfer.

In cases where the slave device requires use of CPHA=0 on the Blackfin SPI master-mode controller (implying use of the hardware slave select mode), the slave select “reset” between bytes can be avoided by combining the needed hardware select (CPHA=0) mode with a software-driven slave select technique. This solution requires the associated slave select function be disabled in the function enable register (FER) for the port and pin in question and that the application software take responsibility for driving the slave select pin as if CPHA=1 (software slave select mode) were active. In short, the application programs the slave select pin “manually” (via the flag service) by manipulating the select before and after each transaction (DMA or otherwise): assert the select just prior to the SPI enablement and deselect it at the transaction completion or DMA interrupt.

TAR-45231 describes a feature request to support this workaround in the SPI Device Driver.

http://www.analog.com/processors/tools/anomalies