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.

AM3359: Next step in bringing up AM3359-based board

Part Number: AM3359

I have a custom board design based on the AM3359 that I'm having difficulty bringing up.  To simplify bringing up uboot & the kernel, much of the design is based on the Beaglebone Black schematic (same connections to SD card, same DDR3 memory part number connected in same manner).  I'm using CCS 9.1 and a Spectrum Digital XDS200 for troubleshooting.

I've been following the advice from http://processors.wiki.ti.com/index.php/AM335x_board_bringup_tips#DDR_configuration and could use some help on what to try next.

From CCS, if I open a memory browser window and try to access the memory at 0x0800 0000, I don't get anything. The MMU is off.

I've run the am335x-boot.dss boot analysis script and verified that the boot order is MMC1->MMC0->UART0->USB0.  I've brought the clock out (sysboot[5] = 1) and verified that it's 24MHz as expected.

I have an SD card that successfully boots the Beaglebone Black that I'm trying to use on the custom board.  If I power the board without the SD card, I get the stream of Cs on UART0 that are expected.

If I try to power the board with the SD card in the SD card slot (attached to MMC0), I don't get any console output on UART0 – was hoping to make it at least to uboot. The program counter is in the dead loop at 0x0002 0088 corresponding to a pre-fetch abort exception.

If I were having an issue with power sequencing, I don’t believe I would have made it as far as executing ROM code – is this correct?  Should I be able to read/write from the DDR3 from the memory browser prior to coding any board-specific DDR3 timing?  Could I please get some help as to what to try next?

Thanks!

 

  • Hello Eric,

    Can you apply the linked patch in this post and check whether your board will start to boot?

    Best regards,
    Kemal

  • Hi Kemal,

    I applied the patch, rebuilt u-boot and created a new SD card image (only put MLO & u-boot.img into image for now). It seems it made it a bit further, but now PC is stuck at 0x402F0440 - here's the boot analysis log...

    CONTROL: device_id = 0x2b94402e
    * AM335x family
    * Silicon Revision 2.1

    PRM_DEVICE: PRM_RSTST = 0x00000001
    * Bit 0 : GLOBAL_COLD_RST

    CONTROL: control_status = 0x0040033c
    * SYSBOOT[15:14] = 01b (24 MHz)
    * SYSBOOT[11:10] = 00b No GPMC CS0 addr/data muxing
    * SYSBOOT[9] = 0 GPMC CS0 Ignore WAIT input
    * SYSBOOT[8] = 0 GPMC CS0 8-bit data bus
    * Device Type = General Purpose (GP)
    * SYSBOOT[7:6] = 00b MII (EMAC boot modes only)
    * SYSBOOT[5] = 1 CLKOUT1 enabled
    * Boot Sequence : MMC1 -> MMC0 -> UART0 -> USB0

    ROM: Current tracing vector, word 1 = 0x0010009f
    * Bit 0 : [General] Passed the public reset vector
    * Bit 1 : [General] Entered main function
    * Bit 2 : [General] Running after the cold reset
    * Bit 3 : [Boot] Main booting routine entered
    * Bit 4 : [Memory Boot] Memory booting started
    * Bit 7 : [Boot] GP header found
    * Bit 20 : [Configuration Header] CHSETTINGS found

    ROM: Current tracing vector, word 2 = 0x00011000
    * Bit 12 : [Memory Boot] Memory booting trial 0
    * Bit 16 : [Memory Boot] Execute GP image

    ROM: Current tracing vector, word 3 = 0x00001000
    * Bit 12 : Memory booting device SPI

    ROM: Current copy of PRM_RSTST = 0x00000000

    ROM: Cold reset tracing vector, word 1 = 0x00000000

    ROM: Cold reset tracing vector, word 2 = 0x00000000

    ROM: Cold reset tracing vector, word 3 = 0x00000001
    * Bit 0 : [Memory Boot] Memory booting device NULL

    Cortex A8 Program Counter = 0x402f0440

    That was with the SD card in.  I'm still not getting any UART0 output.  I booted again with the SD card out - still get the stream of Cs, so I know my connection's good.  After the program counter gets stuck, I am able to connect to the target and see all zeros at 0x8000 0000 now, but if I try to write to the memory, I get a memory verification error.  Here's a screenshot from CCS.

    Is this a familiar address for the PC to stop on?  Should I focus on the DDR3 configuration from here, http://processors.wiki.ti.com/index.php/AM335x_DDR_PHY_register_configuration_for_DDR3_using_Software_Leveling?

    Thanks

  • Can you post the serial console output without the JTAG attached?

  • Hi Kemal,

    Just tried booting without then with the SD card, no JTAG attached.  Without the SD card, I get CCCCC..., and with the SD card, I get no console output at all.  I'm assuming serial output remains 115200, N, 8, 1, correct?

    Thanks,

    Eric

  • Hello Eric,

    I recommended adding the following line of code in the file <u_boot_dir>/arch/arm/mach-omap2/am33xx/board.c:

    int board_early_init_f(void)
    {
            asm("test: nop");
            asm("       nop");
            asm("  b test");
            asm(" nop");
            asm(" nop");
    
            prcm_init();
            set_mux_conf_regs();
    #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_RTC_DDR_SUPPORT)
            update_rtc_magic();
    #endif
            return 0;
    }

    Next, compile Uboot and copy the MLO/u-boot.img to the SD card. Power on the board and connect to CCS (no gel file). After, connecting to CCS, please load the symbol "<u_boot_dir>/spl/u-boot-spl". On the CCS, you will notice the code is stuck inside the branch statement and you can easily change the program counter to exit out from the branch statement. This will allow you to step through MLO and it will guide you in figuring out the failure.

    Regards,
    Krunal

  • Hi Krunal,

    I wasn't able to get SPL to stop with the code you suggested, but was able to just add a hardware breakpoint at _main and step from there.  I realized later that CONFIG_BOARD_EARLY_INIT_F wasn't set in the .config file.

    Regardless, the failure occurs in a call to rtc32k_enable() in board.c.  If I try to step into that function, it instead gets stuck at 0x402f0440.

    Thanks,
    Eric

    
    

     

  • Hello Eric,

    I am wondering if your custom board uses RTC oscillator.

    Regards,
    Krunal

  • Hi Krunal,

    Yes, we followed the design of the 32.768kHz oscillator from the Beaglebone Black, so have the same circuit on our custom board.  The difference is that our design used a CTS crystal (TFE202P32K7680R, load capacitance 12.5pF, max ESR 50k, shunt capacitance 1.8pF, 0.5uW drive level) instead of the Citizen crystal on the BBB.  We also used the same 18pF caps to ground from each lead of the crystal.  I'm fine with not enabling the 32k crystal for now to see how much further I can get in the boot.  I'm not sure what other functions are called later w/ regard to the RTC, so I would appreciate your suggestion as to which CONFIG options I should comment out or remove to not enable the 32k RTC oscillator in SPL.

    I'd also appreciate any insight you may have as to what's going wrong with the 32k oscillator.

    Thanks,

    Eric

  • Hello Eric,

    Please refer to the following thread and let me know if it helps with your debugging.

    Regards,
    Krunal

  • Hi Krunal,

    It helped me to know what to look for, but I think maybe the thread references files in a different version of the SDK - didn't find either item referenced.  So, instead I used, "make menuconfig" after selection of the default configuration, navigated to SPL, then found the option "Enable the RTC32K_OSC on AM33xx based platforms."

    It's not selectable because the BOOTCOUNT_AM33XX count limit option is selected.  I guess it makes use of the real time clock so it sets the RTC32K_OSC option.

    I cleared the BOOTCOUNT_AM33XX option (from the top level, navigate to device drivers, and deselect "Enable support for checking boot count limit") and was then able to clear the RTC32K_OSC enable.

    I was able to make it to sdram_init before it crashed again.  I haven't yet identified the exact line where it hangs, but maybe that suggests to you what to look for next?

    Thanks,

    Eric  

  • Hello Eric,

    In general, SPL needs to load u-boot.img to DDR but the DDR needs to be initialized first. The initialization happens in the sdram_init function. I am wondering if you have verified the DDR on your custom board. 

    Here are a few reference threads related to DDR:
    1.https://e2e.ti.com/support/processors/f/791/t/511797?AM335x-DDR-size-in-Linux
    2.https://e2e.ti.com/support/processors/f/791/t/548685?How-to-do-DDR-calibration-for-AM335x-
    3.https://e2e.ti.com/support/processors/f/791/t/721547?AM3352-DDR-clock-problem

    Regards,
    Krunal