Booting an application from internal flash in BF50xF processors

Document created by WassimB on Jan 14, 2010Last modified by CraigG on May 19, 2011
Version 7Show Document
  • View in full screen mode

Q)

 

How do I build an application such that it will boot completely out of the internal parallel FLASH on the BF504F and the BF506F processors?

 

----

 

A)

 

When booting an application completely out of flash, the emulator is not involved in loading the code and data sections from a (.DXE) executable file into internal memory. Instead, the boot ROM parses a loader file (.LDR) that is stored in FLASH and loads the code and data sections from that loader file into internal memory. We distinguish between two parts of an application:

   1. The first part contains the sections  of an application that will remain, at runtime, in FLASH. The boot ROM does not need to parse these sections because they are already in the location where they need to reside at.

   2. The second part contains the sections  of an application that will reside, at runtime, in internal SRAM memory. Those are the sections that the boot ROM parses at boot time.


When developping an application to boot completely out of flash, each of the above two parts should be prepared into a loader file (.LDR):

  1. Loader file 1 contains the code and data  sections that will remain, at run-time, in flash. As of  the "Update for  ADSP-BF506 EZ-KIT and ADSP-BF527 EZ-KIT rev 2.2 Only -  March 2010" VisualDSP++ Tools update, the software tools automatically generate this loader file when a software project is built, and automatically programs this loader file into flash when the software project is loaded. This is further explained in " FAQ: ADSP-BF506F FLASH Tutorial"


  2. Loader file 2 contains the code  and data sections that will reside at run-time in internal memory. This loader file needs to be prepared manually as discussed later in this FAQ and needs to be programmed in FLASH starting at location 0x2000_0000, which is where the boot ROM expects this loader file to reside at boot time.

 

When code and/or data sections are mapped to flash, for example by preceeding them in the source file with the directive #pragma section("FLASH_code"), the software tools automatically generate Loader file 1 out of those code and/or data sections. By default, the software tools prepare Loader file 1 to reside in 0x2000_0000. However, since when booting completely out of flash Loader file 2 needs to reside at location 0x2000_0000, the following changes needs to be made to the default LDF file:


Replace the following line in the LDF file (Note that as of VisualDSP++ 5.0 Update 8 of June 2010, the LDF already includes this change):

     MEM_FLASH               { TYPE(ASYNC0_MEMTYPE) START(0x20000000)  END(0x203FFFFF) WIDTH(8) }

with the following two lines:

     MEM_FLASH_BOOT    { TYPE(ASYNC0_MEMTYPE) START(0x20000000) END(0x2001FFFF) WIDTH(8) }

     MEM_FLASH               { TYPE(ASYNC0_MEMTYPE) START(0x20020000) END(0x203FFFFF) WIDTH(8) }


This reserves a MEM_FLASH_BOOT memory region at the beginning of flash to be used for storing Loader file 2.


 

When building and loading an application that maps code and/or data into flash sections, as shown in the main source file of a LED blinking project below, the software tools will automatically generate Loader file 1 out of the routine "ClearSet_LED_inFlash" and will place in flash starting at address 0x2002_0000.

 

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

#define LED2 0x0001
#define LED3 0x0002
#define LED4 0x0004

 

#pragma  section("L1_code")
/*******************************************************************
*     Function:    ClearSet_LED
*   Description: Clear or set a  particular  LED (NOT A GROUP).
*******************************************************************/
void   ClearSet_LED_inRAM(const int led, const int bState)
{
    /* if   bState is 0 we clear the LED,
       if bState is 1 we set the LED,
         else we toggle the LED */

 

       if( 0 ==  bState )
    {
        *pPORTFIO_CLEAR = led;
     }
     else if( 1 == bState )
    {
        *pPORTFIO_SET =  led;
     }
    else
    {
        *pPORTFIO_TOGGLE = led;
     }

}

 


#pragma  section("FLASH_code")
/*******************************************************************
*     Function:    ClearSet_LED
*   Description: Clear or set a  particular  LED (NOT A GROUP).
*******************************************************************/
void   ClearSet_LED_inFlash(const int led, const int bState)
{
    /*  if  bState is 0 we clear the LED,
       if bState is 1 we set the  LED,
        else we toggle the LED */

 

        if( 0 == bState )
    {
        *pPORTFIO_CLEAR = led;
     }
     else if( 1 == bState )
    {
        *pPORTFIO_SET =  led;
     }
    else
    {
        *pPORTFIO_TOGGLE = led;
     }

}

 

int  main( void )
{
    /* LED2 uses PF0, LED3 uses PF1, LED4 uses   PF2 */

 

    *pPORTF_FER            &= (~(PF0 | PF1 |  PF2));    /* Setup for  LEDs */
    *pPORTFIO_DIR        |= (PF0 |  PF1 | PF2);        /*  Setup port for output */
    *pPORTFIO_CLEAR         = (PF0 | PF1 |  PF2);        /* Turn all LEDs off */
   
     while(1) {       
     ClearSet_LED_inFlash( LED2, 0x1);
     ClearSet_LED_inFlash( LED3,  0x0);
    ClearSet_LED_inRAM( LED4,  0x1);
    }
    //return 0;

}

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

 

The following steps show the procedure for generating Loader file 2:


Modify the VisualDSP project settings to generate a loader file of the RAM code sections.

a. Click Project –> Project Options… This will display the Project Options window

b. On the Project property page, select Loader file from the drop down menu next to Type.

c. On the Load:Options property page,  ensure that the following options are selected:

     i. Boot Mode is set to Flash/PROM

     ii. Boot Format is set to Intel  hex

     iii. Output Width is set to 16-bit

d. On the Load:Splitter property page, ensure that Enable ROM splitter is not selected and click OK to  save.

e. Click Project –> Build Project to build the  project

f. Program the FLASH as follows:

     i. In VisualDSP, select Tools –> Flash Programmer.

     ii. In the Flash Programmer window, under the Driver tab, browse to the flash programmer driver, which is - at the time of this writing - located at: <VisualDSP installation directory>\Blackfin\Examples\ADSP-BF506F EZ-KIT Lite\Flash Programmer\BF50x4MBFlash\BF506FEzFlashDriver_BF50x4MBFlash.dxe

     iii.Click on Load Driver

     iv. Once the driver is loaded, select the Programming tab and browse to the LDR file that you just created in step e of these instructions.

     v. Ensure that the appropriate selection is made under Pre-program erase options. The appropriate selection is usually Erase affected. refer to the IMPORTANT NOTE below for more information.

     vi. Click on Program

 

Once both Loader files are generated and programmed in flash, (Loader file 1 is automatically generated and programmed by the software tools when the project is built and loaded, and Loader file 2 is manually generated and programmed as explained in the previous steps), the EZ-KIT's appropriate boot mode (boot from internal flash memory) may now be set and and EZ-KIT power may be cycled in order for the application to boot completely out of flash. When the power is cycled, the processor will boot, the loader file that was generated using the steps above (loader file 2) will be parsed  by the on-chip boot ROM and will be loaded into internal memory and the  execution will begin.

 

 

IMPORTANT NOTE: Since the flash  is erased at a block granularity, it is important to ensure that when the two loader files are programmed into flash, they do not erase a  block that the other loader file occupies. In the above example, we set the memory ranges in the LDF file appropriately such that the two loader files will not share any flash blocks. In practice, there are two ways to ensure that programming one of the two loader files does not erase the other:

  1. The two loader files do not share any flash blocks.
  2. The two loader files do share a flash block,  but programming the 2nd loader file does not require the  erasure of the shared block. If the      destination FLASH memory  regions of the 2nd loader file were already erased, then this  may be done in the Flash Programmer interface by checking No  erase in the Programming tab.

Attachments

    Outcomes