Part Number: AM5K2E04
Analyzing the boot procedure of a TI AM5K2E04 we tumbled over an unexpectedly long period of time between the end of the reset sequence and the entrance of U-Boot.
BOOTCOMPLETE pin is used to indicate the beginning of U-Boot function board_init_f(), where we set the BOOTCOMPLETE register at address 0x0262013C to 0xFFFFFFFF to generate a rising edge of BOOTCOMPLETE pin (pin AF31).
Between the end of the reset (rising edge of RESETSTAT#, pin AH29) and the entrance of board_init_f() a duration as long as 560 ms elapses (measured with oscilloscope). We can't explain this timespan to ourselves, as we for example expect a duration of about 60 ms to copy the U-Boot (about 150 kB in size); we are using EMIF Boot mode.
Is it plausible that almost 600 ms elapse from the end of reset to the entrance of board_init_f()? What’s going on during this time?
Thanks, best regards
Please make sure you read the forum guidelines first.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Yordan Kovachev:
In reply to Gerald Ruescher:
In reply to Rex Chang:
we did the measurement and found the following:
white: BOOTCOMPLETE, set in function board_init_f() as described above
light blue: flash's ChipSelect#
The following three plots show the same boot sequence using a 152kB sized U-Boot (only the cursors differ). The plot starts with the rising edge of RESET#. We expect the blue block of the ChipSelect# signal occuring after about 460 ms and taking up about 81 ms to be the phase in which the U-Boot is copied. About 21 ms later board_init_f() is reached.
With an enlarged U-Boot of about 218 kB this block takes up 117 ms as shown in the following plot:
But the mysterious phase of 460 ms remains while copying the U-Boot does not seem to be the reason. Any ideas?
In reply to Lennart Siekmann:
The current reset sequencing doesn't match the power up sequencing shown in the K2E data manual. The RESETz signal should be at a steady high state when PORz and RESETFULLz are released and should remain high until after the device has booted. I don't know if this is causing your long delays but it should be corrected before we attempt any further debug.
If you need more help, please reply back. If your question is answered, please click Verify Answer
In reply to Bill Taboada:
Thanks for your answer. We fixed our reset sequencing and also double checked the timings of the BOOTMODE pins, but the delay still remains.
Our sequence now:
t_0 = 0: RESET# low -> high
t_1 = 100 µs: POR# low -> high
t_2 = 200 µs: RESETFULL# low -> high
BOOTMODE pins are held stable for another 400 ns after the rising edge of RESETFULL# (taken "12 transitions of the SYSCLK1 after the rising edge of RESETFULL#" and "maximum clock period is 33.33 nsec", although we expect SYSCLK1 to have a frequency of 1400 MHz).
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.