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.

C6670 re-latched DEVSTAT after Hard or soft reset !why?

Hi all,

It's about RESET and DEVSTAT latching.

 

Look, the datasheet :for hard reset and soft reset,the DEVSTAT pins are not re-latched. and the boot mode field is writable(I have verified), so I can 
modify the boot configuration field in DEVSTAT,and then trig the reset by writing the RSTCTL and RSTCFG register.


But i found the DEVSTAT is still re-latched after both hard or soft reset ! It is not acting as the Datasheet descripts.

 

Can you tell me why? 

===================

Here is my code, Please point out my mistakes? Thank you in advance!

{
...
...

CSL_BootCfgUnlockKicker();
/***************MODIFY DEVSTAT*******************************************/
//modify DEVSTAT for next re-Boot
volatile uint32 *RegPtr;
RegPtr = (volatile uint32*)0x02620020;
*RegPtr = 0x0003964D; //on POR the value is latched as 0x0003960D


/***************BELOW FOR RESET******************************************/
//RSTCTL Key
RegPtr = (volatile uint32*)0x023100E8;
*RegPtr ^= 0x00005A6A;

//RSTCFG set softreset
RegPtr = (volatile uint32*)0x023100EC;
*RegPtr |= 0x00003000;//also tried hard reset,the value will be 0x00000000

//RSTCTL Key
RegPtr = (volatile uint32*)0x023100E8;
*RegPtr ^= 0x00005A6A;

//RSTCFG trig softreset
RegPtr = (uint32*)0x023100E8;
*RegPtr &= 0xFFFEFFFF;// sadly, after reset ,the DEVSTAT re-latched to value 0x0003960D
CSL_BootCfgLockKicker(); 
...
...
}

 

PS:

[ Here is the background thread:  C6670 SPI boot from another NOR FLASH address,how?

Because the GPIO pin level is fixed on the hardware, so I have to try this method here I mentioned above.]

  • Hi Frank Deng,
    Please do not duplicate threads for same issue. We are looking into this and will get back you. Thank you for your patience.
  • Hi Frank Deng,

    Are you working on Custom board or EVM?

    1. Please lock the boot configuration register after DEVSTAT value is modified.  Then follow the reset sequence.

    Or

    2. Try below sequence,

    #define BOOT_ROM_ENTER_ADDRESS      0x20b00000

    CSL_BootCfgUnlockKicker();
    
    volatile uint32 *RegPtr;
    
    RegPtr = (volatile uint32*)0x02620020;
    
    *RegPtr = 0x0003964D; //on POR the value is latched as 0x0003960D
    
    CSL_BootCfgLockKicker(); 
    
     exit = (void (*)())BOOT_ROM_ENTER_ADDRESS;
            (*exit)();

    Note: Make some delay if needed after locking boot configuration register.

  • Thank you Raja,

    Cuz it said my post  was not successfully posted, so I tried several times. sorry .

    I don't know why.I thought there was problem in C66 forum. The issue is urgent. So I went to C64 forum for help, too .

    Plz tell me what happened to my account ,thanks !

  • Hi,
    No worries. You can follow up this thread for your query. Thank you.
  • Hi Raja,
    Actually,I had tried both the two sequence before my post here.
    1. Please lock the boot configuration register after DEVSTAT value is modified. Then follow the reset sequence.
    I have locked as you sequence but DEVSTAT still re-latched.
    " Note: Make some delay if needed after locking boot configuration register."
    I have make delay in a for loop: 1000 asm(NOP 5);I think it is enough.
    Still relatched after execute the " *RegPtr &= 0xFFFEFFFF;" //RSTCFG trig soft reset

    Can you have a try and make sure the chip is really works as "not re-latch". I found there are a lot of mismatch between the Datasheet and the device action.

    CSL_BootCfgUnlockKicker();
    /***************MODIFY DEVSTAT*******************************************/
    //modify DEVSTAT for next re-Boot
    volatile uint32 *RegPtr;
    RegPtr = (volatile uint32*)0x02620020;
    *RegPtr = 0x0003964D; //on POR the value is latched as 0x0003960D
    CSL_BootCfgLockKicker();
    
    for(i=0;1++;1<1000)
    {
    asm(NOP 5);
    }
    
    //CSL_BootCfgUnlockKicker(); // either Unlock or not has no effection to the below code, verified.
    /***************BELOW FOR RESET******************************************/
    //RSTCTL Key
    RegPtr = (volatile uint32*)0x023100E8;
    *RegPtr ^= 0x00005A6A;
    
    //RSTCFG set softreset
    RegPtr = (volatile uint32*)0x023100EC;
    *RegPtr |= 0x00003000;//also tried hard reset,the value will be 0x00000000
    
    //RSTCTL Key
    RegPtr = (volatile uint32*)0x023100E8;
    *RegPtr ^= 0x00005A6A;
    
    //delay
    for(i=0;1++;1<1000)
    {
    asm(NOP 5);
    }
    
    //RSTCFG trig softreset
    RegPtr = (uint32*)0x023100E8;
    *RegPtr &= 0xFFFEFFFF;// sadly, after reset ,the DEVSTAT re-latched to value 0x0003960D
    //CSL_BootCfgLockKicker(); 



    2.Re-boot idea: I have tried also.
    Progress: DEVSTAT successfully modified and re-boot from the desired image. But the running is not stable, some cores will abort after some times.
    I am sure the image is our released load,very robust load.





    Is there any other aspects we have not considered?

  • Hi Raja,

     

    I have tried on the two ways you suggested to me, but still have problems.

    (1)The jump-to-boot method is a good idea, but you know, the system is 4 cores BIOS running,when suddenly jumped to the boot process, cores will abort after sometime.

     

    (2)So I am still work on the reset - method but still DEVSTAT re-latched:

    I have locked the boot configuration register after DEVSTAT value is modified,and then I set the RSTCFG and RSTCTL register to trig soft or hard reset.

    But I found the DEVSTAT still re-latched, can you please ask your colleagure to have a try on the device?

    Is there any other register or operation I have to set?

     

    Thanks!

     

  • Hi Frank Deng,

    Apologize for the delay. I am working with SoC experts on this issue and will get back to you once I got an update.

    Thank you.

  • Hi Raja,

    Do you have any update? I am looking forward to your reply. (Why re-latched GPIO pin state to DEVSTAT after hard or soft reset)

    Tomorrow is Friday,I am really anxious.

    Thanks for your help!

  • Hi Frank Deng,

    Are you seeing the soft reset issue in C6670 EVM or custom board? Please confirm. Thank you.
  • Hi Raja,
    custom board.
  • Raja said:
    Hi Frank Deng,

    Are you seeing the soft reset issue in C6670 EVM or custom board? Please confirm. Thank you.

    Hi Raja,

    I had also tried on the EVM(TMDSEVM6670LE, Rev. 4A), still re-latched,same as my custom board.

    Can you experts have a try? And could you check my application code I pasted above?

     

    If unluckly, the hard or soft reset is still re-latch after your test.I have to go to the re-boot method. I then have to deal with the unstable situation.But the question is : before suddenly jump to Boot process when the BIOS system is running, how can I make the device state clear ,such as registers, BIOS and peripherals.That is to say :I have to clear the device as clear as reset. Then the device will run stable after the re-boot.

     

    I am looking forward to your good news!

    Thank you so much!

     

    Regards,

    Frank

  • Hi Frank,
    We have reproduced the issue already. This issue has been observed in all keystone I devices. We have escalated this to SoC design team and awaiting for their confirmation and workaround if possible.

    Thank you for your patience.
  • Dear Raja,

    Thanks for your update.  Inform me if  any further progress.

    I believe that you know my purpose,don't you? I hope your team can provide me workarounds.

    Thanks!

    Best regards,

    Frank

  • Hi Raja,

    I wish you had a wonderful weekends. :)

    I am looking forward to your good news.

    Please inform me if the SoC design team had made any progress or not,thank you!

    I hope there are workarounds.

    Best regards,

    Frank

  • Hi Frank Deng,

    Please refer the response by Rahul on below new thread ,

    https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/470512

    Thank you for your patience.

  • Thank you, Raja and Rahul!

    Best regards,
    Frank