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.

DMA problems after boot sequence

Dear community,

Currently I am working with DSP C5505 und have some problems with DMA after the boot sequence from I2C EPROM.

In my program I try to transfer the data from external SRAM (EMIF) to internal via DMA. The program works well, if I load it by the XDS100v2 emulator. Furthermore hex55 v.4.3.8 utility creates a bin file, which I can store in I2C EPROM. After reset DSP can boot and start the program and pulses watch dog. I check it by oscilloscope. When DSP try to stars DMA transfer, it reads only the first burst of 8 double words from EMIF and can’t continue the data transmission.

Do you have some ideas, what is a difference between content of two programs for emulator und boot loader? I suspect it can be problems with hex55 setting.

I hope you can help me to solve this problem.

Best regards,

 

Olek

  • Common Mistakes in Boot Image User Code

     

    A frequent issue is that the user code works fine in CCS environment but fails to work after converted to boot image. This is most likely because the user code relies on GEL file in CCS environment to initialize and setup PLL. This is easily be verified by not using GEL in CCS environment. Solution is to include all necessary steps in the user code. It is a good practice to re-initialize everything you need from within your bootloaded user code.

     

    Another common mistake is the user code uses SARAM31 for memory. The bootloader writes to SARAM31 (byte address 0x4E000 – 0x4FFFF) thus any user code resides in SARAM31 will be corrupted. Do not use SARAM31 if you intend to convert this code to boot image.

  •  

    Hi Steve,

    Thank you for your remark.

    I don’t use any GEL files for initialization. The boot program works fine: PLL is ok, all interrupts und ports works. Only DMA fails to transfer the data. DMA tries to transmit the first burst and reads it from external SRAM. After that the program polls STATUS bit in control register, but nothing happens. It seems that DMA can’t store the first burst because the internal RAM is blocked by CPU or switched central resource fails. But Interrupts still work and I can send I2C messages.

    I will check your idea abort SARAM31.

    Best regards,

     

    Olek

  • Hi Steve,

    I store the program in upper SRAM section:

    SARAM_1 (RW): origin = 0010000h length = 028000h

    .text : > SARAM_1    ALIGN = 4

    I still have the same problem.

    Best regards,

     

    Olek

  • Hi Olek,

    Are you configuring your system clock properly after boot process.

    Can you post your DMA configurations.

    Pratap

  • Hi Pratap,

     

    There ist the code sequence:

     

    DMAIFR=0xFFFF; //Clear Interrupt Flag Register DMA

    IFR0|=0x100; //Clear CPU Interrupt Flag Register DMA

    //NO Interrupts are used!!!

    DMACH0SSAU=dma_CS4_addr>>16; //Load source address EMIF

    DMACH0SSAL=dma_CS4_addr & 0xFFFF;

    DMACH0DSAU=dma_buff_addr>>16; //Load destination address, DARAM origin at 10000h

    DMACH0DSAL=dma_buff_addr & 0xFFFF;

    DMACH0TCR1=864; //One line in Bytes

    DMACH0TCR2=0x18; //Burst mode 8 double words

    DMACH0TCR2|=0x8000; //Start DMA transmission, set EN to 1

     

    while ((DMACH0TCR2 & 0x4000)!=0){;} //Poll the STATUS Bit

     

    It works, if I use emulator.

    Best Regards,

     

    Olek

  • Hi Olek,

    Your DMA configuration looks fine. I suspect either DMA or SRAM configuration getting changed while booting. You can halt your boot process by keeping an infite loop in the code, connect the emulator and verify the DMA and SRAM configrations.  

    You can refer to http://processors.wiki.ti.com/index.php/Debugging_Boot_Issues for bootloader debugging techniques. Section 'Debugging problems with the bootloader' describes how to halt the boot process.

    Pratap

  • Hallo all,

    My colleague found out, the problem is that the MPORT was in idle mode. The emulator can change the settings.

    I program the ICR=0x20E; asm(" idle");. After IDLE instruction DAM can be serviced.

    I would like to say thank you to all forum participants.

    Best regards,

     

    Oleksii

  • you are awesome!