TMDS64EVM: XFR2VBUS Data Transfer Stuck

Hello Seth,

I'm quickly comparing your code against the example code at
https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am243x/SORTE_G/SORTE_g_master_AM243x/xfr2vbus_widget.inc?id=d09576fa217feb446c53a95fed65b2f7db3130aa

the xout command needs to transfer both the data, and the destination address. Your "xout" command is only transferring 32 bytes total over the broadside interface from the PRU core to the XFR2VBUS accelerator (i.e., the 32 bytes of data stored in R2-R9). But you actually need to be sending 40 bytes to also send the address (i.e., to copy data from R2-R11).

Like this:

;issue a write of 32 bytes from address _lo|_hi, one shot
; data in r2-r9
; clobbers r10,r11
XFR2VBUS_WRITE32 .macro  xid,addr_lo,addr_hi
    mov r10,addr_lo
    ldi r11,addr_hi
    xout xid,&r2,40
    .endm

Regards,

Nick

You need to load r10 with global address (see TRM Table 2-1. MAIN Domain Memory Map)

ICSS_G0 DATA RAM: 0x3000 0000

ICSS_G0 Shared RAM:0x3001 0000

- Thomas

For more information about why the global address is needed, please refer to the bus diagrams in this FAQ:
[FAQ] PRU Arbitration Delay 

You will see that the XFR2VBUS instances are connected to the external access path. This is the path that is taken when using global addresses.

However, these accelerators are NOT connected to the internal access path. Thus, they cannot use the PRU local addresses.

Note that XFR2VBUS is still able to access resources within the PRU subsystem. The path the XFR2VBUS read or write would follow is that the read/write needs to exit the PRU subsystem, go onto the system bus, and then come back into the PRU subsystem through the "Inbound VBUSP" in the internal access path diagram. This means that the read/write latency for a local resource in the PRU subsystem will be longer for XFR2VBUS than for the PRU cores doing the read/write directly with a local address. (I would expect that PRU cores using the system address would take a longer amount of time, just like the XFR2VBUS instance) However, since the PRU core is offloading the read/write to the accelerator, it consumes fewer PRU clock cycles, which frees up the PRU cores to execute other instructions while the cores are waiting for the read/write to complete.

For more information about XFR2VBUS, refer to the updated PRU Academy page "XFR2VBUS (Transfer to VBUS)":
https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__AYpwfe.o-fVoSO1rkaT80g__AM64-ACADEMY__WI1KRXP__LATEST 

Regards,

Nick