Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

OMAP35x and AM/DM37x Initialization

From Texas Instruments Wiki
Jump to: navigation, search

This page provides tips on debugging initialization and bring-up issues with the AM37x devices.

Power sequencing

  • ensure that correct power sequencing is occurring on your board. Power sequencing specifications can be found in the data manual. In general there are no timing related specs, only that each voltage rail in the sequence must ramp individually and reach 90% of its voltage before the following rail can start ramping up. For TPS6595xx devices, this is typically done automatically. For discrete solutions, the TPS65023 design-in wiki or the the TPS65073 design-in wiki can guide you on properly designing for the correct power sequencing.

Boot sequence

  • Check your SYS_BOOT signals to ensure that you have the correct boot sequence. Boot sequence tables can be found in the initialization chapter of the TRM. These define which sources the device will potentially boot from, and in what order. If you have access to memory (via JTAG, for example), you can see what the processor read from the SYS_BOOT signals by reading the CONTROL_STATUS register (0x480022F0), bits 0-5.
  • The ROM will attempt to boot from each boot source in the defined boot sequence. If the first boot source fails to boot, the ROM will move on to the next one in the sequence. Keep in mind that some boot sources take some time to timeout if that boot source isn't avaiable (for example, USB or Ethernet). Thus, your bootup make take several seconds longer if your typical boot source is further down in the boot sequence. This is particularly evident on the AM35x EVM. If you boot from MMC on that EVM, it is 4th in a sequence behind NAND, USB, and Ethernet.

Tracing vectors

  • Tracing vectors give you some indication what the ROM code executed in its attempt to boot. This can help you determine how far the ROM got before failing to boot, and can give you some idea as to why it failed. Information on the tracing vector can be found in the Initialization chapter of the TRM. Here are some tips:
  • These are the pertinent registes for tracing data. The first 2 (0xB0 and 0xB4) contain the tracing data from the last boot sequence. The tracing vector is generally around 50 bits of information, spread across 2 32-bit words.
    • 0x4020FFB0 Current tracing vector, word 1
    • 0x4020FFB4 Current tracing vector, word 2
  • This register contains a copy of the reset status register, which will give you an indication of why the processor got reset (for example, VDD1/VDD2 voltage manager reset, External warm reset, MPU watchdog reset, Global software reset, DPLL3 software reset, Global cold reset
    • 0x4020FFB8 Current copy of the PRM_RSTST register (reset reasons)
  • These registers contain the tracing vectors from the first time after a cold reset.
  • 0x4020FFBC Cold reset run tracing vector, word 1
  • 0x4020FFC0 Cold reset run tracing vector, word 2
  • 0x4020FFC4 Reserved

Here are some examples on how to interpret the tracing vectors:

Tracing Example 1

SYSBOOT = 001111 (boot from NAND,USB,UART3,MMC1) After failed boot, cold reset tracing vector reads:

  • 0x4020FFBC = 0x0007307F
  • 0x4020FFC0 = 0x001E0044


Comparing this to the tracing vector table in the Initialization Chapter of the TRM, we see that the following bits are set:


Bit Meaning Comment
0 Reset Reset occurred
1 ROM code C main ROM code hit the main() function in the C code
2 ROM code runs after the cold reset  
3 Booting started  
4 Memory booting started Indicates that the ROM attempted to boot from a memory source
5 No more booting device to check Indicates that the ROM exhaused all boot sources
6 Peripheral booting started Indicates that the ROM attempted to boot from a peripheral source
7 Booting message "change device" Indicates ROM moved to the next booting source in the sequence
12 Device initialized Indicates that the peripheral device was initialized
13 ASIC-ID sent ID was sent as part of the UART boot process
16 Peripheral booting failed Indicates boot failed (in this case, UART boot, since it was the only peripheral boot source)
17 UART Indicates UART booting was attempted
18 USB Indicates booting from USB was attempted
34 NAND Indicates booting from NAND was attempted
38 MMC/SD1 Indicates booting from MMCSD1 was attempted
49-51 NAND boot Indicates NAND booting was attempted from the first 4 blocks of the NAND.

Tracing Example 2

SYSBOOT = 110001 (boot from USB,UART,MMC1,MMC2) After failed boot, cold reset tracing vector reads:

  • 0x4020FFBC = 0x0007307F
  • 0x4020FFC0 = 0x00000060


Comparing this to the tracing vector table in the Initialization Chapter of the TRM, we see that the following bits are set:


Bit Meaning Comment
0 Reset Reset occurred
1 ROM code C main ROM code hit the main() function in the C code
2 ROM code runs after the cold reset  
3 Booting started  
4 Memory booting started Indicates that the ROM attempted to boot from a memory source
5 No more booting device to check Indicates that the ROM exhaused all boot sources
6 Peripheral booting started Indicates that the ROM attempted to boot from a peripheral source
7 Booting message "change device" Indicates that ROM code moved on to another booting source
12  Device initialized Indicates that the peripheral device was initialized
13 ASIC-ID sent ID was sent as part of the UART boot process
16 Peripheral booting failed Indicates one of the peripheral booting sources faied (either USB or UART in this case)
17 UART Indicates UART booting was attempted
18 Peripheral boot Indicates USB booting was attempted
37  MMC/SD2 Indicates booting from MMCSD2 was attempted
38  MMC/SD1 Indicates booting from MMCSD1 was attempted

NAND Booting

For those needed help in performing NAND booting on their custom boards, please refer to the OMAP Flashing wiki

UART/USB Booting

Here is some additional information on the ASIC ID Structure used during UART3 and USB booting. Only the information for Public general purpose (GP) devices is shown here. The ASIC ID is 58 bytes on UART and 69 Bytes on USB. Note that the Checksum subblock is not transmitted over the UART, only over USB.



ASIC ID Item Size (bytes) Description
Items 1 Number of sub blocks
ID Subblock 7 Device identification information
Reserved for non-GP devices 4 see Reserved1
2nd ID Subblock 23 ROM Identification data
Reserved for non-GP devices 23 see Reserved2
Checksum subblock 11 CRC


Items

Offset Size (bytes) Value
00h 1 05h - number of sub blocks USB
04h - number of sub blocks UART



ID Subblock

Offset Size (bytes) Value
01h 1 01h - sub block ID
02h 1 05h - sub block size
03h 1 01h - fixed value
04h 2 34h, 30h - OMAP chip version for OMAP35x
36h, 30h - OMAP chip version for AM/DM37x
06h 1 07h - ASCII bell
07h 1 XXh - ROM revision



Reserved1

Offset Size (bytes) Value
08h 1 13h - sub block ID
09h 1 02h - sub block size
0Ah 1 01h - fixed value
0Bh 1 00h - GP device



2nd ID Sub block

Offset Size (bytes) Value
0Ch 1 12h - sub block ID
0Dh 1 15h - sub block size
0Eh 1 01h - fixed value
0Fh 20h 00h - GP device



Reserved2

Offset Size (bytes) Value
23h 1 14h - sub block ID
24h 1 15h - sub block size
25h 1 01h - fixed value
26h 20 00h ... - GP device



Checksum Subblock

Offset Size (bytes) Value
3Ah 1 15h - sub block ID
3Bh 1 09h - sub block size
3Ch 1 01h - fixed value
3Dh 4 XXXXXXXXh - ROM CRC
41h 4 00000000h

ASIC ID output examples

AM-DM37x ASIC ID output.JPG OMAP35x ASIC ID output.JPG


MMC booting