• State
  • Locked Locked
  • Replies 109 replies
  • Subscribers 102 subscribers
  • Views 23608 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335X Starter Kit Serial COM Port Issues

Nathan Schram
Expert 1085 points
Other Parts Discussed in Thread: AM3358, AM3359, AM3357, AM3354, AM3352

Hi,

I am working with the AM335x starter kit and am having issues getting open communication to run the starter kit test binaries stored on the uSD card.  I was able to get the correct FTDI driver installed so that they show up in the device manager but when I attempt to connect to the device using Putty (115200, same settings described in the AM335x Starter Kit ID Programming guide) I do not get anything back from the device.  It is my understanding that if the device is ready for boot there should be C's printed in the terminal.  I do not see any feed back when the uSD is not connected.  Nor do I get any feedback when the uSD is inserted.  Can you please advise as to what might be giving me issues?  I have measured the clocks on the board and can verify that they are functioning correctly.  What would cause the device not to initiate C's in the terminal once connected?

  • 0
    TI__Guru**** 393215 points

    Hi Nathan,

    Have you tried with another terminal program?

  • 0 in reply to Biser Gatchev-XID
    Expert 1085 points

    Hi Biser,

    Thanks for your reply.  I have tried it with several terminal programs.  I started with Putty and then used TeraTerm and finally again with RealTerm.  I am able to see the 'C' character on TeraTerm when connected to another AM335X Starter Kit.  I am currently looking into the related issues to the ROM not trying to boot.  My approach was to use the provided test binaries to reprogram the ID EEPROM and then run through all the diagnostics.  But at this point the ROM does not try to boot.  I was following TI's AM335X board bring up tips.  I have stable power rails, as well as a stable UART0 signal (not toggling).  I also checked the signal on CLKOUT1 and the signal is stable, which indicates that the clock is propagating correctly through the device.  I unfortunately do not have access to JTAG for any debuggin that way.  I am wondering what other problems would cause the ROM not to try and boot.  Other than verifying the power rails and the clock, is there anything else I can test to verify the device is alive?  I have verified the boot order and the resistor values associated with it and they both check out.  I appreciate any and all help.

    Thanks in advance!

    --Nathan

  • 0 in reply to Nathan Schram
    TI__Guru**** 393215 points

    Is this a Starter Kit EVM or a custom board?

  • 0 in reply to Biser Gatchev-XID
    Expert 1085 points

    This is a custom board based on the Starter Kit EVM.  The only hardware difference between the custom board and the Starter Kit was the removal of the dual ethernet connections.  Everything else is identical including component selection which came from the Starter Kit BOM.  

  • 0 in reply to Nathan Schram
    TI__Guru**** 393215 points

    Hu Nathan,

    CCCC... printout will be output only if you have UART0 included in your boot sequence. What are your SYSBOOT[15:0] settings?

  • 0 in reply to Biser Gatchev-XID
    Expert 1085 points

    Boot Configuration:

    AM335X_LCD_DATA[15.0]

    0100XXXXXXXX110111b

    MMC0, SPI0, UART0, USB0

    UART0 is in the boot configuration.  I have also attached a screenshot of the schematic for the actual pull up/pull downs of the signals.

  • 0 in reply to Nathan Schram
    TI__Guru**** 393215 points

    In this case you will be able to see the CCCC... string only if you don't have a card in MMC0 and no device connected to SPI0. Otherwise if the processor ROM code detects a card it will try to boot from it and possibly hang. If there is no card but a valid SPI0 boot device is detected same will happen. Only after that UART0 is tried and the CCCC... synchronization string is output.

  • 0 in reply to Biser Gatchev-XID
    Expert 1085 points
    There is no card in MMC0, the SPI0 makes connections to the Zigbee header (which has been omitted from my design), and to CD on MMC0 (which is not populated with a card). I have used Putty, RealTerm and TeraTerm to verify that there is no CCCC output to the screen using 115200 baud. At this point I am not able to determine if the processor is "alive". The only feedback I currently have to work with is that the power rails are all stable and accurate to the AM335X board bring up document. Beyond that I can't tell if the processor is actually functioning. Is there any other method to determine if there are bad components?
  • 0 in reply to Nathan Schram
    TI__Guru**** 393215 points

    One thing that you should check is when does the main oscillator start. There is a requirement for a typical start-up time of 1.5ms (see Figure 6-10 and Table 6-3 in the AM335X Datasheet Rev. H). SYSBOOT pins are latched in the processor at reset release time. If the main oscillator has not started properly at that time, or SYSBOOT pullup voltage has not ramped up properly for some reason, the boot combination will not be latched correctly and ROM code will fail to boot the processor.

  • 0 in reply to Biser Gatchev-XID
    Expert 1085 points
    Biser,
    I appreciate your input. I have more information that may be the key to my issue. On my custom board I do not have any data programmed into the ID MEMORY chip (CAT24C256W, U8). There is a disclaimer in the starter kit diagnostics page that says not to erase the entire device (including the first 60 bytes) which has factory settings for device configuration. I have not found anywhere that will say what data needs to be programmed to this EEPROM. My guess is that it needs to have information stored on it to tell the processors bootloader where to grab the data from (in this case the micro SD card). I am not too concerned with getting the device programmed as there are many ways to accomplish this (I2C read/writer, or the manual way of connecting a separate processor for programming), but I am concerned about what data gets programmed. Does anyone have this information available or any advice on this particular issue? An alternate approach for me to verify that this is the problem is to jumper the I2C lines from the DEV board to my custom board and see if the board will boot. That is my next step. I appreciate any and all help! Thanks in advance!
  • 0 in reply to Nathan Schram
    Expert 1085 points
    Biser,
    I have successfully programmed my ID EEPROM with the correct header information based on the information you have provided me. Thank you so much for pointing me to that document. However, I still am unable to boot the processor. I am wondering if there is anything that needs to be programmed to the USB EEPROM (U9) similar to programming the ID EEPROM? I am going to continue working on reading the starter kit's values and programming the result into my custom board just to be sure that i have covered all my bases. Any other ideas that I could pursue that would keep the processor from booting? Is there any way to check and see if the device is alive? I.E. is there a way to verify that the processor is functioning other than verifying the power rails are within spec? Thanks in advance!
    --Nathan
  • 0 in reply to Nathan Schram
    Expert 1085 points
    Additional notes while follwing AM335x board bringup tips:
    PMIC boot is set to EEPROM sequence (BOOT1 = 1, BOOT0=0).
    VDDS_SRAM_CORE_BG = 1.81V
    VDDS_SRAM_MPU_BB = 1.81 V
    CAP_VDD_SRAM_CORE = 1.11V
    CAP_VDD_SRAM_MPU = 1.10V
    CAP_VBB_MPU = 1.10V
    CAP_VDD_RTC = 1.09V
    PORZ Pin checking: the board bring up document states that this pin should remain low throughout the power sequencing and go high when the power AND the high freq clocks are stable. I can only verify that the pin is low on power off and goes high almost immediately upon startup/ power up.
    Probing UART0_TXD: No toggling is occurring on this pin. The voltage is high at ~ 1.8V and does not move.
  • 0 in reply to Nathan Schram
    Expert 1085 points
    Also,
    SYSBOOT[5] = 1, therefore CLKOUT1 is enabled. Probing R186 the clock is visible and is therefore propagating correctly through the device.
  • 0 in reply to Nathan Schram
    TI__Guru**** 393215 points

    This is an indication that SYSBOOT configuration has been latched in the processor, therefore reset is functioning.

  • 0 in reply to Biser Gatchev-XID
    Expert 1085 points
    Biser,
    The only other thing I can think of that might still need to be configured is U32 (93LC56B). Do you know if this EEPROM is preflashed with some information regarding the USB to UART communication? My thought process is that if the processor SYSBOOT configuration has been latched than the reason I am not seeing output on a terminal is due to the USB to UART not being correctly set up. I am currently working on a program to read the EEPROM (using SPI) and write the results to my custom board. Other than this, can you think of anything else that would be preventing my communication from functioning? I appreciate your continued help and support with this!
    --Nathan
  • 0 in reply to Nathan Schram
    TI__Guru**** 393215 points

    Nathan Schram said:
    Probing UART0_TXD: No toggling is occurring on this pin. The voltage is high at ~ 1.8V and does not move.

    Is this a true Starter Kit or a custom board? Starter Kit UART0 should be at 3.3V levels. Do you have an SD card plugged in when you start the board? If so, remove it, restart the board and check if UART0_TXD is toggling.

  • 0 in reply to Biser Gatchev-XID
    Expert 1085 points
    Biser,
    This is a custom board based on the starter kit. The only major difference is that the Ethernet ports have been removed (and the driver IC) and some of the headers for JTAG and Zigbee.
    On the starter kit (on UART0_TXD): 3.31V but no visible toggling of the pin. There is no SD card inserted.
    On the custom board (on UART0_TXD): 3.19V but no visible toggling of the pin. There is no SD card inserted.
  • 0 in reply to Nathan Schram
    TI__Guru**** 393215 points

    What are your SYSBOOT settings?

  • 0 in reply to Biser Gatchev-XID
    Expert 1085 points
    Boot Configuration:

    AM335X_LCD_DATA[15.0]

    0100XXXXXXXX110111b

    MMC0, SPI0, UART0, USB0

    Further back in the thread I posted a picture of the actual pull up/pull down resistors. They are identical to the starter kit.
  • 0 in reply to Nathan Schram
    TI__Guru**** 393215 points
    Have you checked all supply voltages?
  • 0 in reply to Biser Gatchev-XID
    TI__Guru**** 393215 points
    Is this only one board behaving this way or more?
  • 0 in reply to Biser Gatchev-XID
    TI__Guru**** 393215 points
    One more thing - you mentioned that you removed the JTAG interface. Do you have 4.7kOhm pullups on EMU0 and EMU1? They should be pulled up to VDDSHV6 power rail (3.3V in your case).
  • 0 in reply to Biser Gatchev-XID
    Expert 1085 points
    Measured Voltages (Board #1):

    5V Jack 5.19
    TP13 4.92
    TP11 4.92
    TP8 0.01
    VAUX2 3.32
    VMMC 3.30
    VDD_CORE 1.10
    VDD_MPU 1.10
    VAUX1 1.82
    VAUX33 3.32
    VDIG1 1.81
    VDIG2 1.81
    VRTC_PMIC 1.82
    VDAC 1.80
    VPLL 1.82
    VRTC 1.80
    VDDA_ADC 1.82
    VDDSHV1 1.81
    VDDSHV2 3.30
    VDDSHV3 3.30
    VDDSHV4 3.30
    VDDSHV5 3.30
    VDDSHV6 3.31
    VDD_PLL_CORE_LCD 1.81
    VDDS_OSC 1.81
    VDDS_PLL_DDR 1.81
    DDR_VREF 0.76
    VDDS_DDR 1.50
    V3_3D (LCD) 3.30
    LED+ (LCD) 11.49

    There are two custom boards and they are functioning the same.
  • 0 in reply to Biser Gatchev-XID
    Expert 1085 points

    Biser,

    I do not have the JTAG_EMU0 and JTAG_EMU1 pins pulled up to VDDSHV6 (3.3V).  From the reference design it looks like the pull ups were left as do not populate.  I do not have this J12 chip in my design at all.  I can jumper these two pins high.  What would be effected by not pulling them high?

  • 0 in reply to Nathan Schram
    TI__Guru**** 393215 points

    The reference design may be using internal pullups from the FTDI chip. Check EMU0 and EMU1 levels. Both should be at 3.3V otherwise the processot is held in the "Wait in reset" state. Meanwhile I found this guide for programming the FTDI EEPROM: http://processors.wiki.ti.com/index.php/XDS100/Reprogramming_the_VID-PID_EEPROM

  • 0 in reply to Biser Gatchev-XID
    Expert 1085 points
    Biser,
    I will work on getting those pins pulled high as well as getting the EEPROM reprogrammed. I'll post again once I have those steps complete. Thank you for your support!
  • 0 in reply to Nathan Schram
    Expert 1085 points
    Biser,
    EMU0 and EMU1 are both at 3.17V.
  • 0 in reply to Nathan Schram
    TI__Guru**** 393215 points
    I can't see what could be the problem. Try programming the FTDI EEPROM.
  • 0 in reply to Biser Gatchev-XID
    Expert 1085 points
    Biser,
    I was unsuccessful in programming the EEPROM using the provided steps. The program returns "no device found".
    I took it a step further and used an FTDI (UART/USB) cable and connected to the PC. I opened realterm and probed UART0_TXD on the starter kit and am able to see the C character output. When I connect to the custom board and do the same procedure I do not see any characters.
    To me this means that the UART0_TXD is not functioning or was not properly latched in SYSBOOT. However if I am able to see the clock output on R186 (SYSBOOT[5] = 1) that must mean that SYSBOOT was latched but there is an error with the processor? Can you explain the boot process to me in detail.

    Boot assumption: It was my understanding that the boot order began with the PMIC chip. When power up starts the BOOT0 and BOOT1 on the PMIC chip determine the sequence, which BOOT0 = 0 and BOOT1= 1 then the sequence is set to EEPROM. The programmed header information in the EEPROM sends the default boot. The SYSBOOT settings determine boot order (pull-up/pull-down resistors) and the ROM tries to boot from those media. When the boot fails the C character is output to the terminal indicating that the ROM is attempting to boot from the media unsuccessfully.
  • 0 in reply to Nathan Schram
    TI__Guru**** 393215 points

    Nathan Schram said:
    Can you explain the boot process to me in detail. 

    This is described in section 26 of the AM335X TRM Rev. L.

    Nathan Schram said:
    When power up starts the BOOT0 and BOOT1 on the PMIC chip determine the sequence, which BOOT0 = 0 and BOOT1= 1 then the sequence is set to EEPROM. The programmed header information in the EEPROM sends the default boot

    This EEPROM is internal to the PMIC. It provides the correct power sequencing and nothing else.

    Nathan Schram said:
    When the boot fails the C character is output to the terminal indicating that the ROM is attempting to boot from the media unsuccessfully.

    This is not correct. The "C" character is sent wjen UART boot is tried. The reason you see a string of "CCCC..." on your terminal is that the entire boot device sequence is continuously repeated (watchdog reset when last device is tried unsuccessfully), until boot from one of the devices in the list succeeds.

  • 0 in reply to Biser Gatchev-XID
    Expert 1085 points

    Biser,

    I went through the power rails once more to verify they are all stable.  I have included the results below.

    POWER RAIL TARGET (V) MEASURED (V)
    VDDSHV6 3.3 3.32
    VDDSHV2 3.3 3.31
    VDDSHV3 3.3 3.31
    VDDSHV4 3.3 3.31
    VDDSHV5 3.3 3.31
    VDD_CORE 1.1 1.10
    VDD_MPU 1.2 1.10
    VDD_RTC 1.1 1.09
    VDDS_RTC 1.8 1.80
    VDDS_DDR 1.5 1.50
    DDR_VREF 0.9 0.76
    VDDS 1.8 1.80
    VDDSHV1 1.8 1.81
    VDDS_SRAM_CORE_BG 1.8 1.81
    VDDS_SRAM_MPU_BB 1.8 1.81
    VDDS_PLL_DDR 1.8 1.81
    VDDS_PLL_CORE_LCD 1.8 1.81
    VDDS_PLL_MPU 1.8 1.81
    VDDS_OSC 1.8 1.81
    VDDA1P8V_USB0/1 1.8 1.82
    VDDA_ADC 1.8 1.83
    EMU0 3.3 3.17
    EMU1 3.3 3.18

    Additionally, I wanted to check and see if they latching of the SYSBOOT was actually accomplished.  I pulled SYSBOOT[5] = 0, I then probed CLKOUT1 and there was no clock signal.  I returned SYSBOOT[5] = 1 and the CLKOUT1 is present.  This tells me that the latching is functioning properly even though UART0 is not.  I verified this problem on board #2, same result with changing SYSBOOT[5] and still no UART0 signal.

  • 0 in reply to Nathan Schram
    TI__Guru*** 125430 points
    Are you able to run this script and post the generated file:

    processors.wiki.ti.com/.../AM335x_board_bringup_tips
  • 0 in reply to Brad Griffis
    Expert 1085 points
    Brad,
    I will post the results when I complete this. I just ordered the TI XDS100v2 emulator/debugger to use with CCS V6 and wont be able to post the results until the probe arrives. I also have a AM335X starter kit and will post both the results of the SK and the custom board for direct comparison. I will post the results in a few days and we can go from there. Thanks for your help and support.
    --Nathan
  • 0 in reply to Brad Griffis
    Expert 1085 points
    Brad,
    In the document you shared with me on 7/11/15 discussing the procedure for outputting the boot analysis file I saw the section directly above dealing with the DDR configuration. I have not done any work dealing with the DDR AC timing for the specific DDR I am using and have not done the PHY leveling procedure either. With the design being nearly 1:1 to the AM335x Starter Kit is this procedure required? I am just beginning my work with the USB100v2 emulator and will hopefully have my results to post during the day on 7/22/15. Thanks for your continued help.
    --Nathan
  • 0 in reply to Nathan Schram
    Expert 1085 points

    Brad,

    I am having difficulty getting the debugger launched correctly.  I have been following the procedure outlined here:

    processors.wiki.ti.com/.../AM335x_board_bringup_tips

    I am able to setup the target configuration and am able to test the connection.  The output from the test connection are below:

    [Start: Texas Instruments XDS100v2 USB Debug Probe_0]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

    [Result]

    -----[Print the board config pathname(s)]------------------------------------

    C:\Users\nschram\AppData\Local\TEXASI~1\

       CCS\ti\0\0\BrdDat\testBoard.dat

    -----[Print the reset-command software log-file]-----------------------------

    This utility has selected a 100- or 510-class product.

    This utility will load the adapter 'jioserdesusb.dll'.

    The library build date was 'Feb 18 2015'.

    The library build time was '23:56:50'.

    The library package version is '5.1.641.0'.

    The library component version is '35.34.40.0'.

    The controller does not use a programmable FPGA.

    The controller has a version number of '4' (0x00000004).

    The controller has an insertion length of '0' (0x00000000).

    This utility will attempt to reset the controller.

    This utility has successfully reset the controller.

    -----[Print the reset-command hardware log-file]-----------------------------

    The scan-path will be reset by toggling the JTAG TRST signal.

    The controller is the FTDI FT2232 with USB interface.

    The link from controller to target is direct (without cable).

    The software is configured for FTDI FT2232 features.

    The controller cannot monitor the value on the EMU[0] pin.

    The controller cannot monitor the value on the EMU[1] pin.

    The controller cannot control the timing on output pins.

    The controller cannot control the timing on input pins.

    The scan-path link-delay has been set to exactly '0' (0x0000).

    -----[The log-file for the JTAG TCLK output generated from the PLL]----------

    There is no hardware for programming the JTAG TCLK frequency.

    -----[Measure the source and frequency of the final JTAG TCLKR input]--------

    There is no hardware for measuring the JTAG TCLK frequency.

    -----[Perform the standard path-length test on the JTAG IR and DR]-----------

    This path-length test uses blocks of 512 32-bit words.

    The test for the JTAG IR instruction path-length succeeded.

    The JTAG IR instruction path-length is 6 bits.

    The test for the JTAG DR bypass path-length succeeded.

    The JTAG DR bypass path-length is 1 bits.

    -----[Perform the Integrity scan-test on the JTAG IR]------------------------

    This test will use blocks of 512 32-bit words.

    This test will be applied just once.

    Do a test using 0xFFFFFFFF.

    Scan tests: 1, skipped: 0, failed: 0

    Do a test using 0x00000000.

    Scan tests: 2, skipped: 0, failed: 0

    Do a test using 0xFE03E0E2.

    Scan tests: 3, skipped: 0, failed: 0

    Do a test using 0x01FC1F1D.

    Scan tests: 4, skipped: 0, failed: 0

    Do a test using 0x5533CCAA.

    Scan tests: 5, skipped: 0, failed: 0

    Do a test using 0xAACC3355.

    Scan tests: 6, skipped: 0, failed: 0

    All of the values were scanned correctly.

    The JTAG IR Integrity scan-test has succeeded.

    -----[Perform the Integrity scan-test on the JTAG DR]------------------------

    This test will use blocks of 512 32-bit words.

    This test will be applied just once.

    Do a test using 0xFFFFFFFF.

    Scan tests: 1, skipped: 0, failed: 0

    Do a test using 0x00000000.

    Scan tests: 2, skipped: 0, failed: 0

    Do a test using 0xFE03E0E2.

    Scan tests: 3, skipped: 0, failed: 0

    Do a test using 0x01FC1F1D.

    Scan tests: 4, skipped: 0, failed: 0

    Do a test using 0x5533CCAA.

    Scan tests: 5, skipped: 0, failed: 0

    Do a test using 0xAACC3355.

    Scan tests: 6, skipped: 0, failed: 0

    All of the values were scanned correctly.

    The JTAG DR Integrity scan-test has succeeded.

    [End: Texas Instruments XDS100v2 USB Debug Probe_0]

    Next, when I attempt to launch the debugger (right click on the target configuration and select launch selected configuration) I get several errors.  Below is a screenshot of the errors I see in the debug window.

    If I proceed to the last step of the process and try to run the script to output the text document nothing happens. Below is a screenshot of the scripting console window.  No text file is created.  

    I believe the issue is further back in the process.  If the debugger fails to connect to the device no output will be generated.

    Please advise. 

  • 0 in reply to Nathan Schram
    TI__Guru*** 125430 points

    Nathan Schram said:
    Brad,
    In the document you shared with me on 7/11/15 discussing the procedure for outputting the boot analysis file I saw the section directly above dealing with the DDR configuration. I have not done any work dealing with the DDR AC timing for the specific DDR I am using and have not done the PHY leveling procedure either. With the design being nearly 1:1 to the AM335x Starter Kit is this procedure required?

    The first "phase" of booting is for the boot ROM to successfully get your bootloader.  I was under the impression that it's not clear whether that has succeeded yet.  The CCS script that I referenced is intended to help diagnose issues related to the boot ROM loading your initial code.

    With respect to DDR timings, that is an issue that we will come to once you are sure that you're actually getting into your own code (i.e. passed the boot ROM that is built into the AM335x).  Once you get to that point, everything will be under your control.  In terms of the AC timings, if you're using the exact same DDR part as the starter kit then you would not need to recompute the parameters.  However, there is still the question of software leveling.  If your layout is not identical to the starter kit then you would need to perform the software leveling steps and update the DDR initialization code accordingly.

  • 0 in reply to Nathan Schram
    TI__Guru*** 125430 points

    Nathan Schram said:

    Next, when I attempt to launch the debugger (right click on the target configuration and select launch selected configuration) I get several errors.  Below is a screenshot of the errors I see in the debug window.

    There's not much info here.  Do you see any other errors?

    Nathan Schram said:

    I believe the issue is further back in the process.  If the debugger fails to connect to the device no output will be generated.

    Get rid of the quotes and the < > characters.  Those shouldn't be there.

  • 0 in reply to Brad Griffis
    Expert 1085 points
    You are correct in your assumption. It is not clear if the ROM has grabbed the bootloader or not. The DDR is the exact same as the starter kit but the layout is not. I will need to perform the software leveling steps at some point to update the DDR initialization.

    Additionally, from within CCS, if I right click on CortexA8 in the debug window and select connect target the console runs through this list:
    CortxA8: Output: **** AM3358_SK Initialization is in progress ..........
    CortxA8: Output: **** AM335x ALL PLL Config for OPP == OPP100 is in progress .........
    CortxA8: Output: Input Clock Read from SYSBOOT[15:14]: 24MHz
    CortxA8: Output: **** Going to Bypass...
    CortxA8: Output: **** Bypassed, changing values...
    CortxA8: Output: **** Locking ARM PLL
    CortxA8: Output: **** Core Bypassed
    CortxA8: Output: **** Now locking Core...
    CortxA8: Output: **** Core locked
    CortxA8: Output: **** DDR DPLL Bypassed
    CortxA8: Output: **** DDR DPLL Locked
    CortxA8: Output: **** PER DPLL Bypassed
    CortxA8: Output: **** PER DPLL Locked
    CortxA8: Output: **** DISP PLL Config is in progress ..........
    CortxA8: Output: **** DISP PLL Config is DONE ..........
    CortxA8: Output: **** AM335x ALL ADPLL Config for OPP == OPP100 is Done .........
    CortxA8: Output: **** AM335x DDR3 EMIF and PHY configuration is in progress...
    CortxA8: Output: EMIF PRCM is in progress .......
    CortxA8: Output: EMIF PRCM Done
    CortxA8: Output: DDR PHY Configuration in progress
    CortxA8: Output: Waiting for VTP Ready .......
    CortxA8: Output: VTP is Ready!
    CortxA8: Output: DDR PHY CMD0 Register configuration is in progress .......
    CortxA8: Output: DDR PHY CMD1 Register configuration is in progress .......
    CortxA8: Output: DDR PHY CMD2 Register configuration is in progress .......
    CortxA8: Output: DDR PHY DATA0 Register configuration is in progress .......
    CortxA8: Output: DDR PHY DATA1 Register configuration is in progress .......
    CortxA8: Output: Setting IO control registers.......
    CortxA8: Output: EMIF Timing register configuration is in progress .......
    CortxA8: Output: EMIF Timing register configuration is done .......
    CortxA8: Output: PHY is READY!!
    CortxA8: Output: DDR PHY Configuration done
    CortxA8: Output: **** AM3358_SK Initialization is Done ******************


    However, when I try to run the script as shown in an earlier post today, I still do not get the text document created.
    I am currently testing this whole process with the Starter Kit (I assume all steps should complete successfully as this is a working board).
  • 0 in reply to Nathan Schram
    Expert 1085 points
    I re-ran the scripting line, it re-runs through the CortexA8 outputs similar to what I just posted.
    The scripting line I ran was this:

    js:> loadJSFile C:\Users\nschram\Desktop\5463_EzCloud_Files\XDS100v2\am335x-boot.dss

    js:> loadJSFile C:\Users\nschram\Desktop\5463_EzCloud_Files\XDS100v2/am335x-boot.dss

    I ran the line with the backslash and forward slash both directions to make sure it didn't change the output.
    Still no text document created. Here is what the console windows outputs:

    CortxA8: Output: **** AM3358_SK Initialization is in progress ..........
    CortxA8: Output: **** AM335x ALL PLL Config for OPP == OPP100 is in progress .........
    CortxA8: Output: Input Clock Read from SYSBOOT[15:14]: 24MHz
    CortxA8: Output: **** Going to Bypass...
    CortxA8: Output: **** Bypassed, changing values...
    CortxA8: Output: **** Locking ARM PLL
    CortxA8: Output: **** Core Bypassed
    CortxA8: Output: **** Now locking Core...
    CortxA8: Output: **** Core locked
    CortxA8: Output: **** DDR DPLL Bypassed
    CortxA8: Output: **** DDR DPLL Locked
    CortxA8: Output: **** PER DPLL Bypassed
    CortxA8: Output: **** PER DPLL Locked
    CortxA8: Output: **** DISP PLL Config is in progress ..........
    CortxA8: Output: **** DISP PLL Config is DONE ..........
    CortxA8: Output: **** AM335x ALL ADPLL Config for OPP == OPP100 is Done .........
    CortxA8: Output: **** AM335x DDR3 EMIF and PHY configuration is in progress...
    CortxA8: Output: EMIF PRCM is in progress .......
    CortxA8: Output: EMIF PRCM Done
    CortxA8: Output: DDR PHY Configuration in progress
    CortxA8: Output: Waiting for VTP Ready .......
    CortxA8: Output: VTP is Ready!
    CortxA8: Output: DDR PHY CMD0 Register configuration is in progress .......
    CortxA8: Output: DDR PHY CMD1 Register configuration is in progress .......
    CortxA8: Output: DDR PHY CMD2 Register configuration is in progress .......
    CortxA8: Output: DDR PHY DATA0 Register configuration is in progress .......
    CortxA8: Output: DDR PHY DATA1 Register configuration is in progress .......
    CortxA8: Output: Setting IO control registers.......
    CortxA8: Output: EMIF Timing register configuration is in progress .......
    CortxA8: Output: EMIF Timing register configuration is done .......
    CortxA8: Output: PHY is READY!!
    CortxA8: Output: DDR PHY Configuration done
    CortxA8: Output: **** AM3358_SK Initialization is Done ******************
  • 0 in reply to Nathan Schram
    TI__Guru*** 125430 points

    Nathan Schram said:

    Additionally, from within CCS, if I right click on CortexA8 in the debug window and select connect target the console runs through this list:
    CortxA8: Output: **** AM3358_SK Initialization is in progress ..........
    CortxA8: Output: **** AM335x ALL PLL Config for OPP == OPP100 is in progress .........
    CortxA8: Output: Input Clock Read from SYSBOOT[15:14]: 24MHz
    CortxA8: Output: **** Going to Bypass...
    CortxA8: Output: **** Bypassed, changing values...
    CortxA8: Output: **** Locking ARM PLL
    CortxA8: Output: **** Core Bypassed
    CortxA8: Output: **** Now locking Core...
    CortxA8: Output: **** Core locked
    CortxA8: Output: **** DDR DPLL Bypassed
    CortxA8: Output: **** DDR DPLL Locked
    CortxA8: Output: **** PER DPLL Bypassed
    CortxA8: Output: **** PER DPLL Locked
    CortxA8: Output: **** DISP PLL Config is in progress ..........
    CortxA8: Output: **** DISP PLL Config is DONE ..........
    CortxA8: Output: **** AM335x ALL ADPLL Config for OPP == OPP100 is Done .........
    CortxA8: Output: **** AM335x DDR3 EMIF and PHY configuration is in progress...
    CortxA8: Output: EMIF PRCM is in progress .......
    CortxA8: Output: EMIF PRCM Done
    CortxA8: Output: DDR PHY Configuration in progress
    CortxA8: Output: Waiting for VTP Ready .......
    CortxA8: Output: VTP is Ready!
    CortxA8: Output: DDR PHY CMD0 Register configuration is in progress .......
    CortxA8: Output: DDR PHY CMD1 Register configuration is in progress .......
    CortxA8: Output: DDR PHY CMD2 Register configuration is in progress .......
    CortxA8: Output: DDR PHY DATA0 Register configuration is in progress .......
    CortxA8: Output: DDR PHY DATA1 Register configuration is in progress .......
    CortxA8: Output: Setting IO control registers.......
    CortxA8: Output: EMIF Timing register configuration is in progress .......
    CortxA8: Output: EMIF Timing register configuration is done .......
    CortxA8: Output: PHY is READY!!
    CortxA8: Output: DDR PHY Configuration done
    CortxA8: Output: **** AM3358_SK Initialization is Done ******************

    Looks like it connected ok, though all that output indicates you're using a gel file.  You don't want to do that as it will trample on the state of things and make it harder to debug.

    Instead of selecting "SK_AM3358" as your target, please select "AM3358".  It's the basically the same, though minus the gel script.  I think if you make this adjustment and then run the script without the quotes or brackets, then you should hopefully get an output file.

  • 0 in reply to Brad Griffis
    Expert 1085 points
    Brad,
    I changed the target configuration and re-tested the connection. That worked. But after I re-launch the target configuration and right click on CortexA8 in the debug window and select connect target I do not get the console to output anything. If I re-run the script from the script console nothing is run in the console either. And still no output text document.

    The script command looks like this:
    loadJSFile C:\Users\nschram\Desktop\5463_EzCloud_Files\XDS100v2\am335x-boot.dss
  • 0 in reply to Nathan Schram
    TI__Guru*** 125430 points

    Can you try using AM3359 as your target instead?

  • 0 in reply to Brad Griffis
    Expert 1085 points
    Same exact result. No console output, no text file output to desktop. I ran the same script command as before.

    Script command:
    loadJSFile C:\Users\nschram\Desktop\5463_EzCloud_Files\XDS100v2\am335x-boot.dss
  • 0 in reply to Nathan Schram
    Expert 1085 points
    Brad,
    Additionally I have tried the same procedure for AM3352, AM3354, AM3357, AM3358 and AM3359. No console output for any of those target configurations. If I select EVMAM3358 or SK_AM3358 that console information is populated (not sure if this is the GEL file you were referring to or not). Still no text document output to the desktop.

    I updated CCS with all the current extensions and available updates so I am running the most current version of CCS to avoid any versioning issues related to the IDE.
  • 0 in reply to Nathan Schram
    TI__Guru*** 125430 points
    I'm traveling right now so I am not in a position where I can debug the script itself. Perhaps you could just connect to the target and grab the registers that are mentioned in the script. Make sure the MMU says "disabled" in The bottom toolbar before you start grabbing register values.
  • 0 in reply to Brad Griffis
    Expert 1085 points
    Brad,
    I went through the script file you provided and found the registers that it was looking at. I was able to manually find these registers on the starter kit when connected. I included four for the purpose of this post. They are as follows:

    device_id 0x0B94402E
    PRM_RSTST 0x00000001
    control_status 0x00400337
    sysboot0 00110111

    I need to add the JTAG circuitry to the custom board and will be able to go through this whole process again in the AM.
    Stand by for the custom board's results.
    Thanks for your help, even while traveling it is very appreciated!
  • 0 in reply to Nathan Schram
    TI__Guru*** 125430 points

    Just so we're on the same page, when you were running the DSS script. were you checking the *desktop* for the output file?  In other words, despite the fact that you were running am335x-boot.dss from some folder structure on your desktop, the output file is hard code to be put directly on your desktop.  If you have tons of stuff on your desktop I could imagine that it could easily be missed, especially if you weren't looking there.

    Please confirm tomorrow that you have verified that the MMU is disabled before you read these values.  (Please mention it specifically in tomorrow's reply so I'm sure it was disabled.)

    Are you sure the am335x-boot.dss file downloaded correctly?  It looks like you're missing a lot of registers.  The registers from am335x-boot.dss are:

    • 0x44E10600 device_id
    • 0x44E00F08 PRM_RSTST
    • 0x44E10040 control_status
    • 0x4030CE40 current tracing vector 1
    • 0x4030CE44 current tracing vector 2
    • 0x4030CE48 current tracing vector 3
    • 0x4030CE4C Current copy of PRM_RSTST
    • 0x4030CE50 Cold reset tracing vector, word 1
    • 0x4030CE54 Cold reset tracing vector, word 2
    • 0x4030CE58 Cold reset tracing vector, word 3
    • Plus the PC value of the Cortex A8 through the register window

    I would really like to see it work with the script.  As you can see there are quite a few registers.  I wrote that script in the hopes of never having to manually decode them again!  ;-)

  • 0 in reply to Brad Griffis
    Expert 1085 points

    Good morning Brad,

    First off, MMU is OFF (disabled).  I re-downloaded the .dss and placed that file directly on my desktop and tried to re-run it from the scripting console but I still have the same result.  I am aware that the output should be located on the desktop, I have not seen it there (desktop is fairly clean and easy to see if a new item suddenly appeared).

    I am concerned that something is not connecting correctly.  I went through the registers looking for the remaining ones I did not populate manually (I.E. current tracing vectors, cold reset tracing vectors) and cannot find any of them in the register list.  Also, the registers that I could see (device_id, PRM_RSTST, control_status) do not agree with the results you last posted.

  • 0 in reply to Nathan Schram
    Expert 1085 points
    Brad,
    I was successful in getting the .dss script to run. Here are the results:

    CONTROL: device_id = 0x0b94402e

    AM335x family

    Silicon Revision 1.0

    PRM_DEVICE: PRM_RSTST = 0x00000001

    Bit 0 : GLOBAL_COLD_RST

    CONTROL: control_status = 0x00400337

    SYSBOOT[15:14] = 01b (24 MHz)

    SYSBOOT[11:10] = 00b No GPMC CS0 addr/data muxing

    Device Type = General Purpose (GP)

    SYSBOOT[7:6] = 00b MII (EMAC boot modes only)

    SYSBOOT[5] = 1 CLKOUT1 enabled

    Boot Sequence : MMC0 -> SPI0 -> UART0 -> USB0

    ROM: Current tracing vector, word 1 = 0x0000907f

    Bit 0 : [General] Passed the public reset vector

    Bit 1 : [General] Entered main function

    Bit 2 : [General] Running after the cold reset

    Bit 3 : [Boot] Main booting routine entered

    Bit 4 : [Memory Boot] Memory booting started

    Bit 5 : [Peripheral Boot] Peripheral booting started

    Bit 6 : [Boot] Booting loop reached last device

    Bit 12 : [Peripheral Boot] Device initialized

    Bit 15 : [Peripheral Boot] Peripheral booting failed

    ROM: Current tracing vector, word 1 = 0x00001000

    Bit 12 : [Memory Boot] Memory booting trial 0

    ROM: Current tracing vector, word 1 = 0x00111000

    Bit 12 : Memory booting device SPI
    * Bit 16 : Peripheral booting device UART0

    Bit 20 : [Peripheral Boot] Peripheral booting device USB

    ROM: Current copy of PRM_RSTST = 0x00000000

    ROM: Cold reset tracing vector, word 1 = 0x00000000

    ROM: Cold reset tracing vector, word 1 = 0x00000000

    ROM: Cold reset tracing vector, word 1 = 0x00000001

    Bit 0 : [Memory Boot] Memory booting device NULL

    Cortex A8 Program Counter = 0x00020080

    ROM Exception Vectors

    0x4030CE04 Undefined

    0x4030CE08 SWI

    0x4030CE0C Pre-fetch abort

    0x4030CE10 Data abort

    0x4030CE14 Unused

    0x4030CE18 IRQ

    0x4030CE1C FIQ

    ROM Dead Loops

    0x00020080 Undefined exception default handler

    0x00020084 SWI exception default handler

    0x00020088 Pre-fetch abort exception default handler

    0x0002008C Data exception default handler

    0x00020090 Unused exception default handler

    0x00020094 IRQ exception default handler

    0x00020098 FIQ exception default handler

    0x0002009C Validation test PASS

    0x000200A0 Validation test FAIL

    0x000200A4 Reserved

    0x000200A8 Image not executed or returned

    0x000200AC Reserved

    0x000200B0 Reserved

    0x000200B4 Reserved

    0x000200B8 Reserved

    0x000200BC Reserved