This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C5515 ezDSP standalone operation

Other Parts Discussed in Thread: MSP430BT5190

I've been trying to get the c5515 ezDSP to run standalone and I've looked through other forum posts and the wiki
about how to do this. I ported code from the GEL file into C code, and also included the same initialization steps from
the sample code provided by Spectrum Digital as suggested in the other forum posts and the wiki.


The code I am uploading to the board passes audio from the input straight to the output, but with the initialization
code added, I hear nothing from the output. There is no difference when I create a *.bin file and upload this to the board.

When I step through in debug mode, the program hangs after attempting to initialize the AIC3204 codec.

I am using CCS v5.1.1.00033 for Linux.


The code looks like this:

initialize(){
    program_pll();
    config_port();
    SYS_GlobalIntEnable();
    

    IER0 = 0x0010;      // enable timer int
    IER1 = 0x0004;      // enable RTC int

    Timer0Init();


    reset_RTC();
    enable_rtc_second_int();
  

//hangs at this line:

    aic3204_hardware_init();
    aic3204_init();
    set_sampling_frequency_and_gain(44100, 20);
  

//also hangs if using this function from the sample code
//AIC3254_init();

   set_i2s0_slave();
    enable_i2s0();
    

    StartTimer0();
    SYS_EXBUSSEL = 0x6100;
    USBSTK5515_ULED_init();
    SAR_init();
}

void program_pll(){
    Uint16 i;

    //bypass the pll
    CLKCFGMSW = 0x0;

#if (PLL_100M ==1)
    CGCR2 = 0x8000;
    CGCR4 = 0x0000;
    CGCR3= 0x0806;
    CGCR1 = 0x8BE8;

#elif (PLL_12M ==1)
    CGCR2 = 0x8000;
    CGCR4 = 0x0200;
    CGCR3 = 0x0806;
    CGCR1 = 0x82ED;
#elif (PLL_98M ==1)
    // 98.304 MHz
    CGCR2 = 0x8000;
    CGCR4 = 0x0000;
    CGCR3 = 0x0806;
    CGCR1 = 0x82ED;

#endif


    while ( (CGCR3 & 0x0008) == 0);
      // Switch to PLL clk
      CLKCFGMSW = 0x1;

  // clock gating
  // enable all clocks
      SYS_PCGCR1 = 0;
      SYS_PCGCR2 = 0xFF84;


  // reset peripherals
      SYS_PRCNTR  = 0x02;
      SYS_PRCNTRLR = 0x00fb;
      for (i=0; i< 200; i++);
}


void config_port(){
    //  configure ports
    SYS_EXBUSSEL = 0x6900;        // parallel port: mode 6, serial port1: mode 2, serial port0: mode1
}

void SYS_GlobalIntEnable(void)
{
    asm(" BIT (ST1, #ST1_INTM) = #0");
}


Uint16 fTimer =0;

void Timer0Init(void)
{

    /*  Timer0 Initialization */
// timer interval 0.5sec (2Hz)
// prescale = 1011 (devide by 4096)
// 98.304M/4096 = 24K
// 24K/12K = 2Hz (12K = 0x2EE0)

    /* TIM0 EN | AutoReload disable | Prescale = 0(100/2 = 50MHz) ==> 20nsec */
    CPU_TIM0_CTRL = 0x802E;     // autoReload
    //*CPU_TIM0_CTRL = 0x802C;     // disable autoReload

    CPU_TIM0_PLWR = 0x2EE0;
    CPU_TIM0_PHWR = 0x0000;

    CPU_TIM0_CLWR = 0x0000;
    CPU_TIM0_CHWR = 0x0000;

    /*  Clearing timer Aggregation register*/
    CPU_TIMINT_AGGR = 0x0007;

    /*  enable timer0 int flag*/
    CPU_TIM0_IER = 0x0001;
}


Any insight as to what might be causing the AIC codec initialization to hang?

Thanks,
Andrew

  • Andrew,

    I am having somewhat similar issue (boot from flash, output audio does not work). Did you ever figure out what was happening?

  • Hi MikeH,

    Unfortunately I haven't figured this out. I emailed the TI support but they redirected me to the forums.
    I also tried opening a ticket on the Spectrum Digital Help Desk, no response yet.

    I was trying out different initialization steps and flashing them onto my board. In the process,
    something in the flash or bootloader was corrupted and I can no longer connect to the ezDSP
    board in CCS. Not sure how I can "manually" erase whats on the flash and continue working
    on the board. The TI support has been pretty sparse. I think I might just stop by the TI office in
    Toronto to see if I can get some help there.

    This has been pretty frustrating. If you have any leads about this, please share!

    Thanks,
    Andrew

  • Andrew,

    Thanks for the feedback. I will certainly share any info I come up with.

    I get the distinct feeling that TI is slow-rolling the C55xx product line. If you take a look a the frequency of posts by TI employees on this forum you will see what I mean. For the past month or two there have been very few posts the give in-depth technical support. Most of the posts suggest that you read to documentation or the Wiki, which in most cases do not answer the question.

    I'll keep you post on my progress.....or lack thereof. Good luck.

  • Andrew,

    I found a solution that works for me. Give these thread a look.

    http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/p/134794/484531.aspx#484531

    http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/p/126035/462564.aspx

    I hope you have good luck also..............despite TI's complete lack of interest in supporting its customers.

  • Hi MikeH,

    Thanks for the links. I did come across these and did try adding these steps to my code, but had no luck. I will try this again
    if I can communicate with/program the board again. I'll need to find a way to manually wipe the corrupted program on the flash first.

    Thanks again,
    Andrew

  • Andrew,

    I'm not sure which bootloader you are using, but the C5515 bootloader is in ROM and can't be corrupted (without damaging the ROM). You should be able to connect to the board by launching a debug session and using the original GEL file to initialize the C5515. The debug session should halt the processor and give you access to the chip regardless of what is in flash memory, even if it is corrupt.

    Once you are able to connect to the C5515 you can run the "programmer" application which erases the flash chip and flashes new code into it. http://processors.wiki.ti.com/index.php/C5515_Boot-Image_Programmer

  • Hi Mike,

    I am trying to Flash my eZDSP C5515 and am facing some issues. My code has SPI and UART communications with other MSPs. It works perfectly when i run from CCS but when i flash , it works for sometime and stops. I have included the PLL clock initialization , peripheral reset and the Idle registers initialization in my main function. Please provide any suggestions . I have been stuck with this issue for quite sometime.

  • Dilip,

    What is it that "works"? What "stops"? If something works, even for a short time, your flash sounds like it worked properly. There may be some sort of timing (interrupt, DMA, etc) that changes when you run without an emulator attached.

  • Hi Mike,

    Thanks for the reply. The DSP is configured to communicate with an MSP430 using SPI and with a GSM/GPRS module using UART. It takes data from GPRS module and passes it onto MSP. And then it takes data from MSP and passes it to GPRS module. The MSP is MSP430BT5190 and the reference board is eZ430 RF2560. The communication module is TELIT GL865(dono if you know this but just sharing). This setup works when run using CCS. When run with flashed code, after sometime it doesn't pick up the data from UART.

  • You'll need to determine which part of the chain is failing. Have you monitored the UART signals to see if they look correct (i.e. voltage levels, timing, etc)? Is the SPI working when the UART fails? Can you write a simple program that streams data to/from the radio as a test? 

    FYI, you should be able to connect to your target board with CCS, which will halt  your flashed program, then load the symbols into CCS and step through the program to see what is going on. Sometimes this will allow you debug a program loaded from flash by using CCS.

  • Hi Mike,

    I have tested the individual parts in the chain. The UART between DSP and the Radio works perfect. We are using a GPIO to rise an interrupt on DSP. The MSP fires the GPIO when it has data . Then the DSP reads data through SPI. The GPIO interrupt is not picked up by DSP after sometime. This was the result of my tests. Any ideas why this happens? Could there be a memory issue? If so how can i solve it? 

    Thx,

    Dilip.

  • GPIO interrupt timing can be tricky. Are you using the interrupt flag or interrupt "events" for DMA? 

    Note that the interrupt edge trigger polarity is 0=rising edge, 1=falling edge. This bit me once.

    If you are able to connect to your target while using the flashed program, you can check the status of the interrupt flag to see if it is really being set by the GPIO line. If it is set then your interrupt service routine should run. If it is not being set, then something else may be happening.

    Is the MSP resetting the GPIO to zero after it sends the SPI data? Take a look at the timing of this to make sure it is working as expected.

    Are you clearing the GPIO interrupt before or after the DSP processes the data? There may be a timing issue here also. Make sure the DSP clears the interrupt flag.

    That's all I can think of for now.

  • Hi Mike,

    I have done few more tests and can say that it is not the gpio thats creating the problem. It is the SPI. After sometime the data being transferred is getting corrupted. So when my DSP is sending an 's' , MSP is getting some junk value. So it doesnt respond and this continues until i restart everything. I have gone through your other posts on SPI but couldn find anything that i could relate to my problem. Are there any necessary precautions to be taken for SPI? If you have some sample code which works perfectly please give it.

    Regards,

    Dilip.

  • Dilip,

    So, since this does not appear to be a flash-boot problem, why don't we continue this on another thread (SPI problems?). Why don't you start the new thread with an explanation of what you are seeing.

  • Mike,

    From the tests done and the observations, i know that there is a problem with the SPI but am not sure its with SPI alone or something to do with my flashing . Because when i run the same code from CCS it works flawless. 

    Regards,

    Dilip.

  • What speed are you running the SPI clock at? Have you put an oscilloscope on the SPI lines to see if the voltage waveforms are correct? Can you decode the SPI with a logic analyzer to see if there is a consistent pattern to the failure? Take a close look at the CS and its relationship to the MISO and MOSI lines and make sure your CS-data delay timing is within the specs of the device. Which processor is the SPI master (MSP or DSP)?

    I have found that you need a slight delay after sending a byte from the SPI to the attached device. For example:

    for(delay = 0; delay < 6; delay++);

  • The SPI clock is running at 4 MHz. Unfortunately, I dont have an oscilloscope. So cant check the stuff. DSP is the master. 

    CSL_FINS(sysRegs->PSRCR, SYS_PSRCR_COUNT, 0x20);
    // reset time = 0x20
    CSL_FINS(sysRegs->PRCR, SYS_PRCR_PG4_RST, CSL_SYS_PRCR_PG4_RST_RST);
    // spi hardware reset

    CSL_FINS(sysRegs->PCGCR1, SYS_PCGCR1_SPICG, CSL_SYS_PCGCR1_SPICG_ACTIVE);
    // activate spi gate
    for (delay = 0; delay < 5; delay++)
    ; // delay before peripheral activity
    CSL_FINS(sysRegs->EBSR, SYS_EBSR_PPMODE, CSL_SYS_EBSR_PPMODE_MODE1);
    // init peripheral multiplexing

    CSL_FSET(CSL_SPI_REGS->SPICCR, CSL_SPI_SPICCR_CLKEN_SHIFT,// disable spiclock
    CSL_SPI_SPICCR_CLKEN_SHIFT, CSL_SPI_SPICCR_CLKEN_DISABLED);
    CSL_FINST(CSL_SPI_REGS->SPICCR, SPI_SPICCR_RST, RELEASE);
    // give a short software reset

    CSL_FINS(CSL_SPI_REGS->SPICDR, SPI_SPICDR_CLKDV, 99);
    // spi clock divider (99+1)
    CSL_SPI_REGS->SPICCR = (Uint16) (CSL_SPI_SPICCR_CLKEN_ENABLED << 0x000F); // enable spi clock

    CSL_FINS(CSL_SPI_REGS->SPIDCR1, SPI_SPIDCR1_CKP1, 0);
    // clock polarity active high
    CSL_FINS(CSL_SPI_REGS->SPIDCR1, SPI_SPIDCR1_CKPH1, 1);
    // clock phase 
    CSL_FINS(CSL_SPI_REGS->SPIDCR1, SPI_SPIDCR1_DD1, 0);
    // data delay = 0.5 cc
    CSL_FINS(CSL_SPI_REGS->SPIDCR1, SPI_SPIDCR1_CSP1, 0);
    // cs polarity active low

    Above is the code i use to initialise my SPI.


    CSL_FINS(CSL_SPI_REGS->SPICMD1, SPI_SPICMD1_FLEN, 0);
    // frame length = 1
    CSL_FINS(CSL_SPI_REGS->SPICMD2, SPI_SPICMD2_CSNUM, 1);
    CSL_FINS(CSL_SPI_REGS->SPICMD2, SPI_SPICMD2_CLEN, 7);

    CSL_SPI_REGS->SPIDR1 = 0x0000; // data 1 = 0
    CSL_SPI_REGS->SPIDR2 = (Uint16) (ecg_data << 0x0008); // data 2 = ecg_data // cs1 = slave 1

    CSL_FINS(CSL_SPI_REGS->SPICMD2, SPI_SPICMD2_CMD, 1);
    // send data

    do { // Check for Word Complete status
    value_1 = CSL_FEXT(CSL_SPI_REGS->SPISTAT1,SPI_SPISTAT1_CC);
    } while ((value_1 & 0x01) == 0x0);

    do { // Check for busy status
    value_1 = CSL_FEXT(CSL_SPI_REGS->SPISTAT1,SPI_SPISTAT1_BSY);
    } while ((value_1 & 0x01) == 0x01);

    Above is the code i use to send data

    for(stop=0; stop<1500; stop++);

    i gave this delay. Interestingly if i give this delay between sending data and reading data, the data is being shifted by one byte. If i give the delay between two write commands, it works fine.

  • Sorry Dilip. I've run out of ideas and time. Perhaps you could borrow a scope and logic analyzer. It's important to verify the correct logic levels and bit/timing patterns before assuming it is a software/firmware issue.

    This is where someone from TI should chime in.

    Good luck.

  • The problem I am currently having is that the processor is incommunicado. I try to connect to the board normally and in debug mode in CCS and I see the following error:

    (Error -1143 @ 0x5F) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 5.0.623.0)

    I can't seem to reset the chip or at the very least peek in at the memory and registers.

  • Did you programmed new boot image that cause this problem? Can you try connecting CCS quickly right after powered up before ROM code finish?

    Regards.

  • The boot image that is currently on the board is the same as the code I've used when I originally posted this issue. I have not been able to connect to my board since flashing this code.

    In order to connect to the board via CCS, I need to first load a target configuration in CCS. Once the target connection is loaded and I quickly click connect, I see the same -1143 error.

  • Hi Andrew, Dilip,

    Regarding the C5515 eZdsp getting stuck after NOR boot, not allowing CCS to debug...

    The bootloader device order is NOR Flash, NAND Flash, 16-bit SPI EEPROM, I2C EEPROM, and MMC/SD.

    Remove R7 which supplies VDD_IO2 (power to NOR flash)
        - will prevent bootloader from booting
        - reconnect supply after connected in CCS to erase the flash
        - dont recommend "hot switching" of VDD_IO2 but only way to erase NOR without hardware

    Other methods to prevent booting from NOR..
        - Short EM_CS2n to VDD_IO2 (3.3V) during boot to prevent chip select appearing low to NOR flash - short S29AL032 Pin 26 to R61, C4, or some other VDD_IO2, 3.3V node
        - Short VDD_IO2 to GND (cringe) - short C4 to GND

    After device power is applied, wait a second then remove the short - bootloader will have gven up on the NOR flash and allow you to connect as it tries to perform UART/USB boot in an endless loop...

    --

    I have experienced a similar lockout issue if a bad boot image was burned to the NOR flash - following these steps, I was able to get back in and erase the NOR Flash to regain use from the board.

    We learned our lesson here and now pass the chip select signal through a switch in case we ever want to disconnect the chip select signal from the boot source. You can see this on the C5535 eZdsp chip select to the SPI flash. C5535 eZdsp also allows you to boot from an SD card, which is easy to remove to prevent boot loader.

    Let us know if you can get your board back working and we can tackle your other SPI issue.

    Regards,
    Mark

  • Mark,

    Interesting...... But shouldn't the JTAG connection be able to gain control of the processor by asserting its RESET pin? And perhaps the bootloader code should include some sort of failsafe mechanism to prevent this situation in the first place.

  • Thank you, this worked! I am now able to reconnect and flash new programs onto the board.

    I am still struggling with initializing the board for standalone operation. I'm not entirely sure how to re-purpose the initialization code from the gel file.

    Thanks,
    -Andrew

  • Hi Andrew, did you ever get this working in standalone?