Processor SDK RTOS DIAG

From Texas Instruments Wiki
Jump to: navigation, search


RTOS Software Developer Guide Diagnostics



Overview

User Interface

Application

Debug

  • Tips

Overview

The Processor SDK RTOS Diagnostic package is designed to be a set of baremetal tests to run on a given board to provide data path continuity testing on peripherals. For K2H/K2E/K2L/C66x devices, this functionality is provided by POST.

Building the Examples

Pre-requisites to Building

  1. Set your environment using pdksetupenv.bat or pdksetupenv.sh. The diagnostic application uses the same environment variables as the board library build. Refer to the Processor SDK RTOS Building page for information on setting up your build environment.
  2. You will need the following libraries built:
  • Board
  • UART
  • GPIO
  • I2C
  • SPI
  • CSL
  • ICSS
  • PRUSS

(Note: not every library is used for every application, and these libraries should come pre-built with any fresh installation of the Processor SDK)

Compiling the Diagnostic Applications

To build the diagnostic examples:

  1. cd <PDK>/packages/ti/board/diag
  2. make <BOARD>

This will make the diagnostic applications for a specific $BOARD. Alternatively, "make all" will make for all boards. Output files will be located in: <PDK>/packages/ti/board/bin/<BOARD>

Creating the SD Card Loadable Files

For converting the compiled .out files to a format loadable by TI's Secondary Boot Loader (SBL), you must follow these two steps:

  1. out2rprc.exe [.out file] [rprc output]
  2. MulticoreImageGen.exe LE 55 [output name] 0 [rprc output]

Out2rprc.exe and MulticoreImageGen.exe are tools supplied by TI and can be located in the <PDK>/packages/ti/boot/sbl/tools folder. "rprc output" can be any spare name of your choosing. "output name" can also be any name of your choosing. For diagnostic applications, your final output name must have the keyword "TEST" in it. You will have to do this process for every .out application you wish to be loadable on the SD card.

Alternatively, there is also a make target to automate this process:

  1. cd <PDK>/packages/ti/board/diag
  2. make <BOARD>_sd

This will compile all the applications for a specific $BOARD, and also create the SD card loadable files. The output files will be located in: <PDK>/packages/ti/board/bin/<BOARD>/sd. Note that the framework application is named "app" to allow it to be the default application to be loaded by the SBL.

Creating the SPI Flash Loadable Files

SPI boot shall be the primary boot option for the platforms (Ex: AMIC110 ICE) which does not support SD card interface. All the diagnostic tests are integrated into framework binary for the ease of use in the case of SPI boot. Integrated diagnostic framework test binary can be loaded and executed through UART port.

Use below command to build the diagnostic tests and create SPI flash loadable files.

  • make <BOARD>_spi


Make targets

The simplest invocation is to use "make <BOARD>" to compile all the applications. Here is a list of make targets implemented for the diagnostic makefile:

  • make <BOARD> - compile all diagnostic applications for one specific BOARD
  • make clean - clean and remove all applications for all supported BOARDs
  • make <BOARD>_clean - clean and remove all application for one specific BOARD
  • make <BOARD>_sd - compile all diagnostic applications for one specific BOARD and create the SD card loadable files with those compiled applications
  • make <BOARD>_spi - compile all diagnostic applications for one specific BOARD and create the SPI flash loadable files with those compiled applications

The <BOARD> supported depends on your Processor SDK RTOS variant. Refer to following table for available <BOARD> for each Processor SDK RTOS variant:

make target / Variant am335x am437x am57xx k2g omapl13x
<Board> evmAM335x
skAM335x
bbbAM335x
icev2AM335x
iceAMIC110
evmAM437x
skAM437x
idkAM437x
idkAM572x
idkAM571x
evmAM572x
evmK2G
iceK2G
evmOMAPL137

(No Boot support.

Diagnostics need to run from CCS)

Note: OMAPL137 EVM diagnostic tests does not support executing from a boot device. Use the command make evmOMAPL137 to build the diagnostics. Diagnostics test binaries need to be executed from CCS.

Running the Diagnostic Examples

Loading through SD Card (Default Method)

Your SD card must be set up to a bootable format. Refer to the Processor SDK RTOS Boot page for information on how the SD card is handled.

You will need to compile the diagnostic applications for your BOARD, created their respective SD card loadable files, and copied them onto an SD card. You will also need the SBL (renamed to "MLO") on the SD card. To do so:

  1. cd <PDK>/packages/ti/board/diag
  2. make <BOARD>_sd
  3. copy all the content under <PDK>/packages/ti/board/bin/<BOARD>/sd to your SD card
  4. copy the MLO to your SD card (default location at <PDK>/packages/ti/boot/sbl/binary/<BOARD>/mmcsd
  5. insert your SD card into your board and power on your board
  6. open Terminal emulator program eg: Teraterm to connect to the board's UART console
  7. press the "Hard Reset" button on your board. (This is to force re-booting, and not absolutely necessary. Because Terminal emulator program is opened after boot is powered on, you would've missed the initial printout messages. This step is for demonstration and confidence checking that the board has booted correctly)

You should see the following screen:

Diag-screen1.jpg

The framework diagnostic application should be loaded through SBL, and gives you the options:

  • help - prints the command menu and descriptions of the commands
  • run - run a diagnostic application found on the SD card
  • status - current status of the framework run

Below is an example of running a diagnostic application:

Diag-screen2.jpg

Result of return from above run:

Diag-screen3.png

Loading through SPI Flash

This section describes creating the diagnostic test images for SPI flash booting, programming and running them from SPI flash. Currently SPI boot is supported only by iceAMIC110 platform.

You will need to compile the diagnostic applications for your BOARD, create their respective SPI flash loadable files, and program them onto SPI flash. To do so:

  1. cd <PDK>/packages/ti/board/diag
  2. make <BOARD>_spi
  3. Start CCS and launch target configuration file for AMIC110 ICE board
  4. Connect the target, load and run the SPI flash writer binary. Prebuilt SPI flash writer is available at <AM335x PDK>\packages\ti\starterware\tools\flash_writer\spi_flash_writer_AM335X.out
  5. Choose option 1 to initiate image flashing
  6. Enter the file name as SPI bootloader along with full path (Ex: <AM335x PDK>\packages\ti\starterware\binary\bootloader\bin\am335x-evm\gcc\bootloader_boot_mcspi_a8host_release_ti.bin)
  7. Enter offset as 0
  8. Wait until flashing completes successfully
  9. Rerun the SPI flash writer binary and program diagnostic framework loader at offset 20000. Diagnostic framework loader binary will be available at <AM335x PDK>\packages\ti\board\bin\iceAMIC110\spi\app
  10. Rerun the SPI flash writer binary and program diagnostic framework at offset 40000. Diagnostic framework binary will be available at <AM335x PDK>\packages\ti\board\bin\iceAMIC110\spi\framework

Sample CCS output of SPI flash writer is shown below:

Spi flash writer output.jpg


  1. open Terminal emulator program eg: Teraterm to connect to the board's UART console
  2. press the "Hard Reset" button on your board. (This is to force re-booting, and not absolutely necessary. Because Terminal emulator program is opened after boot is powered on, you would've missed the initial printout messages. This step is for demonstration and confidence checking that the board has booted correctly)

You should see the following screen:

Amic110 ice spi boot diag1.jpg


The framework diagnostic application should be loaded through SBL, and gives you the options:

  • help - prints the command menu and descriptions of the commands
  • run - run a diagnostic application found on the SD card
  • status - current status of the framework run

Below is an example of running a diagnostic application:

Amic110 ice spi boot diag2.jpg


Result of return from above run:

Amic110 ice spi boot diag3.jpg


Loading through UART

Follow the below procedure to load and execute the diagnostic tests through UART port. This procedure is applicable to the platforms like AMIC110 ICE which are not having SD card interface.

Compile the diagnostic applications for the BOARD, created their respective SPI flash loadable files.

  1. cd <PDK>/packages/ti/board/diag
  2. make <BOARD>_spi
  3. Connect UART port of the board to host PC
  4. Open serial communication applications like TeraTerm on host PC and configure for ‘115200 8N1’
  5. Power ON the board
  6. ROM bootloader should start waiting for images from UART by printing ‘C’ on the serial console.
  7. Select the TeraTerm menu option ‘File->Transfer->XMODEM->Send...’ and select the framework.bin in the path ‘<PDK>\packages\ti\board\bin\<BOARD>\armv7’

Amic110 ice xmodem1.jpg


Wait till file transfer completes.

Amic110 ice xmodem2.jpg


You should see the following screen after file transfer completes:

Amic110 ice diag1.jpg


The framework diagnostic application should run, and gives you the options:

  • help - prints the command menu and descriptions of the commands
  • run - run a diagnostic application found on the SD card
  • status - current status of the framework run


Below is an example of running a diagnostic application:

Amic110 ice diag2.jpg


Result of return from above run:

Amic110 ice diag3.jpg

Running or debugging on CCS

To debug your application, CCS can give you access to the chip's memory and register values. You can follow the below steps to load and run an application in CCS. If you have a SD card loadable image, and is able to load your application, you can connect to the A15 core in CCS and load symbols without having to load and run the entire application. After running "make all" or "make $BOARD", the output files should be generated under <PDK>/packages/ti/board/bin/ directory. You will have to navigate down to the $BOARD you're building (eg. idkAM572x, evmAM572x, etc.) and the $TARGET core you're building for (eg. armv7).

For the existing diagnostic applications, you may need to define PDK_RAW_BOOT before compiling. This is done by adding the line "#define PDK_RAW_BOOT" to an individual application source file or to <PDK>/packages/ti/board/src/<BOARD>/include/board_cfg.h to apply for all applications. This is used because the default diagnostic loading method is through SD card, and the pinmux is done already. Adding this option only forces the diagnostic applications to do pinmuxing within the application itself (and not depend it being done).

To run on CCS:

  1. Connect USB cable to the board's JTAG
  2. Connect the UART serial cable. For the IDK boards, the UART console is the same as the usb JTAG connector, so no additional cable is necessary.
  3. Plug in power cord to your board
  4. Press the power button on the board to turn the board on
  5. Setup and run CCSv6.1 (or higher). Follow the Processor SDK RTOS Getting Started Guide on how to setup your CCS to connect to the board
  6. Launch target configuration for the board
  7. Connect to the core that you built your application for. For example: for idkAM572x armv7 projects, click on the Cortex A-15 MPU0 core and press the connect button
  8. Load the program by pressing the load button and navigate the explorer to the .out file that you want to load
  9. Press the Run button to run the program
  10. Check UART console to see if anything is printed out. **If nothing is printed out, pause the core and see where the program counter is at. If it is at 0x3808c (or near it), try reloading the program and running again.

Note: On omapl13x platforms diagnostic tests can only be run from CCS as SBL support is not available at this point. Diagnostics are built for both DSP (C674x) and ARM (arm9) cores on omapl13x platform.

Running on a different ARM core

The diagnostic baremetal applications are typically targeted for Core 0 of an ARM corepac. It is possible to load and run it on one of the subcores in CCS. To do so, please consider the following:

  1. Enable Cache - setup typically only enables cache for the main ARM core. You may have to explicitly enable the data and instruction cache. See relevant cache functions under pdk/packages/ti/csl/arch.
  2. [For AM57x boards] Set OPP to high - SBL would set OPP to high for Core 0, but may not do it for the subcores. You can do so by using the GEL file. After connecting to the core, run the function under Scripts -> AM572x PRCM CLOCK configuration -> AM572x_PRCM_Clock_Config_OPPHIGH (similarly named for AM571x).

Diagnostic Applications

Name
Description
GP AM572x IDK AM572x IDK AM571x EVM K2G ICE K2G EVM AM335x SK AM335x BBB AM335x ICEv2 AM335x EVM AM437x SK AM437x IDK AM437x EVM OMAPL137 ICE AMIC110
accelerometer_<BOARD>_armv7.out Test for device detection and read the X, Y and Z axis values to confirm values within range. x x x x
adc_<BOARD>_armv7.out Test for ADC configuration for Channel sequencing and One shot mode operation x x x x
ambient_light_sensor_<BOARD>_armv7.out Test for device detection on board and working of the light sensor x x
buzzer_diagExample_<BOARD>_armv7.out Writes to GPIO in connected to a buzzer. Requires user to verify sound x x
clock_generator_diagExample_<BOARD>_armv7.out Probes the clock generator on I2C bus x
current_monitor_diagExample_<BOARD>_armv7.out Read voltage current on I2C devices x
dcan_diagExample_<BOARD>_armv7.out Does DCAN loopback writes and reads. Passes on successful return. x x x
eeprom_diagExample_<BOARD>_armv7.out Reads the EEPROM and prints out the board's ID information. Passes on successful I2C reads. EEPROM will need to be programmed prior in order for a correct read. x x x x x x x x x x x x x
emac_diagExample_<BOARD>_armv7.out Sends packet on PHY loopback to verify MAC operations x
emmc_diagExample_<BOARD>_armv7.out Writes to and read from eMMC memory. Passes on reading back the correct value as the one written x x x x
framework_<BOARD>_armv7.out The main diagnostic application. This is loaded by SBL and can load other diagnostic applications on the SD card. x x x x x x x x x x x x x
gmac_diagExample_<BOARD>_armv7.out Sends and receive packets over ethernet, both internally and externally. Passes on receiving all packets. x x
haptics_diagExample_<BOARD>_armv7.out Writes to the GPIO pin connected to a motor (haptics). Requires user to verify that the motor is active. x x x
hdmi_diagExample_<BOARD>_armv7.out Tests HDMI display output x
icssEmac_diagExample_<BOARD>_armv7.out Configures one ICSS EMAC port and tests functionality via packet loopback. x x
ioexpGpio_diagExample_<BOARD>_armv7.out Tests GPIO over the IO expander x
ioexpI2c_diagExample_<BOARD>_armv7.out Tests I2C over the IO expander x
ioexpLed_diagExample_<BOARD>_armv7.out Cycles through the LEDs on the IO expander x
lcd_diagExample_<BOARD>_armv7.out Tests LCD display output x
lcdTouchscreen_diagExample_<BOARD>_armv7.out Prompts the user for touches on the LCD touchscreen and report back its location. Requires user to input 9 simultaneous touches to verify pass. x x
led_diagExample_<BOARD>_armv7.out Cycles through GPIO LEDs on the board. Requires user to verify the LEDs blink. x x x x x x x x x x x x x
ledIndustrial_diagExample_<BOARD>_armv7.out Cycles through the I2C LEDs on the board. Requires user to verify LEDs blink. x x x
mcspi_diagExample_<BOARD>_armv7.out Attempts one write and read on the MCSPI header. Requires user to verify the value being read back is as expected. x x x x
mem_diagExample_<BOARD>_armv7.out Writes and reads to external (DDR) memory of the board. Value written/read is the address of the word. This is done two times, for value and ~value (complement), to test for all bits. x x x x x x x x x x x x x
mmcsd_diagExample_<BOARD>_armv7.out Writes to and read from MMCSD memory. Passes on reading back the correct value as the one written x x x x x x x x x x
nand_diagExample_<BOARD>_armv7.out Tests reading and writing to NAND flash memory x
norflash_diagExample_<BOARD>_armv7.out Tests reading and writing to NOR flash memory x
oled_display_diagExample_<BOARD>_armv7.out Light up the OLED display to verify functionality x
pmic_diagExample_<BOARD>_armv7.out Writes and reads to the PMIC controller. This is to verify ability to use I2C to control PMIC. Test passes on successful read and write. x x x x x x x x x
qspi_diagExample_<BOARD>_armv7.out Tests the Quad SPI by writing and reading back the value written to memory. Test passes on correct data read back. x x x x x
rotary_switch_diagExample_<BOARD>_armv7.out Tests the rotary switch at the 10 possible positions x
rtc_<BOARD>_armv7.out Test for setting date and time to RTC registers and running the clock x x x x x x x
temperature_diagExample_<BOARD>_armv7.out Tests reading back from temperature sensor via I2C. Test passes on successful I2C reads. x x x x
uart2usb_diagExample<BOARD>_armv7.out Tests uart messages over usb port. x
uart_diagExample_<BOARD>_armv7.out Data Path continuity test for UART output. Requires user to verify that outputs do appear on console. x x x x x x x x x x x x
mcasp_diagExample_<BOARD>_<CORE>.out On-board audio codec functionality is exercised by this test. Audio supplied at EVM audio input port will loopback to audio output port. This test is intended to demonstrate baremetal functionality of mcasp, edma3 and i2c CSL modules without depending on the LLD libraries. No console output is supported by this test. x x
mcaspAudioDC_diagExample_<BOARD>_<CORE>.out Multi-channel audio daughter card functionality is exercised by this test. Audio supplied at audio DC input ports will loopback to audio DC output ports. This test is intended to demonstrate bare metal functionality of mcasp, edma3 and spi CSL modules without depending on the LLD libraries. No console output is supported by this test. x
pwm_diagExample_<BOARD>_<CORE>.out Demonstrates the usage of PWM CSL FL APIs by configuring the PWM module to generate a pulse of 1KHz with different duty cycle - 25, 50 and 75%. x x x x

Some diagnostic applications expect additional jumpers or hardware settings to complete. Refer to below section.

Additional Jumper or Hardware Settings

Current Monitor

For iceK2G, this test expects J16 and J17 to be connected with jumper shunts. This enables the current monitors to be used.

GMAC

For idkAM572x, idkAM571x, and evmAM572x, this test expects loopback plugs to be used on both Ethernet ports. These loopback plugs will loopback the TX lines back to the RX lines. The Ethernet ports are the RJ-45 connectors labeled "Ethernet" on the board.

ICSS EMAC

For idkAM572x and idkAM571x, this test expects loopback plug to be used on J6. These loopback plugs will loopback the TX lines back to the RX lines. For iceK2G, this test expects loopback plugs to be used on all four ICSS EMAC ports.

LCD Touchscreen

For idkAM572x and idkAM571x, this test expects the LCD module to be connected. This requires the two ribbon cables (one for display, one for the capacitive-touch IC) to be connected.

McSPI

For idkAM572x and idkAM571x, this test expects pins to be connected to the Industrial I/O header. The Industrial I/O header, J37, has two columns in parallel, one of which is the McSPI input and the other being VDD. Thus, connecting any row with a jumper will yield a '1' read on that McSPI input. By connecting the first, second, third, and forth row with jumpers would yield 0x1, 0x2, 0x4, and 0x8 being read respectively.

PWM

PWM output generated while running the diagnostic test can be verified at below pins.

evmK2G - J12 pin 33

evmAM572x - P17 pin 5

idkAM437x - J16 pin 14

evmAM335x - J5 pin 13