• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 379 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.

AM4372: Register values after reset

Kanae
Guru 10285 points

Part Number: AM4372
Other Parts Discussed in Thread: SYSCONFIG

Hi Support Team,

Our customer who is using AM437x has the following question.

We are checking whether each register of AM437x is set according to the design document prepared by our hardware designer.
In the process of checking, we found that there are registers (9 registers below) that are different from the Reset value described
in the design document, even though they are not set by software.
The values after RESET (expected values) and the values (current values) read immediately
after starting the Starter program (see *) are as follows.

Register Name                                                  reset                read
PRCM_CM_DPLL_CLKSEL_TIMER2_CLK    0x0000 0001    0x0000 0002
PRCM_CM_PER_TIMER2_CLKCTRL            0x0003 0000    0x0000 0002
PRCM_CM_WKUP_SYNCTIMER_CLKCTRL 0x0003 0002    0x0000 0002
PRCM_CM_WKUP_CLKDIV32K_CLKCTRL   0x0000 0000    0x0000 0100
PRCM_CM_CLKDCOLDO_DPLL_PER          0x0000 0000     0x0000 0300
prcm_cm_clkmode_dpll_extdev                       0x0000 0004     0x0000 0007
PRCM_CM_CLKSEL_DPLL_EXTDEV            0x0000 0000     0x0200 FA0B
PRCM_CM_DIV_M2_DPLL_EXTDEV             0x0000 0001     0x0000 038A
SYSCONFIG (PWMSS)                                   0x0000 0028      0x0000 0008

About the *Starter Program
Boot: QSPI
Development Environment: CCSv9
  EXT_PLL_Config function call line on line 22 of "Gel File: AM43xx_PLLconfig.gel" is a code that
 Code Composer Studio uses to call the register PRCM_CM_CLKMODE_DPLL_EXTDEV, PRCM_CM_CLKSEL_DPLL_EXTDEV, PRCM_CM_DIV_M2_DPLL_EXTDEV
   are commented out and overwritten to avoid setting them.

In the case of QSPI boot, it is my understanding that the TI private ROM code is doing this until the jump to 0x30000000 below.

The ROM Code initializes the QSPI controller, pin muxing, and clocks to communicate with the QSPI device.
The controller is initialized in Mode 3 and the The ROM sets up the QSPI controller in memory-mapped mode,
and jumps to the beginning of the QSPI memory mapped region (0x30000000) to begin boot.

In the case of the Starter program used to check the register values, the startup routine we created is executed from 0x30000000,
and jumps to the main function at the end.

The contents of the start-up routine is just doing the same thing as described in the following URL for ARM registers,
and I could not find anything that is set to the AM437x register that is the subject of this inquiry.
www.aps-web.jp/.../

Our hardware person could not determine if there is any problem with this register value change.
We didn't set it up as software from here, but the cause is still unknown.
Since we cannot guarantee that other registers will not change without our permission in a situation where there are still registers
whose values change from their initial values on their own, we would appreciate answers to the following questions.

Q1: What causes a register value to change?
Q2: Is it possible to take measures to prevent register values from changing? If so, how?


Regarding the change in register values, it is thought that the TI undisclosed ROM code is one of the factors,
but I would appreciate an explanation of the impact of this ROM code on the above-mentioned registers.

Best regards,
Kanae

  • 0
    TI__Guru* 94961 points

    Kanae, yes the ROM code is most likely the cause of the change in these registers.  We do not explicitly document all the registers the ROM code touches (too numerous to document).  

    To get the true reset value of these registers, you would have to set the device in wait-in-reset mode using the EMU signals (EMU0 = low, EMU1 = high), which would prevent the ROM from executing, and then connect via CCS to read the registers.

    Regards,

    James

  • 0 in reply to JJD
    Guru 10285 points

    Hi James,

    Thank you for your reply.
    I share this with my customer.

    He would like to make sure the following items about your reply.

    ■Cause of register initial value change
    (1) Is it correct to understand that "after TI's undisclosed ROM code is executed,
    the register values do not change again on their own (even though they are not set
    by the startup routine or user software) from the current register values." ?

    (2) According to our hardware engineer, there is no EMU0/1 signal pin connection
    on our custom board, so it is difficult to check.
    Is it possible to check if the initial values of the registers are left as they are after starting the CCS ICE
    in wait-in-reset mode on your evaluation board?

    Or is it possible to make our custom board start up in wait-in-reset mode?

    Best regards,
    Kanae

  • +1 in reply to Kanae
    TI__Guru* 94961 points

    1. Correct.  The registers won't change by themselves, unless there is a status bit or similar that would change based on hardware.  

    2. I'm not sure what you are asking here.  As stated, registers won't change after ROM is executed unless changed by software. 

    Not sure why the customer is concerned about initial values of registers.  They should explicitly write the register if they want to ensure its value.  

    Regards,

    James