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.

AM4376: The boot startup problem

Part Number: AM4376

Hi Team,

We use the core board designed with the AM4376 processor, but some cards cannot be started from the boot. The details are as follows.
1. The processor model is AM4376BZDNA100, and the clock is 24M.
2. As for the startup method of the circuit design, it can be started from MMC1, MMC2, and NAND.
3. The configuration of the sysboot pin [18..0] is 000 0100 0010 0000 0100 (the last four digits can be configured as 0110, 1100), and through the XDS100 I can confirm that the reading of the boot configuration pin is consistent with the actual circuit.
4. The current phenomenon is that some cards can be started normally, but some cards cannot be started by MMC1, MMC2 or NAND.
5. Through the XDS100 tracking registers, it is found that the boards that cannot be started, the corresponding mmc, nand and other pins are not configured, and the default mod7 is used. At the same time, the Boot Error Counters do not count errors and shows random values instead ​​(the normally functioning cards read 3 times, 2 times or 0 times). From the phenomenon, I feel that the internal boot of 4376 is not running.
6. Comparing the CONTROL registers of the cards and the abnormal ones, I notice that the values ​​of the CTRL_CORE_SLDO and CTRL_MPU_SLDO registers are inconsistent. The value read by the normal cards is 02FD0000, and the value read by the abnormal ones is 001F0000.
Kind regards,
Katherine
  • Hi Katherine,

    To route your query to our expert, I would like to know-  Are you using Linux or RTOS to boot?

    Regards

    Suren

  • Hi Suren,

    We use uboot to start our own application, and our application is based on ucos.

    Regards,

    Katherine

  • Hello,
    Will you provide more details?
    - SDK version?
    - Any log files showing the issue?
    - HW board info?
    Best,
    -Hong

  • Hi,

    The problem now is that the CPU does not start uboot, which has little to do with the version of uboot. The main chips of the circuit are as follows:

    1. Our hardware defaults to EMMC0 startup, and the sysboot pin configuration is 000 0100 0010 0000 0100 or 000 0100 0010 0000 1100.

    2. The 4376 matching TPS65218D0RSLT is selected as the power supply chip

    3. I expanded 2 channels of RGMII Ethernet, 1 nandflash, and 2 ddr3l memories

    The phenomenon is as follows:

    1. After the functioning cards were powered on and started, the CPU would send a pulse to the CLK pin of the MMC through MMC0_CLK, and this signal could also be measured through an oscilloscope. Even if the MMC card was not connected externally, the clk clock would still be sent.

    2. After the functioning cards were powered on, through jtag, I could view the correct value collected by the sysboot pin, and I could also see the pinmux register initialized by the cpu according to sysboot, and I could also see the number of CPU startups through the Boot Error Counters memory. 

    3. After the poorly-functioning cards were powered on, no pulse could be measured.

    4. After the poorly-functioning cards were powered on, I could see that the sysboot pin collected the correct value, but the Boot Error Counters memory was a random value, and on the pinmux register I cannot see any traces of initialization.

    At present, the problem we feel is that the cpu can recognize sysboot, but the cpu's own boot has not started.

    Regards,

    Katherine

  • Hello Katherine,
    On the non-working case, can we try "attaching" JTAG to the board to pinpoint to which point code is running up to?
    where "attaching" means attach/connect JTAG without target reset.
    Let's use JTAG debugger to find out if SPL starts to run on the board.
    a). if yes, SPL needs to be debugged further to see where lock-up is.
    b). if no, check SYSBOOT[] latched in CM CTRL_STS register @0x44E10040 to see if it is matching SYSBOOT pin configured on the board.
    Additionally bootrom boot progress can be checked via reading trace vector as described in "5.2.3.2.5 Tracing Data" of the TRM.
    Best,
    -Hong

  • Hello Hong,

    After the non-working cards are powered on, JTAG is "attached" to the board, and the PC register points to 0X00030000, and it does not continue to run afterward.

    I read the CTRL_STS register, and the value is 0X00420304, consistent with the configuration.

    The watchdog is not initialized, and the IDLEST value in PRCM_CM_WKUP__WDT1_CLKCTRL is 11

    Tracing Data 0X40338E40~0X40338E64 are random values.

    Boot Error Counters 0X40337DE0 is a random value.

    After I manually click the CCS run button (rusume), the watchdog is initialized.

    The value of Tracing Data 0X40338E40~0X40338E64 is assigned.

    0X40338E40 0000807E

    0X40338E44 00000010

    0X40338E48 03000030

    0X40338E4C 00010000

    0X40338E50 00000000

    Boot Error Counters 0X40337DE0 is still a random value.

    Regards,

    Katherine

  • Hello,
    Based on the eissue description, plus the random values captured in Tracing Data, one hypothesis might be HW related.
    I'm looping in my colleague for his input...
    Best,
    -Hong

  • Hello Katherine,

    What is the percentage of the boards that do not work.

    Is the issue that you are seeing observed during initial board testing or does it work for some time before the issues is seen.

    Were there any pervious lots that were produced without thus issues being seen.

    Regards,

    Sreenivasa

  • Hi Sreenivasa,

    At present, the boards are Prototype boards and there are 4 boards in total, all of which have similar problems. Today, we have further located it, and the phenomenon is as follows:

    1. After the no-working boards are powered on, we think that the non-working CPU does not run the Public ROM Code after powering on by observing Prototype board. Thus, the PC pointer has stopped at 0X0003_0000.

    2. During the jtag connection process, the cpu should be partially initialized.

    3. Once the jtag is connected to the CPU, the reset takes place through WARM and the board can be started through SD. It seems that jtag initializes some modules in the cpu.

    4. After the jtag is connected to the CPU, the reset takes place through COLD and the board cannot be started through the SD card. The PC pointer has stopped at the position of 0X0003_0000.

    Regards,

    Katherine

  • Hello Katherine

    Thank you for the inputs.

    The different between the warm and cold reset us power-supply ramp, sequencing, oscillator startup and the release of POR.

    Can you verify the hardware to confirm there are no issues around the above functionalities.

    Regards,

    Sreenivasa

  • Hi Sreenivasa,

    The problem has been solved. The EMU0 pin circuit is set as a GPIO input pin, causing the startup to fail.

    Thank you very much.

    Regards,

    Katherine

  • Hello Katherine

    Thank you for the note and glad you were able to resolve.

    The EMU0 pin circuit is set as a GPIO input pin, causing the startup to fail.

    Where was this being set - in the firmware?

    I guess the cold vs warm relates to this configuration.

    Regards,

    Sreenivasa

  • Hi Sreenivasa,

    In the hardware circuit, the EMU0 pin is used as a GPIO input pin, and a low level is collected after power-on, causing the CPU not to start.

    Our speculation is that after the cpu is connected through jtag, the script file or boot will set the pin as GPIO. Thus, when the warm is reset, the pin configuration register will not be affected, so it can be started all the time. After the cold reset, the pin defaults to emu0, so it cannot be started.

    Regards,

    Katherine

  • Hello Katherine

    Thank you.

    Could you please help me understand, if you made hardware change of firmware change to resolve the issue.

    I assume the EMU0 had a termination.

    Regards,

    Sreenivasa

  • Hi Sreenivasa,

    Yes, there is a termination. After it's temporarily disconnected, the EMU0 pin will no longer be used when the subsequent circuit board is upgraded.

    Regards,

    Katherine

  • Hello Katherine

    Noted and thank you for the valuable inputs.

    Regards,

    Sreenivasa