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.

reset via RSCTRL not working

Hello,

I've followed the information online, including E2E, on performing a reset via the RSCTRL register, but am not having much luck.

I write the key first, 0x5a69, but it never goes unlocked.  Before I write that, it has a value of 0x10003 and after as well.  I am debugging it under emulation.  Does it not work then?  This is for a C6748 target.

Please advise,

Robert

P.S. I understand the reset won't occur until a value of 0 is written to bit 16 in RSCTRL, but first I need to have success in getting it unlocked.

  • Robert,

    Can you show the code you are using to do the write? Are you writing a 32-bit value or a 16-bit short? I believe it should be a full 32-bit value being written to any device register.

    If you search in this forum for "RSCTRL" (no quotes), you will find several posts that talk about different methods for using RSCTRL. Please see if the code used in any of those helps you with getting yours to work.

    And please let us know of your success or not.

    Regards,
    RandyP
  • Dear Robert,
    I have did this in LED example project and able to reset while running the code via emulator.
    Please refer to the following e2e post.
    e2e.ti.com/.../1480572

    Let me know if you are not able to solve the problem or any issues.
  • Titusrathinaraj Stalin said:
    Dear Robert,
    I have did this in LED example project and able to reset while running the code via emulator.
    Please refer to the following e2e post.
    e2e.ti.com/.../1480572

    Let me know if you are not able to solve the problem or any issues.

    Hello,

    I had used your exact code, for the implementation ... and only posted here when it did not work.  Still 0x10003 after each step below.

    Please advise

    Regards,

    Robert

    --------------------------------------------------------------

    #define RSCTRL 0x01c110e8

    unsigned int *rsctrl = (unsigned int *)RSCTRL;

    void reset( void )

    {

        *rsctrl = 0x5A69;

        *rsctrl &= ~(1<<16);

        *rsctrl = 0;

    }

  • Hi Randy,

    RandyP said:
    Robert,


    Can you show the code you are using to do the write? Are you writing a 32-bit value or a 16-bit short? I believe it should be a full 32-bit value being written to any device register.

    I have put code in response to Titus.  I am using 32-bit.

    RandyP said:


    If you search in this forum for "RSCTRL" (no quotes), you will find several posts that talk about different methods for using RSCTRL. Please see if the code used in any of those helps you with getting yours to work.

    Right, I did find all, but they didn't ;) Not so far, anyways ... but it certainly helped understand what should be working.

    RandyP said:

    And please let us know of your success or not.

    Not yet!  Appreciate any more ideas.

    Robert

  • Did you run the gel file before loading the code ?

    Actually earlier I have tested this code and it worked.
    Anyways, let me try one more time and update you.
  • Titusrathinaraj Stalin said:
    Did you run the gel file before loading the code ?

    Which gel file would that be?  I rarely use gel files, having put most initialization in the code, since it is intended to run out of flash.

    Robert

  • Can you try to use the gel file before running the code ?
    C:\ti\ccsv6\ccs_base\emulation\boards\lcdkc6748\gel\C6748_LCDK.gel
  • Hi,

    There were several functions in that gel file, so I just ran them all. But still the same result, i.e. the value of RSCTRL remains 0x10003 after trying to unlock.

    Robert
  • Dear Robert,

    I am able to reset the C6748 LCDK board using the below code.

    #define RSCTRL 0x01c110e8

    unsigned int *rsctrl = (unsigned int *)RSCTRL;

    void main( void )

    {

       *rsctrl = 0x5A69;

       *rsctrl &= ~(1<<16);

       *rsctrl = 0;

    }

    Gel file output:

    C674X_0: Output: Target Connected.

    C674X_0: Output: ---------------------------------------------

    C674X_0: Output: Memory Map Cleared.

    C674X_0: Output: ---------------------------------------------

    C674X_0: Output: Memory Map Setup Complete.

    C674X_0: Output: ---------------------------------------------

    C674X_0: Output: PSC Enable Complete.

    C674X_0: Output: ---------------------------------------------

    C674X_0: Output: PLL0 init done for Core:300MHz, EMIFA:25MHz

    C674X_0: Output: DDR initialization is in progress....

    C674X_0: Output: PLL1 init done for DDR:150MHz

    C674X_0: Output: Using DDR2 settings

    C674X_0: Output: DDR2 init for 150 MHz is done

    C674X_0: Output: ---------------------------------------------

    Project attached:

    LCDK_reset.zip

    Screen shots:



  • Thanks for the additional information.  I actually traced it back to PLL register access lock, which is done in my software after setting up each of the PLLs (at the end, after all PLL configuration is done, I re-lock PLL register access).  This PLL register access lock keeps the RSCTRL unlock from occurring.  So now, when I want to do the reset, I first unlock the PLL register access, and then do the RSCTRL unlock, and reset, as shown in your examples, etc.

    However, this has led to a new issue.  When the reset occurs, it jumps to 0x700000.  But when I run from there, I don't hit a breakpoint I have right at the beginning of my main() routine.  If it's done a reset, shouldn't it reset back from the beginning of the main() routine, and hit the breakpoint put there?

    Robert

  • Robert,

    Does the reset that you apply cause a full reset sequence including reloading your code? Since it jumps to 0x700000, I assume that is the case. And if so, then any BKPT instruction opcode inserted by CCS would be overwritten by that reloading; that is how software breakpoints are implemented.

    The C6748 should have a limited set of hardware breakpoints, so you could set one of those in main() and it would still occur even if the code is overwritten. Check the tutorial or click on Add Breakpoint to get the exact steps to do this, or post in the CCS forum if you do not get a quick answer here.

    Regards,
    RandyP
  • RandyP said:
    Robert,

    Does the reset that you apply cause a full reset sequence including reloading your code? Since it jumps to 0x700000, I assume that is the case. And if so, then any BKPT instruction opcode inserted by CCS would be overwritten by that reloading; that is how software breakpoints are implemented.

    That's what is happening Randy.  I flashed in some code that does some led blinking, then reset, and I can see it repeating.  

    Looks like we're good on this one.  Thanks to you and Titus.

    Robert