Why is my PRU UART code halting?

I should also mention that I am not able to debug the PRU code at the moment. I'm curious about the presence of the file /sys/kernel/debug/remoteproc/remoteproc1/single_step and I wonder if remoteproc could enable any debugging possibilities (I'm totally new to remoteproc).

I hope to get an XDS100 JTAG adapter soon, and then use it to step through the PRU code directly. But I haven't got that yet.

The other detail I should have mentioned before is: When the code variant with the 'tx' variable is used, the code runs fine until the UART receives a byte, at which point it crashes (it doesn't echo the byte, and the PC ends up at 0x148. With the code variant that doesn't use the 'tx' variable, the code is able to echo the RX byte to TX and continue running fine.

Hi Craig,

Is this a soft UART? you can check this wiki - there is an example with up to 6 soft UARTs on the PRU: http://processors.wiki.ti.com/index.php/Soft-UART_Implementation_on_AM335X_PRU_-_Software_Users_Guide

No, my question has nothing to do with soft UARTs. It has more to do with execution flow, perhaps code loading.

Hi Craig,

Yes, there are some debug features enabled by the remoteproc driver. These features are located in /sys/kernel/debug/remoteproc/remoteproc<0/1> directory. 

The 'single_step' utilizes the single-step execution of the PRU cores.  Writing a non-zero value performs a single step, and a zero value restores the PRU to execute in the same mode as before the first single step.  (Note: if the PRU is halted because of a halt instruction, then no change occurs.)

For example, you can perform a single-step by echoing 1 into single_step, and then you can read the PRU registers. So, typically, I would use it as:

echo 1 > /sys/kernel/debug/remoteproc/remoteproc1/single_step; cat /sys/kernel/debug/remoteproc/remoteproc1/regs

and continue doing this to execute PRU one instruction after other.

Echo 0 will return the PRU to the prior state before the first echo 1 (it will run continuously if it was running before; noop if it was halted before).

If you want to start stepping from the beginning of the program, you can write 0x0 to the PRU_CTRL register (i.e. address 0x4A322000 for PRU0) before echoing 1 into single_step.

Regards,

Melissa 

Hi Craig,

Can you try replacing your resource table file with resource_table_empty.h?   The resource table is the main difference I can think of between the CCS loader and pruss_remoteproc.   

As for JTAG debugging, I am investigating if this is possible while running Linux remoteproc.  

Regards,

Melissa 

I've investigated, and results are pointing to my hypothesis (1): the remoteproc driver isn't loading the code into the PRU properly.

I've used the devmem2 tool under Linux to halt the PRU0 and read its IMEM. According to the map file, the first 0x118 bytes of IMEM are used by my program.

I compared the IMEM read under Linux to the IMEM read when doing straight JTAG debugging. It looks as though the IMEM under Linux has not correctly loaded the last 6 words, from address 0x100 onwards.

Please see the attached file, sub-directory memory-check. In particular, this diff:

craigm@craig-linux-pc:~/git/ir-pru-uart-test-2/memory-check$ diff -u pru0-imem-jtag.dat pru0-imem-remoteproc-edited.txt 
--- pru0-imem-jtag.dat	2015-02-19 16:54:51.650676089 +1100
+++ pru0-imem-remoteproc-edited.txt	2015-02-19 16:55:21.370676665 +1100
@@ -62,9 +62,9 @@
 91002780
 E1040200
 100000E0
-81002780
-21001500
-230044C3
-21004300
-10000000
-20C30000
+00000001
+00000000
+00000000
+00000000
+00000000
+00000000

Compare to the file pru0-imem-disassembly-jtag.txt which shows the disassembly. The corrupted memory corresponds to the C line

tx = CT_UART.RBR;

Here is the updated file which I forgot to attach before:

0412.ir-pru-uart-test-2.tar.gz

The code was added as follows:

commit 5e834aa9ce55e3ae1473a39868fca5420b7bedea
Author: Suman Anna <s-anna@ti.com>
Date:   Mon May 19 17:21:12 2014 -0500

    remoteproc/core: add a rproc ops for performing address translation
    
    The rproc_da_to_va API is currently used to perform any device to
    kernel address translations to meet the different needs of the remoteproc
    core/drivers (eg: loading). The functionality is achieved within the
    remoteproc core, and is limited only for carveouts allocated within the
    core or to internal memories published through the resource table.
    
    A new rproc ops, da_to_va, is added to provide flexibility to platform
    implementations to perform the address translation themselves when the
    above conditions cannot be met by the implementations. The rproc_da_to_va()
    is expanded to take in an additional flags field and invoke this ops if
    present, and fallback to regular processing if the platform implementation
    cannot provide the translation.
    
    Signed-off-by: Suman Anna <s-anna@ti.com>

It appears that this has a bug as previously described.

The carveouts are what the traditional DSP or IPU processors use for loading and executing code in DDR, essentially memory is allocated from kernel and mapped into the respective processors's MMUs at the specific addresses that those processors load the code/data. 

There is no particular branch hosted on a newer kernel where the driver is available, the next branch that I will host will be on the 2015 LTS kernel. Depending on the kernel of your choice, you should be able to cherry-pick the remoteproc patches from my 3.14 remoteproc feature tree.

http://git.ti.com/gitweb/?p=rpmsg/remoteproc.git;a=shortlog;h=refs/heads/rproc-linux-3.14.y

The PRU related commits should start from ed052fb60b9a03fea110cb253ffeed5c6f198a34 onwards, there shouldn't be many. Depending on the kernel you want, you may also have to pick some additional mailbox framework patches (the framework that 3.14 uses is available from 3.18 onwards).