• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 190 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.

TMS320F28P650DK: Questions about GSxRAM initialization after CPU1 watchdog reset

Ting-Wei Gao
Prodigy 10 points
Part Number: TMS320F28P650DK

Tool/software:

Hi

I have some questions about GSxRAM initialization when I am using F28P65:

(1) I use a CPU1 GSxRAM test variable, and add this variable by 1 per CPU1 PWM ISR.

     After I use CPU1 watchdog reset,  the variable will still remain its value.

     Is this phenomenon normal?

(2) After power-on reset or CPU1 watchdog reset,

     will the variables in GSxRAM be set to zero if they don't have initial values in variable declaration?

Best regards.

Ting-Wei

  • +1
    TI__Guru* 77410 points

    Ting,

    I will refer back to the F28P65x TRM https://www.ti.com/lit/spruiz1b page 1045 which gives the boot flow

    Ting-Wei Gao said:

    (1) I use a CPU1 GSxRAM test variable, and add this variable by 1 per CPU1 PWM ISR.

         After I use CPU1 watchdog reset,  the variable will still remain its value.

         Is this phenomenon normal?

    Ting-Wei Gao said:

    (2) After power-on reset or CPU1 watchdog reset,

         will the variables in GSxRAM be set to zero if they don't have initial values in variable declaration?

    A1/2)RAM INIT will only occur on a Power on reset(POR) or XRSn based reset.  Watchdog reset WDRSn will not trigger the RAM Init function in the Boot ROM.  So #1 is expected, and for #2 RAMINIT will only occur after POR, but not WDRSn.

    Best,
    Matthew

  • 0 in reply to MatthewPate
    Prodigy 10 points

    Hi Matthew
    Thank you for your reply.


    (1) Please refer to the picture below.
         Do you mean that POR and WDRS use the boot flow of red line but only POR triggers the RAM init (red circle)?

    (2) Is there another method to trigger RAM init at WDRS?
         Or can I change the WDRS boot flow to the orange line for RAM init (orange circle)?
         (Please refer to the picture below.)

    Best regards.


    Ting-Wei

  • +1 in reply to Ting-Wei Gao
    TI__Guru* 77410 points

    Yes, this what I was referring to.  Looking at the TRM page 774, you can also activate the RAM Init through a SW write to the DxInit/LxInit/GxInit registers and then wait for the Init to set the "DONE" bit.

    Something you could do as part of your main code, is read the reset cause register "RESC" to determine if the source was something other than POR, and then init the RAMs accordingly.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Prodigy 10 points

    Hi Matthew
    Thank you for your reply.

    I do a SW write to GxInit registers in main() that I found the GSRAM variables which have initial values in variable declaration are set to zero.
    So I try another way that I do a SW write to GxInit registers before codestart branch to _c_int00.
    Will this method cause any bad effect to TI boot flow? 

    codestart: 
	SETC OBJMODE
	EALLOW
	.if WD_DISABLE == 1
	  MOVZ DP, #7029h>>6
	  MOV  @7029h, #0068h
	.endif
GSRAM_Init_Start:
	MOVW DP, #5F452h>>6
	MOV  @5F452h, #001Fh
GSRAM_Init_Chk:
	MOVW DP, #5F454h>>6
	CMP  @5F454h, #001Fh
	B    GSRAM_Init_Chk, NEQ
	EDIS
	LB _c_int00

    Best regards.
    Ting-Wei

  • +1 in reply to Ting-Wei Gao
    TI__Guru* 77410 points

    Ting-Wei, 

    Good point on the c initialization, I see how that is an issue.  And yes, adding this code to code_start_branch.asm will address these issues and not impact the boot flow.  This section of code is the first thing that will get executed from a power up into flash boot, so there is no assumption of any CPU register retention, i.e. it is safe to code in assembly as you have done.

    The only concern will be the watchdog, so I'm assuming you've disabled it via a WD_DISABLE = 1 predefine.  If you have any concerns on disabling the WD, we would need to add some more assembly to write to the check bits periodically.  If you've ran the above with WD_Enabled and don't see an issue, the RAM init time won't change run to run, so you can leave alone; I just don't know the time to RAM init the GSx RAM vs the WD timeout from reset.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Prodigy 10 points

    Hi Matthew
    Thank you for your reply.

    Yes, I have disabled the watchdog via an assembly code "WD_DISABLE .set 1".
    I will use my method and continue to check it is working.

    My issue is solved.
    Thank you.

    Best regards.
    Ting-Wei