PRU0 base address

150 views
Skip to first unread message

Karl Karpfen

unread,
Nov 4, 2014, 11:54:03 AM11/4/14
to beagl...@googlegroups.com
OK, I'm sure it is a stupid question but I don't find it in AM335x TRM...there the offset of PRU_CTRL-register is defined with 0x00000000. But what is the base address? I found a definition 0x4a322000 in one of Starterware headers but this seems to be wrong.

So what is correct base address for PRU0 registers and RAM areas?

josmfe...@gmail.com

unread,
Nov 6, 2014, 12:13:30 AM11/6/14
to beagl...@googlegroups.com
Hey man, 

You should read this PDF file. It helps a lot.


From there most of your doubts will surely be solved. If not, keep posting.

Best of luck,

Jose

Karl Karpfen

unread,
Nov 6, 2014, 2:19:34 AM11/6/14
to beagl...@googlegroups.com
OK, the base address seems to be correct. Nevertheless CTRL-register isn ot readable, so it seems some important PRU-initialisations are missing. So is there any clock or power that has to be turned on for PRU?

ericgg...@gmail.com

unread,
Nov 6, 2014, 10:28:56 AM11/6/14
to beagl...@googlegroups.com
The PRU does need to be enabled, typically by a Device Tree entry similar to this:

fragment@4 {
        target = <&pruss>;
        __overlay__ {
            status = "okay";
        };
};

If using a cape of some kind, this would normally be in the device tree setup for that cape.
If it's your own custom cape, you would need to add this to your device tree file.
There may also be a suitable device tree overlay already installed in /lib/firmware that you can simply enable, but I don't have my BBB in front of me right now to check.

Karl Karpfen

unread,
Nov 10, 2014, 3:38:32 AM11/10/14
to beagl...@googlegroups.com, ericgg...@gmail.com
OK, seems I have to clarify this a bit: in my environment no Linux is involved, I'm digging within the hardware directly.

What I found meanwhile: some clocks have to be enabled. But setting CM_PER_PRU_ICSS_CLKCTRL to 0x00000002 and CM_PER_PRU_ICSS_CLKSTCTRL to 0x00000010 (=CM_PER_PRU_ICSS_CLKSTCTRL_OCP_GCLK) did not do the trick.

Any other ideas?

Karl Karpfen

unread,
Nov 12, 2014, 2:19:25 AM11/12/14
to beagl...@googlegroups.com
OK, solved, using this initialisation PRU is at least initialised:

   HWREG(SOC_PRM_PER_REGS)|=0x00000002;
   HWREG(SOC_PRM_PER_REGS)|=0xFFFFFFFD;

   HWREG(SOC_CM_PER_REGS+CM_PER_PRU_ICSS_CLKCTRL)=0x00000002;
   HWREG(SOC_CM_PER_REGS+CM_PER_PRU_ICSS_CLKSTCTRL)=(CM_PER_PRU_ICSS_CLKSTCTRL_OCP_GCLK|CM_PER_PRU_ICSS_CLKSTCTRL_IEP_GCLK);

   memcpy((void*)PRU0IRAM_PHYS_BASE,textbuf,textlen);
   memcpy((void*)DATARAM0_PHYS_BASE,databuf,datalen);
   HWREG(PRU0CONTROL_PHYS_BASE+PRU_CTRL)=0x00000002; // enable and execute -> PRUSS_CFG_BASE instead of PRU0CONTROL_PHYS_BASE?

Afterwards CTRL-register contains 0x8003 which means PRU is executing something.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/CRyvSLTPg6E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages