3.5.2.5. Lab 4: How to Initialize the PRU¶

3.5.2.5.1.1. Set up the Target Configuration¶

Select View -> Target Configurations to see a list of available configurations. If a target configuration was created as a part of Creating a CCS PRU Project, it will show up here.

If there is no target configuration:

1. Right click in the white space in the Target Configurations window. Select New Target Configuration.
2. Specify a filename (e.g., am335x_bbb_xds100v2.ccxml, am62x_sk.ccxml, am64x_evm.ccxml, etc) and select Finish.
3. Select a connection type:
   • If the EVM requires a separate JTAG debugger, select the JTAG debugger that is being used
     • AM335x example: A BeagleBone Black being debugged with an XDS100v2 emulator would select Texas Instruments XDS100v2 USB Debug Probe
   • If the EVM uses an on-board debugger, select the installed debugger
     • AM62x, AM64x, AM65x example: Select Texas Instruments XDS110 USB Debug Probe
4. Select the Board
5. AM335x BeagleBone Black only: Select the Advanced tab and follow the steps in the PRU Hands-On Labs: LAB 1: Toggle LED with PRU GPO, section “Load the PRU Firmware”.
6. Save the Target Configuration.

3.5.2.5.1.2. Connect to the EVM¶

If the processor has a Processor MCU+ SDK (AM62x, AM64x):

1. Reference the Processor MCU+ SDK documentation, section “Getting Started” > “EVM Setup”.
2. Follow the steps to get the EVM properly set up for a CCS connection.
3. Connect the JTAG debug port to the computer running CCS.

Otherwise:

• AM65x: Reference the Processor SDK RTOS documentation, section “CCS Setup for AM65XX”.
• AM335x on a Beaglebone Black: Reference the PRU Hands-On Labs: LAB 1: Toggle LED with PRU GPO, section “Load the PRU Firmware”.
• Other AM335x, AM437x, AM57x boards: Check to see if the board is documented in the SDK documentation, section “How to Guides” > “Hardware EVM Setup”

3.5.2.5.1.3. Test the Target Configuration¶

1. Power on the board. Note that different boards may have different Power-on / power-off procedures. Reference the EVM User’s Guide for details.
2. Make sure that the JTAG debug port is plugged in.
3. If the Target Configuration is not open, open it by double clicking on the filename in the Target Configurations window.
4. click button Test Connection.

3.5.2.5.1.4. Load the PRU firmware¶

1. In the “Target Configurations” view, right click the Target Configuration file. Select Launch Selected Configuration.

   Note

   Launch Selected Configuration might not appear if you right click the file in a view other than “Target Configurations”.

2. After the Target Configuration loads, right click on the DMSC core. Select Connect Target.

3. The initialization script should run automatically. Among other things, the initialization script sets up the PRU core clock so the CCS debugger can connect to the PRU cores.

4. After the initialization script runs, right click on the DMSC core. Select Disconnect Target.

5. Right click on the appropriate PRU core (e.g., PRU_0) and select Connect Target.

   Note

   AM62x: At the time of writing, the PRU cores are associated with AM62, but not AM62_SK_EVM. If the PRU cores do not show up in the Debug view, edit the Target Configuration to use AM62 instead of AM62_SK_EVM. Save the configuration before re-starting the debug session in CCS.

6. Load the built example by selecting Run -> Load -> Load Program.

7. Select Browse Project. Navigate to the built project. Select the .out file from the Debug folder.

8. The PRU firmware has been loaded into the PRU!

9. Jump to Lab 5: Basic Debugging of PRU Firmware to debug the PRU firmware.

3.5.2.5.2.1. Configure the Kernel¶

The remoteproc and rpmsg modules are enabled by default. These modules are included out-of-the-box in the Linux Processor SDK.

Modules can be enabled or disabled by customing the Linux kernel config. For steps to use menuconfig to adjust the kernel config, reference the Processor SDK Linux documentation, section Foundational Components > Kernel > Users Guide.

The Remoteproc driver can be found in menuconfig under Device Drivers > Remoteproc drivers.

The PRU RPMsg driver can be found in menuconfig under Device Drivers > Rpmsg drivers

3.5.2.5.2.2. Modify Device Tree Files to account for Pinmuxing¶

TI processors route multiple signals to each pin on the processor. Each pin has a multiplexer that selects which of the internal signals is routed to the pin. The pin multiplexer settings are called “pinmux settings”.

The PRU Getting Started Labs do not interface with the processor pins, so pinmux settings are not required.

For an example of adding PRU pinmux settings to the Linux devicetree, reference the software for TI design TIDA-01555. Note that different processors may have different ways of notating address offsets for pinmux values.

General documentation for compiling a device tree binary is in the Linux Processor SDK, section “Foundational Components” -> “Kernel” -> “Users Guide”. For the TIDA-01555 example, build am335x-boneblack-pruadc.dts

3.5.2.5.2.3. Copy files to the target filesystem¶

There are many ways to boot Linux on a TI processor. These steps will boot Linux with an SD card.

1. Create a bootable SD card. Follow the steps in the Linux Processor SDK, section “Overview” -> “Getting Started Guide” -> “Create SD Card”.

2. Once the card is created, mount the SD card on the Linux computer.

3. The rootfs partition on the SD card contains the target filesystem. Copy the files from the Linux computer to the SD card:

   • Copy the PRU firmware binaries xxx.out to the /lib/firmware/pru directory of the rootfs partition.

   • If the Linux devicetree was modified:

     • Copy the xxx.dtb file to the boot directory of the rootfs partition of the SD card. It is suggested to give development DTBs a unique name.

     • Change the “EVM.dtb” symlink in the rootfs/boot directory to point to the new dtb file instead of the default.

       • AM335x example:

         sudo ln -f -s am335x-boneblack-prucape.dtb am335x-boneblack.dtb
         

4. Unmount the SD card from the Linux computer before removing the SD card. This step ensures that the files finish writing to the SD card before the SD card is removed.

3.5.2.5.2.4. Boot the new device tree and FS on the Target¶

1. Move the SD card from the host PC to the target board.

2. Check that the EVM BOOTMODE switches are set for SD card boot. Reference the EVM’s Quick Start Guide or User Guide for more information.

3. Power on the board. Note that different EVMs may have different power-on / power-off procedures. Reference the EVM User Guide for more information.

4. Establish a serial connection between the EVM and the development computer. Reference the EVM Quick Start Guide for more information.

5. Wait for the kernel to boot. At the prompt, login with “root” and no password.

6. Use the remoteproc sysfs interface to specify which PRU firmwares the remoteproc driver should load:

   • Check which remoteproc node is associated with which core with the below command. “pru” can be replaced with “rtu” or “txpru” to find RTU & TX_PRU cores on ICSSG devices.

     grep -Isr pru /sys/kernel/debug/remoteproc/
     

   • Next, use the sysfs interface to set firmware equal to the name of the PRU firmware. RemoteProc starts looking for firmware at /lib/firmware. For example, to tell the RemoteProc driver that the PRU core at remoteproc1 should load /lib/firmware/pru/firmwareName.out, use this command:

     echo 'pru/firmwareName.out' > /sys/class/remoteproc/remoteproc1/firmware
     

7. Use the remoteproc sysfs interface to load and then run the PRU cores. Once ‘start’ has been echoed into the state attribute, the remoteproc firmware will load the PRU cores and then run them.

   echo 'start' > /sys/class/remoteproc/remoteproc1/state