Post Go back to editing

Simple program to test ADSP-21488

Hello, could any one show example how to test my setup ?
( i made flash programmer, and development board,25MHz CLK, Boot config SPI_MASTER (01), and CLK konfig is 00)
In loader setup, should i sue SPI_FLASH, or SPI_MASTER ?

my program looks like this:

#include <def21488.h>

#include <cdef21488.h>

#include <math.h>

#include <SRU.h>

#include <asm_sprt.h>

asm("#include <def21489.h>");

#define NOP asm volatile("nop;")

void initPLL(void);

void Mandelbrot(float zoom);

int main( void )

{

    initPLL();

    asm("bit clr FLAGS FLG1;"); //CS LOW

    asm("bit set FLAGS FLG1;");//CS HIGH”

   

     while(1)

     {

        asm("bit clr FLAGS FLG1;"); //CS LOW

        asm("bit set FLAGS FLG1;");//CS HIGH”

      }

   

}

void initPLL(){

int i, pmctlsetting;

    // Set INDIV bit in PMCTL register

    pmctlsetting = *pPMCTL;

    pmctlsetting |= INDIV;

    *pPMCTL= pmctlsetting;

    // Program PLL multiplier to same value as CLK_CFGx pins/previously programmed value in software……

    *pPMCTL = pmctlsetting;

    // then place PLL in bypass mode

    pmctlsetting |= PLLBP;

    *pPMCTL = pmctlsetting;

    //Wait for recommended number of cycles

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

          NOP;

    // Bring PLL out of bypass mode by clearing PLLBP bit

    *pPMCTL ^= PLLBP;

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

          NOP;

    pmctlsetting = *pPMCTL;

    // Clear the previous PLL multiplier

    pmctlsetting &= ~PLLM63;

    // Clear the INDIV bit

    pmctlsetting &= ~INDIV;

    // or set the INDIV bit

    // *pMCTL |= INDIV;

    *pPMCTL= pmctlsetting;

   

    // CLKIN= 25 MHz, Multiplier= 16, Divisor= 2, CCLK_SDCLK_RATIO 2.5.

    // Fcclk = (CLKIN * 2 * M) / (N * D)

    // VCO frequency = 2*fINPUT*PLLM = 2*25*16 = 800 <= fVCOmax (800 MHz)

    // M = 1 to 64, N = 2,4,8,16 and D = 1 if INDIV = 0, D = 2 if INDIV = 1

  

    pmctlsetting=SDCKR2_5|PLLM16|DIVEN|PLLD2;

    *pPMCTL= pmctlsetting;

    pmctlsetting|= PLLBP;    //Setting the Bypass bit

    pmctlsetting^= DIVEN;    //Clearing the DIVEN bit

    *pPMCTL= pmctlsetting;    // Putting the PLL into bypass mode

    //Wait for around 4096 cycles for the pll to lock.

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

          NOP;

       pmctlsetting = *pPMCTL;

    pmctlsetting ^= PLLBP;          //Clear Bypass Mode

    *pPMCTL = pmctlsetting;

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

          NOP;

  

}
Problem, i don't get any FLAG1 toggle, and i really don't know why,  (Photo of home made board for ADSP-21488, later it will be used in my master degree work, in university)

Parents
  • Hi Linus,

    Sorry for the delay in answering .

    Did the code run properly through an Emulator . If the code failed to run through an emulator , we cannot say this as a booting problem .

    If you are able to load and execute the application using a JTAG ICE, but is unable to execute the applications when boot-loaded, consider the following points while debugging:

    • Check the BOOTCFG pins of processor and ensure that they are properly connected to digital voltage level high or level low. When resistors are used to provide flexibility to change boot mode, ensure that the right ones are populated.
    • Ensure that the /TRST signal of the JTAG ICE is connected to board ground. Do not leave this signal floating. Letting this signal float may cause boot failures or other memory access failures.
    • Ensure that the correct boot kernel is used before generating the loader (.LDR) file. If you are using a modified boot kernel, try using the default boot kernel supplied with Visual DSP++Registered together with an example application (like flag toggle) to confirm basic boot-loading.
    • Ensure that you have selected the correct parameters while generating the .LDR file. Selecting an inappropriate parameter may cause the boot to fail.
    • Check whether the code boot-loaded using an ICE (in-circuit emulator). Connect the ICE to the target and open a simulator session in Visual DSP++. Turn on the target to start boot-loading. Change the session from “simulator” to “emulator” and look at the Disassembly window. This shows whether the application boot-loaded from the external source. If you do not see the expected code, there is a boot failure. You can also use this method to check whether the processor downloaded the initial 256 instructions.
    • Ensure correct power on reset timings as specified in the data sheet.
    • Check the CLKCFG signals and ensure that the PLL is not overdriven. Ensure that the ratio selected in combination with the CLKIN frequency does not exceed the core clock to a value greater than specified.
    • Check for the integrity of tracks on the board as there may be open circuits or short circuits on the board. You can also monitor RSTOUT to confirm the PLL lock

    Also refer to the Application  note given in the following link:

    1. EE-223 :In-Circuit Flash Programming on SHARCRegistered Processors

    http://www.analog.com/static/imported-files/application_notes/EE.223.In.Circuit.Flash.Programming.on.SHARC.Processors.Rev.2.02.07.pdf

    1. EE-305 :Designing and Debugging Systems with SHARCRegistered Processors

    http://www.analog.com/static/imported-files/application_notes/EE-305.pdf

    Regards,

    Mahesh

Reply
  • Hi Linus,

    Sorry for the delay in answering .

    Did the code run properly through an Emulator . If the code failed to run through an emulator , we cannot say this as a booting problem .

    If you are able to load and execute the application using a JTAG ICE, but is unable to execute the applications when boot-loaded, consider the following points while debugging:

    • Check the BOOTCFG pins of processor and ensure that they are properly connected to digital voltage level high or level low. When resistors are used to provide flexibility to change boot mode, ensure that the right ones are populated.
    • Ensure that the /TRST signal of the JTAG ICE is connected to board ground. Do not leave this signal floating. Letting this signal float may cause boot failures or other memory access failures.
    • Ensure that the correct boot kernel is used before generating the loader (.LDR) file. If you are using a modified boot kernel, try using the default boot kernel supplied with Visual DSP++Registered together with an example application (like flag toggle) to confirm basic boot-loading.
    • Ensure that you have selected the correct parameters while generating the .LDR file. Selecting an inappropriate parameter may cause the boot to fail.
    • Check whether the code boot-loaded using an ICE (in-circuit emulator). Connect the ICE to the target and open a simulator session in Visual DSP++. Turn on the target to start boot-loading. Change the session from “simulator” to “emulator” and look at the Disassembly window. This shows whether the application boot-loaded from the external source. If you do not see the expected code, there is a boot failure. You can also use this method to check whether the processor downloaded the initial 256 instructions.
    • Ensure correct power on reset timings as specified in the data sheet.
    • Check the CLKCFG signals and ensure that the PLL is not overdriven. Ensure that the ratio selected in combination with the CLKIN frequency does not exceed the core clock to a value greater than specified.
    • Check for the integrity of tracks on the board as there may be open circuits or short circuits on the board. You can also monitor RSTOUT to confirm the PLL lock

    Also refer to the Application  note given in the following link:

    1. EE-223 :In-Circuit Flash Programming on SHARCRegistered Processors

    http://www.analog.com/static/imported-files/application_notes/EE.223.In.Circuit.Flash.Programming.on.SHARC.Processors.Rev.2.02.07.pdf

    1. EE-305 :Designing and Debugging Systems with SHARCRegistered Processors

    http://www.analog.com/static/imported-files/application_notes/EE-305.pdf

    Regards,

    Mahesh

Children
No Data