AM1705 UART2 boot issue

Since there is no JTAG debug, this will be difficult to determine the issue.

Can you send a scope shots with all boot pins relative to reset? One possibility is the wrong boot mode is being latched. Also showing the power rails with respect to the some of the boot pins will help.

Jeff

Hello Jeff,

We have measured using DSO pin voltages at reset.

We have seen these voltage levels on CRO at the IC pin.

We have observed that BOOT13, BOOT14 & BOOT12 pins toggle post reset, as per MMCSD waveforms as given in datasheet page 77.

We do have JTAG interface on-board but do not have emulator.

Kindly advise on what to do further.

Rgds,

Roma

The voltage levels you show look correct.

After the boot failure, if you apply a second reset, does the behavior change, or do you still see those 3 boot pins toggling? Have you checked any other pins for activity or is it only those 3?

At this point I think you need an emulator to determine the cause of failure. Is it possible to get one?

Jeff

Hello,

We have placed order for Emulator; however same will not be available till next week.

In the meanwhile, we tried configuring different boot modes to check if CPU is responding correctly.

We tried following boot modes:

1) SPI0 Flash boot mode.

Result:

a) No activity on SPI0 lines. MMCSD lines toggle only for one cycle. Voltage level on SPI0_CLK/BOOT2 is 0.9V at reset and 0.8V post reset.

b) Changed PU value from 2.2K to 1K. Voltage level on SPI0_CLK/BOOT2 is 3.3V post and pre-reset.

2) I2C0 Master Boot mode

Result: Observed I2C Clock as per data rate mentioned in datasheet.

Do you think there is an issue in PU & PD values?

Also, once we receive the emulator, if for some reason CPU does not go into emulator debug mode, will emulator help?

Rgds,

Roma

You do not need to be in emulator boot mode to connect with the emulator. See the following wiki for details:

http://processors.wiki.ti.com/index.php/OMAP-L138_Bootloader#When_should_I_use_Emulation_Boot_Mode.3F

On that part there is no MMCSD boot mode so it is probably the EMIF pins toggling instead. Once you changed to 1k pullups did you see any activity on the SPI0 lines? If a 2.2K pullup was giving a .9V on BOOT2 then a stronger pullup is needed.

Jeff

Hello,

We do not see any activity on SPI0 lines (boot config: SPI0) after changing the PU value to 1K.

As previously mentioned, Emulator is expected by next week. In the meanwhile, is there something else we can check on to determine if CPU is working?

Is there any pin we can check to know if CPU has initialised (say Resetout or Clkout)?

Kindly revert on same at the earliest.

rgds,

Roma

You should see RESETOUT go high after RESET is deasserted. If it does can you measure the time between the two rising edges?

Jeff

Hello,

We re-checked and found AM1705 does not have a RESETOUT pin. Is there some other pin which will help us understand if AM1705 is initialising correctly?

We have checked Clock stability versus Reset de-activation timing for correct initialising of AM1705, that seems to be as mentioned in datasheet. This seems to be ok.

As no specific delay time has been given in datasheet between VCORE & VCC, we modified our circuit, to increase delay between VCORE to VCC turn on time. VCORE voltage ramps first and then after 12-15msec VCC voltage turns on.

We still see the same problem, UART2 boot mode, SPI0 Flash mode or UART0 boot mode do not work (We changed the boot settings accordingly on hardware).

To remove the doubt of dry solder, we also got the IC pins re-soldered.

Kindly adivse on what else can be done till we get the emulator.

Rgds,

Roma

The CLKOUT pin will not be active after reset even in a working case so that cannot be used to tell anything.

Can you please clarify whether or not a second POR changes the behavior at all? If there is still no activity on the UART pins, that would show more definitively that the incorrect boot mode is being latched.

Jeff

Hello,

I am referring to page 42 of datasheet, wherein OSCIN has to be stable prior to RESET pin deactivation. We checked this on our card.

We are referring to datasheet attached, wherein there is no CLKOUT or RESETOUT pin. 3731.am1705-amcpu-oct10.pdf

 Pls let us know if attached datasheet is the correct datasheet we are referring to.

Also, pls let us know on which page of datasheet are RESETOUT & CLKOUT pins defined.

Kindly do revert back.

Thanks & Regards,

Roma

Correct for AM1705 neither RESETOUT nor CLKOUT are pinned out.

Did a second POR change anything?

Jeff

Hello,

Second POR has no effect.

UART2 boot or SPI0 Flash boot still does not work.

Rgds,

Roma

If the second POR has no effect then that seems to eliminate any issue with the power sequence and RESET timing.

Will you be getting the emulator soon? That may be the only way to find the root cause of this.

Jeff

Hello,

We got the emulator, and we found that as per hardware PU/PD resistor settings for Boot mode, correct boot mode is latched; i.e., if UART2 boot mode is configured then correct setting is being latched within the CPU.

However, if we connect UART2 on Hyperterminal to check for "Boot Me" then we do not see any message.

We were able to test GPIO section by driving LED On & Off.

We tried accessing on-board SDRAM when emulator is present and have found that CCS hangs or gives an error.

We are still not able to proceed beyond this point. Do suggest a solution.

Rgds,

Roma

Hi Jeff,

Continuance to previous observations, below is addition details

I am using ARM UBL provided in DaVinci-PSP-SDK-03.20.00.12 for AM1705.

I modified the ARM UBL code for board testing. The device initialization is done as per the ARM UBL provided in DaVinci-PSP-SDK-03.20.00.12.

I tested my GPIO Debug code for the board & it is working properly.

But for testing UART & SDRAM the code hangs during debug process in DEVICE_PLL0Init() function.

DEVICE_PLL0Init is same as per DaVinci-PSP-SDK-03.20.00.12.

I have attached the ARM UBL code given in DaVinci-PSP-SDK-03.20.00.12.

Please revert back on above issue

Thanks & Regards

Jitendra7610.armubl-03.20.00.12.tar.gz

Is PLL initialization the only thing not working? Can you run in bypass and internal memory and not have any issues?

In the PLL0Init function, can you step through and tell which line it is hanging on? Thanks

Jeff

Also, when you set UART2 boot mode, after reset can you connect in CCS and give the address of the program counter? The debug GEL file will also provide useful information such as the PC and any ROM error messages that you can paste here.

Jeff

HI Jeff,

The CCS is hanging at PLL setting, the part of the code where hang condition occurs is given below

The code given below is the part of  DEVICE_PLL0Init( ) function

PLL0->PLLCTL |= 0x1;

SYSTEM->CFGCHIP[3] |= 0x4;       // Enable 4.5 divider PLL0

      SYSTEM->CFGCHIP[3] |= 0x1;       // Select 4.5 divider for EMIFA / EMIFB clock source

but when i keep the EMIFB clock source at SYSCLK5 setting then code doesn't hangs.

But when i do not debug the DEVICE_Init( ) function then code works properly.

And regarding UART2 debug the output of the debug gel file is given below.

ARM9_0: GEL Output: 

---------------------------------------------

ARM9_0: GEL Output: |             Device Information            |

ARM9_0: GEL Output: ---------------------------------------------

ARM9_0: GEL Output: DEV_INFO_00 = 0x9B7DF02F

ARM9_0: GEL Output: DEV_INFO_01 = 0x00000000

ARM9_0: GEL Output: DEV_INFO_02 = 0x0000F3F2

ARM9_0: GEL Output: DEV_INFO_03 = 0x00000012

ARM9_0: GEL Output: DEV_INFO_04 = 0x00000000

ARM9_0: GEL Output: DEV_INFO_05 = 0x000003E0

ARM9_0: GEL Output: DEV_INFO_06 = 0x00000080

ARM9_0: GEL Output: DEV_INFO_07-DEV_INFO_08-DEV_INFO_09-DEV_INFO_10-DEV_INFO_11-DEV_INFO_12 = 8-0-152949-21-11-42

ARM9_0: GEL Output: DEV_INFO_13,DEV_INFO_14,DEV_INFO_15,DEV_INFO_16 = 0,0,0,15871

ARM9_0: GEL Output: -----

ARM9_0: GEL Output: DEV_INFO_17 = 0x00030003

ARM9_0: GEL Output: DEV_INFO_18 = 0x00000000

ARM9_0: GEL Output: DEV_INFO_19 =ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 

ARM9_0: GEL Output: -----

ARM9_0: GEL Output: DEV_INFO_20 = 0x00000000

ARM9_0: GEL Output: DEV_INFO_21 = 0x00000000

ARM9_0: GEL Output: DEV_INFO_22 = 0x30303864

ARM9_0: GEL Output: DEV_INFO_23 = 0x3330306B

ARM9_0: GEL Output: -----

ARM9_0: GEL Output: DEV_INFO_24 = 0x1502A00B

ARM9_0: GEL Output: DEV_INFO_25 = 0x08025575

ARM9_0: GEL Output: DEV_INFO_06 = 0x00000080

ARM9_0: GEL Output: DEV_INFO_26 = 0x7BFE0000

ARM9_0: GEL Output: 

ARM9_0: GEL Output: ---------------------------------------------

ARM9_0: GEL Output: |               BOOTROM Info                |

ARM9_0: GEL Output: ---------------------------------------------

ARM9_0: GEL Output: ROM ID: d800k003 

ARM9_0: GEL Output: Silicon Revision 2.0

ARM9_0: GEL Output: Boot Mode: UART2

ARM9_0: GEL Output: 

ROM Status Code: 0x00000000 

Description:ARM9_0: GEL Output: No error

ARM9_0: GEL Output: 

Program Counter (PC) = 0xFFFD6244

ARM9_0: GEL Output: 

ARM9_0: GEL Output: ---------------------------------------------

ARM9_0: GEL Output: |              Clock Information             |

ARM9_0: GEL Output: ---------------------------------------------

ARM9_0: GEL Output: 

ARM9_0: GEL Output: PLLs configured to utilize crystal.

ARM9_0: GEL Output: ASYNC3 = PLL0_SYSCLK2

ARM9_0: GEL Output: 

ARM9_0: GEL Output: NOTE:  All clock frequencies in following PLL sections are based

ARM9_0: GEL Output: off OSCIN = 24 MHz.  If that value does not match your hardware

ARM9_0: GEL Output: you should change the #define in the top of the gel file, save it,

ARM9_0: GEL Output: and then reload.

ARM9_0: GEL Output: 

ARM9_0: GEL Output: ---------------------------------------------

ARM9_0: GEL Output: |              PLL0 Information             |

ARM9_0: GEL Output: ---------------------------------------------

ARM9_0: GEL Output: 

ARM9_0: GEL Output: PLL0_SYSCLK1 = 24 MHz

ARM9_0: GEL Output: PLL0_SYSCLK2 = 12 MHz

ARM9_0: GEL Output: PLL0_SYSCLK3 = 24 MHz

ARM9_0: GEL Output: PLL0_SYSCLK4 = 6 MHz

ARM9_0: GEL Output: PLL0_SYSCLK5 = 24 MHz

ARM9_0: GEL Output: PLL0_SYSCLK6 = 24 MHz

ARM9_0: GEL Output: PLL0_SYSCLK7 = 4 MHz

ARM9_0: GEL Output: 

ARM9_0: GEL Output: ---------------------------------------------

ARM9_0: GEL Output: |              PSC0 Information             |

ARM9_0: GEL Output: ---------------------------------------------

ARM9_0: GEL Output: 

ARM9_0: GEL Output: State Decoder:

ARM9_0: GEL Output:  0 = SwRstDisable (reset asserted, clock off)

ARM9_0: GEL Output:  1 = SyncReset (reset assered, clock on)

ARM9_0: GEL Output:  2 = Disable (reset de-asserted, clock off)

ARM9_0: GEL Output:  3 = Enable (reset de-asserted, clock on)

ARM9_0: GEL Output: >3 = Transition in progress

ARM9_0: GEL Output: 

ARM9_0: GEL Output: Module 0: EDMA3CC (0)        STATE = 0

ARM9_0: GEL Output: Module 1: EDMA3 TC0          STATE = 0

ARM9_0: GEL Output: Module 2: EDMA3 TC1          STATE = 0

ARM9_0: GEL Output: Module 3: EMIFA (BR7)        STATE = 0

ARM9_0: GEL Output: Module 4: SPI 0              STATE = 0

ARM9_0: GEL Output: Module 5: MMC/SD 0           STATE = 0

ARM9_0: GEL Output: Module 6: AINTC              STATE = 3

ARM9_0: GEL Output: Module 7: ARM RAM/ROM        STATE = 3

ARM9_0: GEL Output: Module 9: UART 0             STATE = 0

ARM9_0: GEL Output: Module 10: SCR 0 (BR0/1/2/8)  STATE = 3

ARM9_0: GEL Output: Module 11: SCR 1 (BR4)        STATE = 3

ARM9_0: GEL Output: Module 12: SCR 2 (BR3/5/6)    STATE = 3

ARM9_0: GEL Output: Module 13: PRUSS              STATE = 0

ARM9_0: GEL Output: Module 14: ARM                STATE = 3

ARM9_0: GEL Output: Module 15: DSP                STATE = 0

ARM9_0: GEL Output: 

ARM9_0: GEL Output: ---------------------------------------------

ARM9_0: GEL Output: |              PSC1 Information             |

ARM9_0: GEL Output: ---------------------------------------------

ARM9_0: GEL Output: 

ARM9_0: GEL Output: State Decoder:

ARM9_0: GEL Output:  0 = SwRstDisable (reset asserted, clock off)

ARM9_0: GEL Output:  1 = SyncReset (reset assered, clock on)

ARM9_0: GEL Output:  2 = Disable (reset de-asserted, clock off)

ARM9_0: GEL Output:  3 = Enable (reset de-asserted, clock on)

ARM9_0: GEL Output: >3 = Transition in progress

ARM9_0: GEL Output: 

ARM9_0: GEL Output: Module 1: USB0 (2.0)         STATE = 0

ARM9_0: GEL Output: Module 2: USB1 (1.1)         STATE = 0

ARM9_0: GEL Output: Module 3: GPIO               STATE = 0

ARM9_0: GEL Output: Module 4: UHPI               STATE = 0

ARM9_0: GEL Output: Module 5: EMAC               STATE = 0

ARM9_0: GEL Output: Module 6: EMIFB (BR20)       STATE = 0

ARM9_0: GEL Output: Module 7: MCASP0 + FIFO      STATE = 0

ARM9_0: GEL Output: Module 8: MCASP1 + FIFO      STATE = 0

ARM9_0: GEL Output: Module 9: MCASP2 + FIFO      STATE = 0

ARM9_0: GEL Output: Module 10: SPI 1              STATE = 0

ARM9_0: GEL Output: Module 11: I2C 1              STATE = 0

ARM9_0: GEL Output: Module 12: UART 1             STATE = 0

ARM9_0: GEL Output: Module 13: UART 2             STATE = 3

ARM9_0: GEL Output: Module 16: LCDC               STATE = 0

ARM9_0: GEL Output: Module 17: eHRPWM (all)       STATE = 0

ARM9_0: GEL Output: Module 20: eCAP (all)         STATE = 0

ARM9_0: GEL Output: Module 21: eQEP 0/1           STATE = 0

ARM9_0: GEL Output: Module 24: SCR8 (Br15)        STATE = 3

ARM9_0: GEL Output: Module 25: SCR7 (Br12)        STATE = 3

ARM9_0: GEL Output: Module 26: SCR12 (Br18)       STATE = 3

ARM9_0: GEL Output: Module 31: L3 RAM (Br13)      STATE = 3

Hi Jeff,

The points given below are my queries & their observation. 

UART2 BOOTMODE :

Regarding UART2 Boot mode, The "BOOTME" word occurs at UART2 TX only when I connect XDS100V2 Emulator & click on "connect target" option from the CCS4 Target configuration window for XDS100V2 USB Emulator.

When XDS100V2 USB Emulator is connected at that moment AM1705 "BOOTME" appears on the UART2.

AND when AM1705 CPU is power ON without XDS100V2 USB Emulator then "BOOTME" word DOESN'T appear.

UART0 BOOTMODE:

For UART0 Boot mode also the "BOOTME" word occurs at UART0 TX only when I connect XDS100V2 Emulator & click on "connect target" option from the CCS4 Target configuration window for XDS100V2 USB Emulator.

And without XDS100V2 USB Emulator the "BOOTME" DOESN'T appears.

UART 1 & UART0 peripherals:

On my AM1705 board UART2 peripheral is working properly. I have attached a SDRAM-Test.rar file it contains my SDRAM Debug code & with this code UART2 & SDRAM works properly.

BUT for UART1 & UART0 the code that I have attached is not working.

I made SDRAM Debug code by modifing ARM-UBL code provided in DaVinci-PSP-SDK-03.20.00.12 & the code should work for UART0 & UART1 in AM1705.

Can you please look into it why UART1 & UART0 is not working, the UART1 & UART0 initialization is same as ARM UBL. BUT "BOOTME " word appears at UART0 port when emulator is connected, That means UART0 port is working, So where the issue can be???

These are the issues which we are facing for AM1705 CPU.

Jeff  Please revert back on above given issue as soon as possible.

Thanks & Regards

Jitendra Jagasia

2465.SDRAM Test.rar

Hi Jeff,

The points given below are my queries & their observation. 

UART2 BOOTMODE :

Regarding UART2 Boot mode, The "BOOTME" word occurs at UART2 TX only when I connect XDS100V2 Emulator & click on "connect target" option from the CCS4 Target configuration window for XDS100V2 USB Emulator.

When XDS100V2 USB Emulator is connected at that moment AM1705 "BOOTME" appears on the UART2.

AND when AM1705 CPU is powered ON without XDS100V2 USB Emulator then nothing appears on UART2.

UART0 BOOTMODE:

For UART0 Boot mode also the "BOOTME" word occurs at UART0 TX only when I connect XDS100V2 Emulator & click on "connect target" option from the CCS4 Target configuration window for XDS100V2 USB Emulator.

And without XDS100V2 USB Emulator nothing appears on UART0.

SDRAM:

Please refer to my previous post.

SDRAM is working with AM1705 with the emulator.

EMULATOR CONNECTION ISSUE:

AT the end of our day, We changed OUR BOOT MODE from UART0 TO SPI0 FLASH MODE [ BY changing RESISTER combination ]. AND after changing the BOOT mode from SPI0 FLASH my XDS100V2 Emulator is giving "ARM9_0: Error connecting to the target: Connect to PRSC failed " ERROR MESSAGE. Before changing the BOOT MODE my emulator was working properly. 

AND WE also checked SPI0 CLK on CPU after POWER UP without EMULATOR CONNECTED &  we observed there was no SPI0 CLK at POWER UP. So SPI0 FLASH Mode is also not working.

Kindly help us with the BOOT MODE ISSUE since we are stuck with many days.

Thanks & Regards

Jitendra Jagasia

Thanks for the additional details. It seems like there is some issue related to the emulator and related pins. Can you provide voltage levels of the EMU0/EMU1 pins and TRST before and after reset? If you can send the schematics for the board that would be helpful to look at as well. Thanks

Jeff

Hi Jeff,

With respect to your previous POST

CPU CARD SCHEMATIC:

The CPU card schematic (along with the DC-DC converter card schematic) has been sent to out Local TI  FAE. He must have emailed you these schematics. Please go through the schematic & send us reply if you find anything regarding why CPU is not booting UP without Emulator.

VOLTAGE LEVELS OF EMULATOR PINS :

BEFORE CONNECTING DEVICE:

PIN1 TMS:  3.1V

PIN2 TRST: 2.8V

PIN3 TDI:  3.1 V

PIN 4 DIS : 0 V

PIN 5 VD : 3.1 V

PIN 6 : 0 V

PIN 7 TD0:  0 V

PIN 8 :  0 V

PIN 9 RTCK: 3.1 V

PIN 10 : 0 V

PIN 11 TCK: 3.1 V

PIN 12: 0 V

PIN 13 EMU0 : 0 V

PIN 14 EMU1: 0 V

AFTER CONNECTING DEVICE:

PIN1 TMS:  TMS Pulses [ 100 to 150 usec time period & pulse width of 2 to 5  usec. Line is normally low with high going pulses)]

PIN2 TRST: 3.1V

PIN3 TDI:  TDI Pulses [ Line is normally high with low going pulses)]

PIN 4 DIS : 0 V

PIN 5 VD : 3.1 V

PIN 6 : 0 V

PIN 7 TD0:  Pulses

PIN 8 :  0 V

PIN 9 RTCK: Block of CLK pulses of 1 MHz freq

PIN 10 : 0 V

PIN 11 TCK: CPU TCK CLK pulses [ High level is at 2.4V & low level at 0.5V ] . CLK freq = 1 MHz

PIN 12: 0 V

PIN 13 EMU0 : 0 V

PIN 14 EMU1: 0 V

EMU0 & EMU1 status before & after reset is same 0 V.

TRST status before & after reset is same 3.1V. When we connect the target device from CCS using emulator, it pulses once.

EMULATOR STATUS:

As per my previous post regarding XDS100V2 Emulator this is our observation

XDS100V2 Emulator is working properly when we changed the BOOT mode setting to the previous Boot mode "SPI0 Slave". Not sure what the issue was.

BOOT2 pin latching issue:

When we changed the resistors on the board to make BOOT2 pin high (for SPI0 flash mode), it was getting latched as "low" only. We could see the processor pin as "high" but internally it was latching as "low" only (as seen on CCS debug gel file output). What could be the issue?

UART 0 , UART 1 , UART 2 & SPI0 FLASH BOOT ISSUE:

As per my previous post

THE CPU board is still not BOOTING UP without EMULATOR connected.

Kindly look into this issue as we are stuck on this for long time and are under heavy pressure from our customer.

Thanks for your support.

Thanks & Regards

Jitendra Jagasia

Thanks for the information. I sent some suggestions via email. Specifically, TRST should be pulled down on the board, not pulled up. Can you try your testing with that modification? In parallel I will look over the data you sent. Thanks

Jeff

1) Pls. note, U15 (FET Switch) OEB pn is driven by CPU-RESET and not CPU_RESETB. This is a correction not shown in schematics

sent previously.

2) To answer your second question, following Boot mode assembly options were assembled and accordingly Boot modes checked on

AM1705 CPU card:
SPI0 Flash
R41, R110, R33, R112, R96 are assembled.
R91, R92, R93, R95, R99, R100, R103, R128, R32, R17, R34, R20, R60, R13, R102, R129, R108, R109, R3, R111, R42, R18, R19,

R31, R35 are not assembled.

UART0
R128, R31, R112, R111, R96 are assembled.
R91, R92, R93, R95, R99, R100, R103, R41, R32, R17, R34, R20, R60, R13, R102, R129, R108, R109, R3, R111, R42, R18, R19, R33,

R35 are not assembled.

UART2
R128, R31, R33, R35, R96 are assembled.
R91, R92, R93, R95, R99, R100, R103, R41, R32, R17, R34, R20, R60, R13, R102, R129, R108, R109, R3, R111, R42, R18, R19,

R110, R112 are not assembled.

I2C0Master
R96, R31, R33, R35, R41
R91, R92, R93, R95, R99, R100, R103, R128, R32, R17, R34, R20, R60, R13, R102, R129, R108, R109, R3, R111, R42, R18, R19,

R110, R112 are not assembled

We are only changing Boot mode options by changing PU/ PD for BOOT0, BOOT1, BOOT2, BOOT3 & BOOT7 pins of CPU. At any given

time depending on the boot mode, we only assemble either PU or PD never both. 1K resistor is being used for PU/ PD.

3) On CPU-DC card, we have changed 3.3V EN1 RC value from 25.5K-ohm-0.1uF to 82K-ohm-0.1uF and for 1.2V EN2, we have removed

charging capacitor, only PD is present.

4) As suggested by you, for JTAG_RESETB pin we changed from PU to PD. However, we found that JTAG_RESETB & CPU_RESETB are

always low and the CPU always remains in reset till we "Initialise Target" using the emulator. Then based on the Boot mode

set, we get correct signals on CRO. But this happens only when emulator is connected.
By changing JTAG_RESETB PU to PD, CPU by itself does not boot or initialise. This means it always requires emulator.
As per schematic, if JTAG_RESETB is PD, then reset will always remain active indefintely.

5) Through CCS only on "Connect target" we see TRSTB pulsing; However when we click on "CPU Reset option" on CCS we do not

see TRSTB pulsing.

6) Observed that once through emulator if we do "connect target" for SPI0 Flash mode then we get SCLK clock pulses (at

frequency as given below). After this on shutting down CCS application and then resetting the CPU card through manual switch

reset, we observe the same frequency SCLK clock pulses.

7) Also, following observations:
In I2C0 Master Boot mode, SCL frequency (for 24MHz crystal assembled on CPU card) observed on our CPU card is 96.15kHz as

against expected 93.8kHz. (reference: SPRABA4B- Nov 2010; pg: 24); with or without JTAG emulator connected.
In SPI0 Flash Boot mode, SCLK frequency (for 24MHz crystal assembled on CPU card) observed on our CPU card is in the range of

803kHz- 833kHz as gainst expected 923kHz. (reference: SPRABA4B- Nov 2010; pg: 24)

We checked 24MHz crystal frequency on CRO and it is 24.07MHz.

Hello Jeff,

Your inputs solicited. This is a lot of info, so kindly guide us.

Just thinking, Could it be ROM version issue? Or a PLL/timing issue?

Hello Roma,

Can you please confirm the Si Version? Please use below procedure

The AM17xx bootloader resides in the ROM of the device. This document describes the boot protocol

used by the bootloader, discusses tools required to generate boot script, and talks about

limitations/assumptions for the bootloader.

The AM17xx bootloader has undergone multiple revisions. To check the version of your device, perform

the following steps.

1. Connect to the device in the Code Composer Studio™ software.

2. Select View → Memory.

3. Enter the address of the beginning of the ROM, 0xFFFD0000, at the top of the memory window.

4. Select Character mode at the bottom.

The text d800k003 should appear in the memory window at offset 0x08. For earlier ROM revisions, the

text could also appear as d800k001. It’s important to know your ROM revision when generating boot

images. If you don’t see either of these values in the memory window, this document is not applicable to

your device.

Thanks & Best Regards 

Feroz

This is your problem:

4) As suggested by you, for JTAG_RESETB pin we changed from PU to PD. However, we found that JTAG_RESETB & CPU_RESETB are

always low and the CPU always remains in reset till we "Initialise Target" using the emulator. Then based on the Boot mode

set, we get correct signals on CRO. But this happens only when emulator is connected.
By changing JTAG_RESETB PU to PD, CPU by itself does not boot or initialise. This means it always requires emulator.
As per schematic, if JTAG_RESETB is PD, then reset will always remain active indefintely.

See section 6.5.1 of the datasheet. Initially the device requires a POR, in which both RESET and TRST are held low. Then RESET is released (with TRST still held low) and the device will boot properly without an emulator. If you are constantly asserting RESET and TRST then it is expected that the CPU will remain in reset.

So please test this and verify you are booting correctly.

Jeff

Hi Jeff,

UART 2 BOOT MODE:

Now we can see "BOOTME" word on the hyperterminal.

I am currently using slh_OMAP-L137.exe which I downloaded from  http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L137 To load  ARM UBL & U-boot into the SPI0Flash.

SPI flash is working properly which I checked using debug code.

The command used to load ARM UBL & U-BOOT is as follows " sfh_OMAP-L137.exe -p COM3 -targetType AM1707 -flash D:\Jitendra\AM1x-1_10_00_01\AM\arm-ubl-spi.bin D:\Jitendra\AM1x-1_10_00_01\Try\u-boot.bin  "

And the output of the sfh_OMAP-L137.exe is attached below.

Can you please guide us why AM1705 is hanging at the point as shown in screenshot below.

Please revert back as soon as possible.

Thanks & Regards

Jitendra

Good news! Glad you got your boot issue resolved. Can you give some details on what you changed?

See this wiki page for modifications to the flashing utility you will have to make for custom boards:

http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L137#Modifications_for_Custom_Boards

Unfortunately the serial flasher is for the EVM and you will have to rebuild it if your board differs. Most likely the SDRAM timings are different which is why it is hanging.

Now that you have an emulator you can flash with the CCS version of the tool, also included in the package. This might be easier to rebuild if you are not experienced with Cygwin.

Jeff

Hi Jeff,

The problem was in our schematic CPU_RESETB was an AND logic function of BRD_RESETB & JTAG_RESETB.

As JTAG_RESETB was PD on board, CPU would not initialise.

So on removal of AND gate, booting of CPU worked fine.

Thanks & Regards,

Roma

Hi Jeff,

I tried using OMAP-L137_FlashAndBootUtils_2_20 CCS project flash loader but it is giving many issues:

FIRST:

when I compiled the CCS project provided in the OMAP-L137_FlashAndBootUtils_2_20 it gave me an error that  "spi_memboot.h" file is missing. I added the spi_memboot.h from the OMAP-L137_FlashAndBootUtils_2_20\Common\ubl\include folder to the OMAP-L137_FlashAndBootUtils_2_20\OMAP-L137\CCS\SPIWriter\include\ folder & then I compiled the CCS project & now it was not giving any file missing error & it compiled properly.

SECOND:

I loaded the spiwrite.out file created from the above CCS project & run the code. 

then the spiwrite application ask for ARM UBL file, then when I load the ARM UBL provided by DaVinci-PSP-SDK-03.20.00.12 then it gave me " ERROR: File too big.. Closing program. " ERROR.

The file provided by DaVinci-PSP-SDK-03.20.00.12 is 20 KB in size then why it is giving error. 

The ARM UBL size is compared with " hSpiMemInfo->hMemParams->memorySize ", But the given variable is not assigned any value anywhere in the CCS project. I have attached the code which I am referring to.

Is there any other TI flash loader or any other TI executable to load code for AM1705. And our SDRAM timing is same as the EVM SDRAM timing.

Please revert back on above given query.

Thanks & regards 

Jitendra

Hi Jeff,

Just for information our flash on board is MX25L25635E.

The commands of the flash is same as per EVM OMAPl137.

Thanks & Regards

Jitendra 

Hi Jeff,

MORE OBSERVATION for above issue:

I changed the Device_init() function according to my custom board.

And I tested my Device_init() function with my debug code project it is working properly & SDRAM is also working.

But when I checked the OMAP-L137_FlashAndBootUtils_2_20 output FROM MEMORY VIEW i observed there is no DATA in SDRAM when though the CODE is writing data in 0xC0000000 address space.

I checked my Device_init() & SDRAM init function both are same according to my debug & are working properly.

Then why?  OMAP-L137_FlashAndBootUtils_2_20 spiwriter code is not working.

Please revert back on above query as soon as possible.

Thanks for your support.

Thanks & regards 

Jitendra

Hi Jeff,

My above query is still not resolved.

Please can just look into it.

Thanks & regards

Jitendra

Hi,

My above query is still not resolved.

Please revert back as soon as possible

Thanks & regards

Jitendra

Hi Jeff,

I am currently facing a new issue regarding linux kernel & u-boot.

The link to my above query are given below

http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/47/t/129497.aspx

http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/47/p/129492/465210.aspx#465210

Can just look into the issue.

Thanks & Regards

Jitendra