• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 100 subscribers
  • Views 629 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.

intermittent dsplink startup problem

Chuck Peplinski
Genius 5770 points

I am using dsplink 1.65.02.09 to control a DA830 running PA version 5. The ARM runs Linux arago 3.3.0+, from a TI 3.22 distribution.

I have reconfigured the tables in CFG_DA8XXGEM_SHMEM.c to match my system.
I have set the RESETCTRLADDR to the top of my SDRAM region-0x80.  (though why is not clear)

This configuration usually runs, but sometimes the DSP does not start up correctly.
When I enter this state, I typically have to power cycle the board to get out of it. A reset won't fix it.  

I can connect to the DSP with the JTAG debugger in this state and I typically find that the PC is in the DSP L2 ROM (address 0x00714A52).
I understand the the L2 ROM is boot code of some kind. Do I get any hint of what's gone wrong by knowing what is this code?

When connected with the debugger, I can load symbols and restart the program without downloading.  The code is there.  But some run time sequence makes the boot go bad.

My guess is that some important register setting is missing from the sequence. Does this sound familiar to anyone?

  • 0
    Genius 5770 points

    I think this is a question about how the DSP boots.  I don't have a Linux problem.

  • 0 in reply to Chuck Peplinski
    TI__Guru** 116830 points

    Hi Chuck,

    We have moved this to the Linux forums as the all of the DSPLINK/SYSLINK experts monitor the embedded Linux forums and would be able to best guide you to find the answers to your questions.

    Just as a clarification can you describe the DSP boot scenario. Is this for the recovery from suspend state where you have the PA application loading after the Linux boots up or is the scenario described for the power on reset scenario. Also it appears that this implementation works  but not reliably. Could the code be transitioning too fast in some scenarios causing the fail. Please see if the PSC status in the code is being monitored correctly.

    Regards,

    Rahul

    PS: It may also provide specifics on how the DSPLINK is built like is the NO_BOOT option enabled for DSP boot, etc

  • 0 in reply to Rahul Prabhu
    Genius 5770 points

    This work is in preparation for the low power recovery.  So far, this happens from a cold boot.  The DSP code is not built with the PA_NO_BOOT flag.

    Many times the configuration works.  I boot up Linux from a reset, insmod the dsplink driver built to load the DSP code and the DSP starts up, all is fine.

    Other times, I do exactly the same thing and the DSP gets stuck in the boot ROM.  

    To use the debugger in these cases, I have code on the DSP at the start of main.c that loops on a volatile variable.  So when it works, I connect the debugger and enable the program to actually start by changing this variable.  In the cases where it fails, the DSP does not stop at this loop.  I assume it does not get to main.  I print out the vectors specified by the host and they are the same in the two cases.

  • 0 in reply to Chuck Peplinski
    Genius 5770 points

    A short answer that would help me would be an explanation of what is in the L2 BOOT ROM code and how I might get there.  

    Would I land there by a jump to zero?  Or am I stuck there because some condition is not satisfied?

    At this point, the system is already up.  DSP code has run via the UBL and the ARM has booted to the Linux prompt.  I am restarting the DSP code.  Am I right that it has no business going into the BOOT ROM?  

  • 0 in reply to Chuck Peplinski
    TI__Genius 12025 points

    Chuck,

    The DSP ROM code looks at the boot mode register and either enters a spin loop or executes the idle instruction. The boot mode register is documented along with the boot address register. Sometimes, the host processor will assert reset on the DSP and then set the boot mode to execute the idle instruction; then release the DSP. This is used to trigger a low power transition or to recover from a crash.

    I'm suspicious of your boot address. The DSP boot address must be aligned on a 10-bit boundary. The boot register has bits [9-0] tied to zero. If your reset vector is not aligned, the DSP may be booting some random code and crashing.

    ~Ramsey

  • 0 in reply to Ramsey
    Genius 5770 points

    This is an interesting hint.

    In my code, cint_00 is the entry to the DSP code and it's typically something like 0xc3973180.  That's not 10 bit aligned.  Do I have to do something different in the linker to assure that?  OR do you mean what dspLink calls the "entry point"?  In my code, this also is not 10 bit aligned.  I guess I can change that.   A trace from my code shows:

    da8xxgem.c: DA8XXGEM_start.688. Entering. dspAddr 0xc3973180

    da8xxgem.c: DA8XXGEM_start.709. Set entry point as 0xc3dfff80.

    I suspect it is the latter.  And if the HW truncates this to a 10 bit alignment, then it will first execute some random junk before hitting the jump instruction that we write there.  I'll try this on Monday.

  • 0 in reply to Chuck Peplinski
    Genius 5770 points

    So far, so good.  I think that was the problem.  My entry point is now set to 10 bit alignment and it seems to work well.

  • 0 in reply to Chuck Peplinski
    TI__Genius 12025 points

    Chuck,

    I'm glad to hear you worked it out. Thanks for posting your final results, it benefits everyone.

    ~Ramsey