• Locked Locked
  • Replies 7 replies
  • Subscribers 54 subscribers
  • Views 924 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

run, pause, reset CPU OK, but restart program fails

Andrey Gursky
Intellectual 350 points

Dear TI support and forum members,

using ezdsp5502 and CCS 6.x on GNU/Linux Debian (jessie/testing), I'm experiencing since a while the following issue. After a sequence: run, pause, reset CPU, restart, the error occurs:

C55xx: GEL Output:
OnReset()
C55xx: GEL Output:
OnRestart()
C55xx: Trouble Setting Breakpoint with the Action "Finish Auto Run" at 0x26e90: (Error -1066 @ 0x26E90) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 5.1.507.0)
C55xx: Breakpoint Manager: Retrying with a 55 Hardware breakpoint

Simple programs using DSP/BIOS are not affected.

I've checked, the stacks are big enough. What could be wrong in order to trigger such an error?

Thanks,
Andrey

  • TI__Mastermind 23785 points
    I am moving this to CCS forum if they can help.Reagrds.
  • TI__Guru**** 168357 points
    Andrey,

    I am not 100% sure what may be happening, but since the address reported is located in external RAM (0x26E90), I imagine if somehow the external memory interface became misconfigured during the CPU reset.

    The error mentions the inability of the JTAG debugger to set a breakpoint at the address above, which happens if the memory is misconfigured, has an error or is simply non-existing.

    To confirm if that may be the root cause, perhaps you can try to disconnect from the C55x core (on the Debug view, right-click on the C55x core and select Disconnect), reset the device (or power cycle, if using an external JTAG debugger) and re-connect?

    Unfortunately I do not have the same board as you, but I tried something similar on my C5505 but I couldn't get the error message you have (it is probably due to what I am using).

    I will keep testing and see if I can reproduce everything and let you know the results.

    Hope this helps,
    Rafael
  • in reply to desouza
    Intellectual 350 points
    Rafael,

    thanks for your tips. This sequence does work indeed:
    disconnect - connect (jumped to 0xFF8000 = auto reset?) - restart - OK

    Hmm, but I can't remember I did changes concerning memory management.

    Now I've extended a simple DSP/BIOS program only by placing .text into SDRAM and enabled icache. That's enough to fail. One doesn't has to continue with program execution after breakpoint at main, just load (jumped to main) - reset - restart - FAILS.

    Thanks,
    Andrey
  • in reply to desouza
    Intellectual 350 points
    Rafael,

    > disconnect - connect (jumped to 0xFF8000 = auto reset?) - restart - OK
    auto-reset at connecting to target is not activated in CCS properties. But why it jumps? I believe it is because the gel file issues a CPU reset. Despite of a CPU reset it's working.

    I think, I had some reasons to do a CPU reset before to restart. If I restart program (being in good state) without doing reset, it works well.

    And gotcha! I believe it's a bug in the gel file. EMIF registers get lost after reset (but fortunately not SDRAM content) and gel file simply misses the emif initialization after reset, but calls it (after reset) during connect to target.

    Regards,
    Andrey
  • in reply to Andrey Gursky
    TI__Guru**** 168357 points
    Andrey,

    Thanks for reporting back your findings.

    At first glance I agree with you the GEL file probably needs to call the EMIF initialization routine (part of the SystemSetup()) both at the OnTargetConnect() and at the OnReset() routines. However, I wonder if there was a good reason to not include the EMIF initialization on the OnReset() routine - i.e., if a specific use case demands that and any changes would break compatibility.

    I will see if it is possible to change that (this file is not owned by us) and report back if I have some news, ok?

    Regards,
    Rafael
  • in reply to desouza
    Intellectual 350 points

    Rafael,

    yes it would be interesting to know, whether the EMIF initialization just has been forgotten or there are some important considerations.

    I had already one very nasty issue with this board and it turned out, among others, the EMIF wasn't configured properly enough in the GEL file. I opened a ticket by Spectrum Digital, but it remains unresolved. The supplied closed source software seems to work (of course TCP/IP protocol can fix errors by retransmitting data, thus hiding real errors) and there were no interest to fix and improve the open source version or at least to help with fixing by joining my thread here [1]. Now I'm applying this patch only locally.

    I hope, you will be more lucky with people at Spectrum Digital.

    Regards,
    Andrey

    [1] e2e.ti.com/.../983270

  • in reply to Andrey Gursky
    TI__Guru**** 168357 points

    Andrey,

    I talked to Spectrum Digital about the EMIF initialization on the GEL file and the idea is that, after a reset is issued, reload the executable (inside the GEL it is called OnPreFileLoaded()). The reason is that SDRAM data cannot be trusted in all cases when the EMIF is misconfigured (which happens when it goes through a reset).

    Obviously that does not prevent you from modifying the GEL file and suit your needs.

    I also asked them to take a look at the ticket you filed, thus you should receive a reply from them.

    Regards,

    Rafael