• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 100 subscribers
  • Views 1076 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.

AM3358: New board bring-up: SD card activity, but no working JTAG or uboot SPL UART output

Jay Carlson
Prodigy 185 points

Part Number: AM3358

I'm trying to bring up a simple AM335x break-out board, but I'm not getting very far. The break-out board has every I/O pin broken out to headers, with both MMC0 and MMC1 broken out to MicroSD connectors.

With no boot media in, I see the character "C" sent over UART0 eight times at approximately 144,341 baud. 

I created an SD card image using the master branch of Buildroot, using the beaglebone_defconfig. Because of potential RTC issues illustrated below, I have disabled CONFIG_SPL_AM33XX_ENABLE_RTC32K_OSC in u-boot.

With a (verified working on a BeagleBone Black) 32 GB MicroSD card inserted into either MMC0 or MMC1, I see on a logic analyzer that the AM335x initializes the SD card and reads blocks 0 through 136 from it.

However, I get no U-Boot SPL output on the UART. I've attached both a J-Link Mini EDU and a full-blown J-Link JTrace Pro Cortex-A debug probe to the board, and I get 

$ sudo JLinkGDBServer -device am3358
SEGGER J-Link GDB Server V6.80d Command Line Version
[...]
Target voltage: 3.36 V
Listening on TCP/IP port 2331
Connecting to target...
ERROR: AM335x connect: Can not find ICE-Pick (IRLen mismatch)
AM335x connect:Can not find ICE-Pick (IDCODE mismatch). Expected 0x0B00002F, found: 0xFFFFFFFF

I have verified that none of the JTAG pins are shorted to 3.3V.

Here are the schematics for the board: 

The board has several issues, as well as some variations from TI recommendations:

  • Oops: RTC_PORZ (B5) is disconnected
  • Oops: ENZ_KALDO_1P8V is disconnected
  • VDD_CORE, VDD_MPU, and VDDS_DDR are all run off a single 1.35V supply (which is within the operating ranges of the AM3358, as far as my reading suggests)
  • There is no intentional power sequencing.

I have tested on two boards, so I don't immediately suspect solder issues. I have checked that all the VDD rails are operating properly. The internal CAP_ rails measure as follows:

  • CAP_VDD_RTC: 1.08V
  • CAP_VDD_SRAM_MPU: 1.346V
  • CAP_VDD_SRAM_CORE: 1.346V
  • CAP_VBB_MPU: 1.34V

I have tried shorting CAP_VDD_RTC to VDDCORE, as suggested in the TRM, in case my disconnected RTC_PORZ/ENZ_KALDO pins were causing the RTC regulator to malfunction, but that didn't fix the boot problem.

I can verify, however, my RTC crystal isn't oscillating.

I have no problem spinning a new rev to fix the RTC bugs or change some of the design, but I'd like to feel a bit more confident that I know the magic bullet that was preventing even the JTAG from working. This is a small break-out board that I built for my own internal purposes, so frankly, it's not important if it's perfect.

I've grossly violated power sequencing specifications in the past and only seen occasional start-up glitches (one out of a hundred) on other processors I've used, so that "fix" doesn't instill a lot of confidence.

Does anyone have some guesses as to what the likely culprit is for this? Are there further design bugs I've missed? I appreciate it!

  • 0
    TI__Guru 70412 points

    Jay,

    Jay Carlson said:
    With a (verified working on a BeagleBone Black) 32 GB MicroSD card inserted into either MMC0 or MMC1, I see on a logic analyzer that the AM335x initializes the SD card and reads blocks 0 through 136 from it.

    that's a good thing, meaning lots of basic boot things are working.

    Jay Carlson said:
    However, I get no U-Boot SPL output on the UART.

    Often bootloaders depend very much on a given board and the supporting HW it has on it, including but not limited to board-ID EEPROMs, DDR configuration, and much more. Unfortunately our standard U-Boot (pretty much the same as upstream U-Boot in terms of AM335x support) doesn't initialize the serial console until very late in the boot process, so you will get no output for a host of boot issues that could occur, making debugging challenging. However what you can do is turn on the debug UART as described in the "Setup early (debug) UART" section in our U-Boot board port document here: https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/AM335X/linux/How_to_Guides/Board_Port/U-Boot.html

    Jay Carlson said:
    I've attached both a J-Link Mini EDU and a full-blown J-Link JTrace Pro Cortex-A debug probe to the board,

    As for JTAG, you probably want to double-check all your connection, to see that they are the same as on the BeagleBone Black for example. If your SoC is able to load from the boot media, I don't see a reason why JTAG would not be able to work.

    Jay Carlson said:
    There is no intentional power sequencing.

    That is very concerning. We cannot support or guarantee any kind of operation if the datasheet-mandated power sequencing isn't strictly followed. Issues are not only limited to start up issues but violating datasheet conditions will also affect device reliability and operation over time, resulting in all kinds of issues.

    From what you describe yourself there seem to be several concerns with your board, to me it sounds like re-doing the board to closer align with one of the TI reference designs would be a good thing to do.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Prodigy 185 points

    Andreas,

    Thanks for the tip on enabling early UART debugging. I honestly assumed I wasn't even getting into board.c-specific code since I wasn't getting any output at all. 

    I took out the weird EEPROM check code and just return "true" for board_is_bone_lt(), bypassed the PMIC init code, and hacked around a bit more to get things to the main U-Boot SPL banner screen. Things hang after "Trying to boot from MMC1" so I added some printfs() that get me into fat_itr_resolve(), where things seem to be hanging.

    My printf() args are getting garbled, and I noticed that it hangs while trying even just to print the next file/directory the FAT code is iterating through. To me, this looked like a stack that overflowed, but the same card boots fine on my BeagleBone Black (well, not completely, but it gets further along, and nothing is garbled).

    So my attention turns to the RAM on the board since I believe at this point U-Boot SPL is storing its stack in DRAM (correct me if I'm wrong?)

    I'm passing the beagleblack parameters to config_ddr(). I'm using IS43TR16512BL-107MBL as my RAM, which is a 1 GB (512Mx16) DDR3-1866 speed grade. I tried slowing the RAM down from 400 to 333 and finally to 303 MHz, but that hasn't fixed the problem. There's a zillion tuning parameters in there, but I don't really know where to start with that — I've worked with processors from other vendors before, and I've always just sort of soldered down whatever DDR3 chips I had laying around and haven't ever had to tune anything, so I'm suspicious of that as a possible explanation.

    Any ideas?

  • 0 in reply to Jay Carlson
    TI__Guru 70412 points

    Jay,

    Jay Carlson said:
    Thanks for the tip on enabling early UART debugging. I honestly assumed I wasn't even getting into board.c-specific code since Iwasn't getting any output at all. 

    that's great, glad it was helpful.

    Jay Carlson said:
    I took out the weird EEPROM check code and just return "true" for board_is_bone_lt()

    I wrote some of the EEPROM check code in U-Boot actually so please don't call it "weird" ;) But on a more serious note, yes that is one of the first thing it needs to go on when working on a custom board. The sole purpose of it is to make TI boards easier to use, and make it possible to use one U-Boot across many boards - something you typically don't care for custom boards, hence it is recommended to get removed.

    Jay Carlson said:

    Things hang after "Trying to boot from MMC1" so I added some printfs() that get me into fat_itr_resolve(), where things seem to be hanging.

    My printf() args are getting garbled, and I noticed that it hangs while trying even just to print the next file/directory the FAT code is iterating through. To me, this looked like a stack that overflowed, but the same card boots fine on my BeagleBone Black (well, not completely, but it gets further along, and nothing is garbled).

    That loading of U-Boot (proper) happens after DDR bringup, so if things are going wrong here DDR setup is often to blame. Can you please go to the board port document pointed to earlier (https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/AM335X/linux/How_to_Guides/Board_Port/U-Boot.html), specifically the section 'Port DDR configuration if your DDR setup (devices, clock speeds, etc.) differs from the originating platform (EVM)'. It has a reference to an application note describing AM335x DDR setup in great detail, please have a look to see if this is helpful.

    Regards, Andreas