6.2. Board Diagnostic Overview

6.2.1. Overview

The PDK 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.

Primary goal of the diagnostic tests is to validate the interfaces on the HW boards to confirm there are no connectivity and assembly issues. Implementation of diagnostic tests will not cover the complete protocol or specification used by the interface under test. Board diagnostic tests serve as reference for board bring-up but they are not recommended to be used as reference for production software development.

6.2.2. Building the Diagnostic Tests

6.2.2.1. Pre-requisites for Diagnostics Build

  1. Follow the steps provided in PDK userguide to setup the build environment.

  2. You will need the following libraries built:

  • Board

  • UART

  • GPIO

  • I2C

  • SPI

  • CSL

  • ICSS

  • PRUSS

  • MMCSD

  • ENET

  • USB

  • CPSW

  • OSAL

  • FatFS

  • UDMA

  • SCICLIENT

  • PMIC

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

6.2.2.2. Build Commands

  • Build the diagnostic tests using the below command

make BOARD=<Board Name> CORE=<Core Name> <Diag Build Name>
<Board Name> is the board for which diagnostics need to be built (Ex: |__PART_DEFAULT_BOARD__| )
<Core Name> is the CORE ID (Ex: mcu1_0)
<Diag Build Name> is the diagnostic build target name as defined in <PDK>/packages/ti/board/diag/board_diag_component.mk

  • Successful build creates the diagnostic application at <PDK>/packages/ti/binary/board_diag_<Test Name>/bin/<Board Name>

6.2.3. Running the Diagnostic Examples

6.2.3.1. Loading through SD Card

Diagnostic tests can be run through SD card either using standalone test binary or through menu based diagnostic framework application. Below sections describe the procedure for each method.


SD card must be set up to a bootable format for running the diagnostic tests from SD card. Refer to the PDK Boot page for information on how the SD card is handled.

6.2.3.2. Running Standalone Diagnostic Tests through SD Card

  • Build diagnostic test application by following the steps described in section Building the Diagnostic Tests

  • Copy the diagnostic application image (.appimage) to SD card and rename it to ‘app’

  • Copy the system firmware and bootloader images to SD card

  • Insert the SD card into the board

  • Connect the serial port of the board to host PC

  • Open Terminal emulator program eg: Teraterm to connect to the board’s UART console

Note

Use MAIN UART0 console for running the tests on mpu1_0, mcu2_0 cores and MCU UART console for running the tests on mcu1_0 core.




  • Power ON the the board.

  • Diagnostic test should start running and display the log on the console.

6.2. Running Diagnostic Framework Application through SD Card

  • Build all the diagnostic test applications by following the steps described in section Building the Diagnostic Tests

  • Copy the ‘.appimage’ files from ‘<PDK>/packages/ti/binary/board_diag<Test Name>/bin/<Board Name>’ folder to SD card

  • Rename the file board_diag_framework_xxx.appimage to ‘app’

  • Rename board_diag_<Test Name>_xxx.appimage files to <Test Name>_TEST

  • Copy the system firmware and bootloader images to SD card

  • Connect the serial port of the board to host PC

  • Open Terminal emulator program eg: Teraterm to connect to the board’s UART console

Note

Use MAIN UART0 console for running the tests on mpu1_0, mcu2_0 cores and MCU UART console for running the tests on mcu1_0 core.

  • Power ON the the board.

You should see the following screen when board is bootted with diagnostic binaries in SD card:

../_images/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:

../_images/diag_screen2.jpg

Result of return from above run:

../_images/diag_screen3.png

6.2.3.3. Loading through UART

  • Build diagnostic test application by following the steps described in section Building the Diagnostic Tests

  • Configure the board for UART boot

  • Connect the serial port of the board to host PC

  • Open Terminal emulator program eg: Teraterm to connect to the board’s UART console

Note

Use MAIN UART0 console for running the tests on mpu1_0, mcu2_0 cores and MCU UART console for running the tests on mcu1_0 core.




  • Power ON the the board, the console should show a sequence of CCC being printed

  • Choose the X-Modem interface and send the SBL that was built for UART. After the transfer is completed, repeat the same step for sysfw.bin (or, for HS device, use the ‘sysfw-hs-enc.bin’) and the diagnostic application image (.appimage). You will see notifications to perform these actions.

  • Check the console logs after diagnostic test is loaded through UART.

6.2.3.4. 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 corresponding core in CCS and load symbols without having to load and run the entire application. After building the diagnostic application, the output files should be generated under ‘<PDK>/packages/ti/binary/board_diag<Test Name>/bin/<Board Name>’.

For running the diagnostic tests from CCS, pinmux configurations in diagnostic tests need to be enabled by defining the macro ‘PDK_RAW_BOOT’. This is done by default for debug build profile. For enabling the pinmux for release build profile, define the macro ‘PDK_RAW_BOOT’ in <PDK>/packages/ti/board/diag/board_diag_component.mk by adding the line ‘export BOARD_DIAG_CFLAGS = -DPDK_RAW_BOOT’. This is required because the default diagnostic loading method is through SD card, and the pinmux is done by sbl. 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:

  • Connect USB cable to the board’s JTAG

  • Connect the UART serial cable.

  • Plug in power cord to your board

  • Press the power button on the board to turn the board on

  • Setup and run CCSv10 (or higher).

  • Launch target configuration for the board

  • Connect to the core that you built your application for.

  • Load the program by pressing the load button and navigate the explorer to the .out file that you want to load

  • Press the Run button to run the program

  • 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.

6.2.4. Diagnostic Applications Support

Name

Description

AM65xx EVM

AM65xx IDK

J721E EVM

J7200 EVM

AM64x EVM

adc_TEST

Reads the input voltage provided on ADC header. Verifies Multiple ADC channels. Need to provide voltage input on ADC header from external source while the test.

x

x

x

adcStress_TEST

Reads the input voltage provided on ADC header. Test is repeated for 100 cycles. Press ‘b’ to stop the test before completing test cycles. Need to provide voltage input on ADC header from external source while the test.

x

x

x

bootEeprom_TEST

Verifies boot EEPROM by writing a block of data, reading back written data for correctness.

x

x

x

x

bootEepromStress_TEST

Verifies boot EEPROM read/write covering entire memory.

x

x

x

x

bootSwitch_TEST

Verifies boot mode switch by configuring boot strap pins as GPIOs and reading the pin state with boot switch set in different patterns

x

x

x

x

x

button_TEST

Verifies push buttons on the board. Test prompts for pressing a specific button which will be detected by the test.

x

x

x

clockGen_TEST

Verifies clock generator modules on the board.

x

x

csirx_TEST

Verifies csirx port on the board by receiving test pattern from csi fpd hub and displaying it on HDMI monitor.

x

currentMonitor_TEST

Read voltage, current on I2C devices

x

x

x

x

x

currentMonitorStress_TEST

Read voltage, current on I2C devices. Test is repeated for 100 cycles. Press ‘b’ to stop the test before completing test cycles.

x

x

x

x

x

displayPort_TEST

Verifies eDP display port on the board by displaying a color bar on DP monitor.

x

dsitx_TEST

Verifies dsitx display port on the board by displaying a color bar on the LCD. Need to connect a LCD which is compatible with FPD device used on the board for running the test.

x

eeprom_TEST

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

emmc_TEST

Writes to and read from eMMC memory. Passes on reading back the correct value as the one written

x

x

x

x

x

emmcStress_TEST

Writes to and read from eMMC memory. Test covers the entire eMMC memory

x

x

x

x

x

enetIcssg_TEST

Verifies ICSSG ENET ports in loopback with one port connected to another port. 100 packets are sent and received during the test.

x

x

extRtc_TEST

Test for setting date and time to external RTC and running the clock

x

x

x

x

extRtcStress_TEST

Test for setting date and time to external RTC and running the clock. Test is repeated for 100 cycles. Press ‘b’ to stop the test before completing test cycles.

x

x

x

x

framework(app)

The main diagnostic application. This is loaded by SBL and can load other diagnostic applications on the SD card.

x

x

x

x

hdmi_TEST

Verifies HDMI display port on the board by displaying a color bar on HDMI monitor.

x

hyperbus_TEST

Tests the Hyperbus by writing and reading back the value written to memory. Test passes on correct data read back.

x

x

icssgLed_TEST

Cycles through LEDs on the IDK application board.

x

icssgLedStress_TEST

Cycles through LEDs on the IDK application board. Test is repeated for 100 cycles. Press ‘b’ to stop the test before completing test cycles.

x

lcd_TEST

Tests LCD display output and touch input

x

led_TEST

Cycles through GPIO LEDs on the board. Requires user to verify the LEDs blink.

x

x

x

x

x

ledStress_TEST

Cycles through GPIO LEDs on the board. Requires user to verify the LEDs blink. Test is repeated for 100 cycles. Press ‘b’ to stop the test before completing test cycles.

x

x

x

x

x

ledIndustrial_TEST

Cycles through the I2C LEDs on the board. Requires user to verify LEDs blink.

x

x

x

ledIndustrialStress_TEST

Cycles through the I2C LEDs on the board. Requires user to verify LEDs blink. Test is repeated for 100 cycles. Press ‘b’ to stop the test before completing test cycles.

x

x

x

lin_TEST

Verifies LIN ports on the board with two ports connected with each other. Data is sent from one port and received on another port. Both ports are veirified for Tx and Rx

x

x

mcan_TEST

Verifies MCAN ports on the board with two ports connected with each other. Data is sent from one port and received on another port. Both ports are veirified for Tx and Rx

x

x

x

x

mcanStress_TEST

Verifies MCAN ports on the board with two ports connected with each other. 10240 packets are sent from one port and received on another port. Both ports are veirified for Tx and Rx

x

x

x

x

mem_TEST

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

memStress_TEST

Writes and reads to external (DDR) memory of the board. Walking 1’s and walking 0’s tests are executed on the whole DDR memory

x

x

x

x

x

mmcsd_TEST

Writes to and read from MMCSD memory. Passes on reading back the correct value as the one written

x

x

x

x

x

mmcsdStress_TEST

Writes to and read from MMCSD memory. Passes on reading back the correct value as the one written. Entire SD card memory starting from 1.5GB offset is written/read during the test.

x

x

x

x

x

norflash_TEST

Tests reading and writing to NOR flash memory

x

x

x

x

norflashStress_TEST

Tests reading and writing to NOR flash memory. Entire NOR flash memory is accessed during the test.

x

x

x

x

oled_TEST

Tests the OLED display by displaying test messages on the oled panel.

x

ospi_TEST

Tests the Octal SPI by writing and reading back the value written to memory. Test passes on correct data read back.

x

x

x

x

x

ospiStress_TEST

Tests the Octal SPI by writing and reading back the value written to memory. Test passes on correct data read back. Entire OSPI flash memory is accessed during the test.

x

x

x

x

x

pcie_TEST

Tests the PCIe interface in end point and rootcomplex mode using two boards. Data is sent from one board to other and sent it back to the first board for verification.

x

x

pmic_TEST

Verifies PMIC access and setting the PMIC voltages

x

x

rotarySwitch_TEST

Tests the rotary switch at the 10 possible positions

x

rs485_TEST

Verifies PRU UART port on the board. Supports board to board test and single board test. RS485 to RS232 coverter is needed to run the test on AM65xx platform

x

x

rs485Stress_TEST

Verifies PRU UART port on the board. Sends 10MB of data from the board to serial console. Teraterm script loops the data back to the board. Data recieved on the board and verified. RS485 to RS232 coverter is needed to run the test on AM65xx platform.

Need to run this test from CCS. SD boot support is not available.

x

x

spiEeprom_TEST

Verifies SPI EEPROM by writing a block of data, reading back written data for correctness.

x

temperature_TEST

Tests reading back from temperature sensor via I2C. Test passes on successful I2C reads.

x

x

x

x

x

temperatureStress_TEST

Tests reading back from temperature sensor via I2C. Test passes on successful I2C reads. Test is repeated for 100 cycles. Press ‘b’ to stop the test before completing test cycles.

x

x

x

x

x

uart_TEST

Data Path continuity test for UART output. Requires user to verify that outputs do appear on console.

x

x

x

x

x

uartStress_TEST

Verifies UART port with large block of data transfer. Sends 10MB of data from the board to serial console. Teraterm script loops the data back to the board. Data recieved on the board and verified. RS485 to RS232 coverter is needed to run the test on AM65xx platform.

Need to run this test from CCS. SD boot support is not available.

x

x

x

x

x

usbDevice_TEST

Verifies the USB device mode operation of board under test. USB modules operates at high speed (2.0) Board is exposed as USB MSC device to host PC during the test.

x

x

usbHost_TEST

Verifies the USB host mode operation of boardf under test. USB modules operates at high speed (2.0) during the test. File write/read and data verification on the connected USB device is done during the test

x

x

usbHostStress_TEST

Verifies the USB host mode operation of boardf under test. USB modules operates at high speed (2.0) during the test. File write/read and data verification on the connected USB device is done during the test Test is repeated for 100 cycles. Press ‘b’ to stop the test before completing test cycles.

x

x

Power On Self Test

Verifies basic memory devices on the board and displays the board ID details. Executed on boot automatically before displaying diag main menu. Can be skipped by entering ‘b’ in the serial console within 5 secs of diag boot.

x

x