Other Parts Discussed in Thread: SK-AM69
Tool/software:
Hi, we are working on a new board design based off of the SK-AM69. While a number of peripherals are changed, the main startup circuitry (including the CPLD) and power are mostly unchanged (some edits, but functionally very similar). We did change the RAM chips. We generated new RAM files and pinmux files from the TI tools. Boot device is SD card.
We are getting stuck trying to boot. We have an SD protocol analyzer, and it shows that the SD card is initialized, goes to 25MHz, and loads tiboot3.bin using single block reads (by confirming the addresses read vs a dump of the SD card contents and the data of that file), and something at address 0x2000 (don't know what is there?). At this point, there's a 2 second pause, and then it repeats this cycle indefinitely. Appears to be a reset loop.
When looking at the SK-AM69 board, our protocol analyzer shows that after the tiboot3.bin load, the SD card is re-initialized and multi-block reads at 50MHz are used to read more of the card and get the next files.
We aren't sure why we can't get past this point, but how do you go about troubleshooting at this stage?
We have a Lauterbach Power Debug X51, but while it can attach to the SK-AM69 board after booting, it doesn't appear to be able to attach at this point in the boot process (it says running, no CTI), which I presume is because we haven't got far enough in the boot to load something for the debug subsystem, so the Lauterbach can't get past the CTI mux to be able to interact with specific cores. Still reading up on the documentation on this, but the ARM V8/V9 debugger seems to suggest that you can't connect at the reset vector, but have to get far enough, then have an infinite loop or something in your code to attach with a minimum of code run.
Here's some other things we have checked: power rails DC voltages look good, don't see safety error pins asserted, main 19.2MHz clock is running.
Thanks for your help.