Custom board - AM3359ZCZ

Miha Gostencnik

Other Parts Discussed in Thread: CODECOMPOSER, AM3359

Good day,

have a problem and was hopping for some help.

We made a custom board based on the XAM3359ZCZ processor and produced few prototypes that were running flawlessly and they are still. Now, the problem started when we ordered the first larger batch with the official AM3359 processor. Inserted the microSD card and was hoping to see a clean boot, but as it turned out the original u-boot/Kernel are not booting (used the same card as with the prototypes). The only major hardware change was switching to a production level microprocessor, since the former was still labeled as X. Went throught almost the whole batch and majority stopped at the same time, just before the kernel image would be read. Tested them also with the CodeComposer's GEL scripts for DDR2 (Quick Test) and it went throught with no errors (on 266MHz). Where on the first prototypes we needed to lower the frequency to 200MHz for a successfull test with CCS, but with the u-boot/kernel the 266MHz setting worked fine.

Here is the original u-boot output (attached image):

and here is the output tested with a newer u-boot, with some additional printfs:

U-Boot SPL 2012.10 (Mar 02 2013 - 19:33:59)

void enable_board_pin_muxBeaglebone pinmux.DEBUG: config_ddr: EMIF_REG_SDRAM_TYPE_DDR2

void am33xx_spl_board_init(void)

BeagleBone PMIC Code

int board_mmc_init(bd_t *bis) - boot_commonomap_mmc_init(0, 0, 0);

OMAP SD/MMC: 0

mmc_send_cmd : timeout: No status update

Card did not respond to voltage select!

spl: mmc init failed: err - -17

### ERROR ### Please RESET the board ###

U-Boot SPL 2012.10 (Mar 02 2013 - 19:33:59)

void enable_board_pin_muxBeaglebone pinmux.DEBUG: config_ddr: EMIF_REG_SDRAM_TYPE_DDR2

void am33xx_spl_board_init(void)

BeagleBone PMIC Code

int board_mmc_init(bd_t *bis) - boot_commonomap_mmc_init(0, 0, 0);

OMAP SD/MMC: 0

## Baudrate 170192 bps not supported

spl: mmc init failed: err - 1

### ERROR ### Please RESET the board ###

Mind the two different outputs (second one with the baudrate error). Could this be the frequency related issue, because with the newer u-boot a colleague of mine set the processor's frequency to 500MHz? He had to lower it to 500MHz just to be able to cancel the autoboot and get into u-boot's shell.

Some additional info regarding the board: "Inspiration" for schematic was taken from the EVM and Beaglebone with also some custom parts which were successfully tested with the prototypes. For the main PMIC the TPS65910AA1 was used, 512MB DDR2 memory, TFP410P, dual ETH with DP83849 and so on.

Thank you very much for reading throught this post and have a nice day.

over 13 years ago

0 Miha Gostencnik over 13 years ago

Prodigy 180 points

Good day,

some more informations, if it helps. The processor's AM3359ZCZD72 revision number is 2AA6DHW GI 962.

0 Charles Butkus over 13 years ago

Prodigy 200 points

If you're having to underclock it to get uboot stable, there's something wrong with your ram timings/who knows what else.

Use the jtag and step through the uboot code as it comes up..

http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_uboot_linux_debug_with_ccsv5

int board_mmc_init(bd_t *bis) - boot_commonomap_mmc_init(0, 0, 0);

OMAP SD/MMC: 0

mmc_send_cmd : timeout: No status update

Card did not respond to voltage select!

spl: mmc init failed: err - -17

Can you do a capture from a working board?

If some boards are fine, and others aren't.. sounds like a manufacturing defect.

Usually I'm pretty happy to get the "### ERROR" because it means my MLO is working, and it just couldn't find u-boot.img because I haven't gotten that far yet.

You have mmc CardDetect wired up and working properly? I don't *think* that u-boot cares about it, but it's worth a check.

0 Miha Gostencnik over 13 years ago in reply to Charles Butkus

Prodigy 180 points

Hello all,

let me share some new pointers regarding this problem.

Charles Butkus said:

If you're having to underclock it to get uboot stable, there's something wrong with your ram timings/who knows what else.

Apperantly DDR is working fine, since we've tested it with the CCS and later also with a "customized" u-boot that directly calls/tests the DDR without putting in the "mtest" command. But if we manually run the mtest command in prompt, we get errors.

Charles Butkus said:

Use the jtag and step through the uboot code as it comes up..

http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_uboot_linux_debug_with_ccsv5

Tried this, but couldn't get it working. Probably has to do something with eclipse and plugin versions. Will give it a try on a different computer.

Charles Butkus said:

int board_mmc_init(bd_t *bis) - boot_commonomap_mmc_init(0, 0, 0);

OMAP SD/MMC: 0

mmc_send_cmd : timeout: No status update

Card did not respond to voltage select!

spl: mmc init failed: err - -17

Can you do a capture from a working board?

If some boards are fine, and others aren't.. sounds like a manufacturing defect.

A majority of boards are fine, but all act the same with the same problem. With those that aren't working, I cant even access the CPU through CCS and even MLO, u-boot doens't work, not even the serial and "CCCC...". These will be debuged a bit later, after we find this problem/solution.

Charles Butkus said:

Usually I'm pretty happy to get the "### ERROR" because it means my MLO is working, and it just couldn't find u-boot.img because I haven't gotten that far yet.

You have mmc CardDetect wired up and working properly? I don't *think* that u-boot cares about it, but it's worth a check.

Checked both settings and neither is the problem. U-boot is not checking this pin, but I know that kernel does. Since this was the problem with the first prototypes and this was the first thing I checked.

0 Alexander Golovlev1 over 13 years ago in reply to Miha Gostencnik

Prodigy 10 points

Hi Miha!

Do you have any progress with this problem? I'm currently facing the "mmc_send_cmd : timeout: No status update" problem & can't figure the origin of it.

0 Miha Gostencnik over 13 years ago in reply to Alexander Golovlev1

Prodigy 180 points

Hi Alexander,

my apologies for such a late response.

We actually found the problem/solution and it was, as always, right in front of us. In the end, it was as Charles suggested. The problem was with DDR timings. We've downloaded those excel tables and inserted the outcome numbers in u-boot. Had to tweak them some more to work at max frequency, but in the end it worked.

With added printf's in the code as we were trying to find the problem, we just delayed the memory reading/writing bursts and thus the error was not always at the same time.

Hope this also solves the problem with you.

Have a nice day,

Miha

Processors

Processors forum

Custom board - AM3359ZCZ