• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 350 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Boot issue ezdsp 5515

MikeH
Guru 15580 points

I am observing strange behavior when trying to boot from NOR flash on my ezdsp c5515 board.

I have successfully generated a .bin file of my project code and flashed it into NOR flash on the ezdsp c5515 board. However, when attempting to boot from flash, the DMA process, which is supposed to transfer audio samples out to the AIC3204, does not start. 

However, if I start a debug session and connect to the C5515 (no GEL file), the DMA process starts as soon as I connect. I can then hit Run and the program (and DMA function) will work properly. But, when booting from a cold start, the DMA does not run.

Can anyone shed any light on what may be happening?

  • 0
    Guru 15580 points

    TI EMPLOYEES.......CAN I PLEASE GET SOME SERIOUS TECHNICAL SUPPORT ON THIS? IT'S CRITICAL!

    Peter Chung? Hyun Kim? Mark Mckeown?

    What does the emulator do when it connects to the target? Why would it allow/cause the DMA process to start? Why would the DMA *not* start when booting from NOR flash?

    Cmon guys. Dig a little.

  • 0 in reply to MikeH
    Prodigy 100 points

    I'm seeing the same behaviour. In my case the code has been sent via USB using the ROM bootloader, The code runs fine under the debugger (without a gel file), but outside the debugger the DMA fails to start. I've double checked I'm doing the relevant peripheral resets and enabling the peripheral clocks, but still the DMA refuses to start unless the debugger is attached.

    Any advice much appreciated.

    John 

  • 0 in reply to John Atkins96586
    Prodigy 100 points

    Ok, in case any one is interested, I've found the solution. It seems that the ROM bootloader puts the 'memory port' in the idle state using the IDLE command. Connecting the debugger somehow resets this.

    This golden snippet solved the problem:

    volatile ioport Uint16 *icr;

     icr = (Uint16 *)0x0001;
     *icr = 0x0000;
    asm("\tIDLE"); //execute idle instruction

     John

  • 0 in reply to John Atkins96586
    Guru 15580 points

    John,

    Thanks for the update. I found a similar fix in another thread, which works for me.

    IDLE_ICR = 0x000E;
    asm(" nop_16");
    asm(" nop_16");
    asm(" nop_16");
    asm(" nop_16");
    asm(" nop_16");
    asm(" nop_16");
    asm(" idle");

    It's a shame that TI does not support its customers.............