PRU configure and basic test not working

Hello,

I’m currently trying to configure and use the PRU of the BBB.

So I’ve tried two different method to do so however, with none of them I get succeed and I don’t really
understand why.

  1. First method (from Derek Molloy book) :

http://exploringbeaglebone.com/chapter13/
So I have tried to do the PRU-based Clock Signal Generators, because this one
do not required any additional material except an oscilloscope.

So I had load the EBB-PRU-Example DTS overlay (provided in attachment), and I have receive the following message :

`

echo EBB-PRU-Example > $SLOTS

[ 51.417438] bone_capemgr bone_capemgr: part_number ‘EBB-PRU-Example’, version ‘N/A’
[ 51.425297] bone_capemgr bone_capemgr: slot #4: override
[ 51.430665] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[ 51.437772] bone_capemgr bone_capemgr: slot #4: ‘Override Board Name,00A0,Override Manuf,EBB-PRU-Example’
[ 52.526058] gpio-of-helper ocp:gpio_helper: ready
[ 52.531052] bone_capemgr bone_capemgr: slot #4: dtbo ‘EBB-PRU-Example-00A0.dtbo’ loaded; overlay id #0

`

`

cat $SLOTS

0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 0 Override Board Name,00A0,Override Manuf,EBB-PRU-Example
`

I have also check :

`

lsmod |grep uio

uio_pruss 4590 0
uio_pdrv_genirq 3317 0
uio 8319 2 uio_pruss,uio_pdrv_genirq
`

`

root@beagle01:~/labs/exploringBB/chp13/fixedPRUClock# ./build
PRU Assembler Version 0.86
Copyright © 2005-2013 by Texas Instruments Inc.
Pass 2 : 0 Error(s), 0 Warning(s)
Writing Code Image of 12 word(s)
`

`

sudo ./fixedclock

However, when I tried to monitor what append on pin P9_27 but I didn’t observed anything on this pins.`

  1. Second method (from the Beagle bone black cookbook written by Charles A Hamilton) :

This time, I have use this DTS : BB-BONE-PRU-01 (https://github.com/jadonk/cape-firmware/blob/master/arch/arm/boot/dts/BB-BONE-PRU-01-00A0.dts)
In addition, I have tried to used this code :
https://github.com/HudsonWerks/bbb-pru

So first I tried to add the DTS, I received this message :

`

echo EBB-PRU-Exampecho BB-BONE-PRU-01 > $SLOTS

[59800.649273] bone_capemgr bone_capemgr: part_number ‘BB-BONE-PRU-01’, version ‘N/A’
[59800.656947] bone_capemgr bone_capemgr: slot #12: override
[59800.662528] bone_capemgr bone_capemgr: Using override eeprom data at slot 12
[59800.669680] bone_capemgr bone_capemgr: slot #12: ‘Override Board Name,00A0,Override Manuf,BB-BONE-PRU-01’
[59800.699368] ------------[ cut here ]------------
[59800.704089] WARNING: CPU: 0 PID: 619 at arch/arm/mach-omap2/omap_hwmod.c:2087 _enable+0x201/0x210()
[59800.713188] omap_hwmod: pruss: enabled state can only be entered from initialized, idle, or disabled state
[59800.722894] Modules linked in: uio_pruss usb_f_ecm g_ether usb_f_rndis u_ether libcomposite pvrsrvkm(O) omap_sham omap_aes snd_soc_davinci_mcasp snd_soc_edma snd_soc_omap omap_rng rng_core snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd soundcore evdev spi_omap2_mcspi uio_pdrv_genirq uio leds_gpio
[59800.751252] CPU: 0 PID: 619 Comm: bash Tainted: G W O 4.1.19-bone20 #1
[59800.758778] Hardware name: Generic AM33XX (Flattened Device Tree)
[59800.764974] [] (unwind_backtrace) from [] (show_stack+0x11/0x14)
[59800.772791] [] (show_stack) from [] (warn_slowpath_common+0x6b/0x8c)
[59800.780948] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x23/0x2c)
[59800.789714] [] (warn_slowpath_fmt) from [] (_enable+0x201/0x210)
[59800.797524] [] (_enable) from [] (omap_hwmod_enable+0x15/0x20)
[59800.805158] [] (omap_hwmod_enable) from [] (omap_device_enable+0x29/0x50)
[59800.813751] [] (omap_device_enable) from [] (_od_runtime_resume+0x11/0x1c)
[59800.822450] [] (_od_runtime_resume) from [] (rpm_callback+0x79/0x8c)
[59800.830608] [] (rpm_callback) from [] (rpm_resume+0x25b/0x3f8)
[59800.838237] [] (rpm_resume) from [] (__pm_runtime_resume+0x43/0x54)
[59800.846319] [] (__pm_runtime_resume) from [] (pruss_probe+0x64/0x478 [uio_pruss])
[59800.855635] [] (pruss_probe [uio_pruss]) from [] (platform_drv_probe+0x35/0x74)
[59800.864757] [] (platform_drv_probe) from [] (driver_probe_device+0x173/0x31c)
[59800.873702] [] (driver_probe_device) from [] (bus_for_each_drv+0x3f/0x60)
[59800.882297] [] (bus_for_each_drv) from [] (device_attach+0x57/0x6c)
[59800.890366] [] (device_attach) from [] (bus_probe_device+0x5b/0x78)
[59800.898435] [] (bus_probe_device) from [] (device_add+0x303/0x430)
[59800.906422] [] (device_add) from [] (of_platform_device_create_pdata+0x5f/0x8c)
[59800.915540] [] (of_platform_device_create_pdata) from [] (of_platform_notify+0x73/0xa0)
[59800.925364] [] (of_platform_notify) from [] (notifier_call_chain+0x4b/0x68)
[59800.934137] [] (notifier_call_chain) from [] (__blocking_notifier_call_chain+0x2d/0x3c)
[59800.943954] [] (__blocking_notifier_call_chain) from [] (blocking_notifier_call_chain+0x17/0x1c)
[59800.954556] [] (blocking_notifier_call_chain) from [] (of_property_notify+0x3b/0x54)
[59800.964107] [] (of_property_notify) from [] (__of_changeset_entry_notify+0x2f/0x98)
[59800.973571] [] (__of_changeset_entry_notify) from [] (of_changeset_apply+0x53/0xe0)
[59800.983042] [] (of_changeset_apply) from [] (__of_overlay_create+0x21d/0x380)
[59800.991996] [] (__of_overlay_create) from [] (capemgr_load_slot+0x2c9/0x440)
[59801.000854] [] (capemgr_load_slot) from [] (slots_store+0xe1/0x230)
[59801.008927] [] (slots_store) from [] (kernfs_fop_write+0x85/0x130)
[59801.016913] [] (kernfs_fop_write) from [] (__vfs_write+0x1b/0x90)
[59801.024807] [] (__vfs_write) from [] (vfs_write+0x65/0x12c)
[59801.032175] [] (vfs_write) from [] (SyS_write+0x31/0x6c)
[59801.039283] [] (SyS_write) from [] (ret_fast_syscall+0x1/0x4c)
[59801.046900] —[ end trace 946addae1fb87bd8 ]—
[59801.070988] pruss_uio 4a300000.pruss: No children
[59801.081029] gpio-of-helper ocp:gpio_helper: ready
[59801.085871] bone_capemgr bone_capemgr: slot #12: dtbo ‘BB-BONE-PRU-01-00A0.dtbo’ loaded; overlay id #0
`
I don’t really understand the middle part, but it seam not to have error.

I have still

`

lsmod |grep uio

uio_pruss 4590 0
uio_pdrv_genirq 3317 0
uio 8319 2 uio_pruss,uio_pdrv_genirq

`

`

cat $SLOTS

0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
12: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-BONE-PRU-01
`

Then, I just use the makefile

`

make

pasm -b major-tom-pru.p

PRU Assembler Version 0.86
Copyright © 2005-2013 by Texas Instruments Inc.

Pass 2 : 0 Error(s), 0 Warning(s)

Writing Code Image of 6 word(s)

cc -Wall -Werror -c -o major-tom-pru.o major-tom-pru.c
cc major-tom-pru.o -lpthread -lprussdrv -o major-tom-pru
`

`

sudo ./major-tom-pru

prussdrv_open() failed

`

So it is link with this code section
/* open the interrupt */
if((rtn = prussdrv_open(PRU_EVTOUT_0)) != 0) {
fprintf(stderr, “prussdrv_open() failed\n”);
return rtn;
}

And generally they fixed it by adding the DTS but I already loaded it.

That is why I have no clue on what’s going wrong on both example.
My main purpose is to test if my configuration are correct in order to do then more advance
example with the PRU.
If someone have an idea to fix this ?
In addition if someone have some other good example on PRU working on the v4.1.19, I will be glad to see them.
Thanks by advance
Regards
Vincent

Rq ;

`

uname -a

Linux beagle01 4.1.19-bone20 #1 Tue Mar 8 01:54:43 UTC 2016 armv7l GNU/Linux

`

I forgot to indicate the release on which I’m working on :

`

lsb_release -da

Distributor ID: Debian
Description: Debian GNU/Linux 8.3 (jessie)
Release: 8.3
Codename: jessie
`

Is anyone have already work on the PRU on this kernel version ?
Thanks by advance.
Regards.
Vincent

Le mardi 5 avril 2016 11:33:06 UTC+2, Le Costaouec Vincent a écrit :

I think the output of uname -a for your kernel version is more helpful than the Debian version which is running when it comes to overlays, modules, and Beaglebone hardware specific issues.

I’m subscribing to this thread, as you are doing what I’ve planned to do in the not too distant future, so I’m really interested in what the solutions are to your problems here.

The Beaglebone development is fast and furious, which is good, but the developers don’t seem to give a hoot if changes break what little documentation is out there, which IMHO makes the BB a rather poor choice for newbies.

I’ve posted a fair amount about Bonescript issues because I’m trying to help a friend get started with an automation project for a solar powered, off-grid, hydroponic green-house. He needs some A/D or I’d have recommended a Rasperry Pi2 from the start, but if things don’t fall into place soon I’ll just buy him a Pi Hat that has A/D and give it to him along with one of my RiP2 boards as the frustration factor is really turning me off. Without me helping him, he’d already have tossed the BB in the trash and did the best he could with timers and relays, which he totally understands – but he was looking to get creative with some of his control ideas that he clearly sees as difficult to do without a computer.

Here is what you need to understand about people on this list. There are no “developers" on this list. No one on this mailing list is paid by BeagleBoard. We are all volunteers, including Robert Nelson. If you have a problem with Documentation, then why don’t you create it so others can learn. If you need help with getting the info you need, we are all prepared to help.

Regards,
John

I think one of the problems is that there are now too many variables for getting a consistent working “platform” for the PRU’s.

We have two Debian releases - Wheezy and Jessies

We have too many possible kernels to work with.

And we have uio_pruss, or remoteproc / rpmsg.

Me, I’m not super experienced with using the PRU’s but have worked with them. But I’m using a Wheezy rootfs, and a 4.1.x kernel. plus uio_pruss, and not remoteproc. So, I’m not really equipped to help anyone outside of that scope. Then again, even if someone were to duplicate exactly what I’ve done, I’m not super experienced. But usually I’m very good at troubleshooting, and I can write advanced code . . .

I understand this. I’m only stating my observations. Kind of hard to “step up” and document something if the instructions won’t work after another release or two.

If I find an answer I follow up so that a Google search that finds the problem might also find my solution (if any). But fact of the matter, unless Robert or Jason come in with an answer, there usually isn’t one.

When I broke the 2016-03-27 node-red by doing an npm install of node-red-node-beaglebone, I followed up in my thread that I’d got it working again with npm uninstall and apt-get purge & apt-get install bb-node-red-installer. But it’d have been far more productive if the “notes” about the 2016-03-27 image had said node-red-node-beaglebone was broken despite node-red running “out of the box”.

But fact of the matter, unless Robert or Jason come in with an answer, there usually isn’t one.

So you’re saying only Robert and Jason know how to setup and use the PRU ? I know that’s wrong. I can tell you what the deal is with me however. When I come on, and say I could perhaps write up a how to and share it with the group, for situations where multiple people have issues with one thing or another. To which I get an answer by someone saying " that would be awesome, because I can’t be f’d to bother taking the time to fix it myself".

How do I respond to a comment like that ? I can tell you exactly what I think about such comments. If you can’t bother to help yourself, then I can’t bother to help you. Plain and simple . . .

So if you cannot do it, then you want another volunteer to do for you? We are all in the same boat as you, and we all do our part, but simply complaining about the situation without first trying to improve the situation isn’t helpful.

Previously, you mentioned Raspberry Pi, which for the most part uses the same kernel and Debian FS as BBB, so any documentation that applies to Raspberry Pi also applies to BBB.

The real turmoil started with the transition from the V3 Kernel to the V4 kernel with the abandonment of the board file and the transition to the DeviceTree. With TI attempting to mainline all it’s driver code we expect to see many of the problems like your in the future. Packages for the most part should work out of the box.

Regards,
John

That should read

With TI attempting to mainline all it’s driver code we don’t expect to see many of the problems like your in the future

Regards,
John

Thanks guys for yours different interesting note.

I’have some few update :

I succeed to figure out how to solve the error :
`
prussdrv_open() failed

`

The issue was that the function work like that :

`

int prussdrv_open(unsigned int host_interrupt)
{
char name[PRUSS_UIO_PRAM_PATH_LEN];
if (!prussdrv.fd[host_interrupt]) {
sprintf(name, “/dev/uio%d”, host_interrupt);
prussdrv.fd[host_interrupt] = open(name, O_RDWR | O_SYNC);
return __prussdrv_memmap_init();
} else {
return -1;

}
}

`
So it was trying to load /dev/uio0 but when I look for it, it was not there.
So I change to this dts : https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-REPLICAP-00B1.dts
And it’s succeed to create the /dev/uio0.

However, now I’m facing new issue when I’m trying to execute the different programs :

`

root@beagle01:~/labs/bbb-pru/simple-tests# sudo ./major-tom-pru
[167188.892328] Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6da3000
[167188.900146] pgd = ddde8000
[167188.902965] [b6da3000] *pgd=9dc30831, *pte=4a304303, *ppte=4a304a33

root@beagle01:~/labs/exploringBB/chp13/fixedPRUClock# sudo ./fixedclock
[167484.486691] Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6e32000
[167484.494512] pgd = dcd78000
[167484.497330] [b6e32000] *pgd=9df94831, *pte=4a304303, *ppte=4a304a33

`

It’s seem to appears when this function is launch :

`

int __pruss_detect_hw_version(unsigned int *pruss_io)
{

if (pruss_io[(AM18XX_INTC_PHYS_BASE - AM18XX_DATARAM0_PHYS_BASE) >> 2]
== AM18XX_PRUSS_INTC_REV)
return PRUSS_V1;
else {
if (pruss_io

[(AM33XX_INTC_PHYS_BASE - AM33XX_DATARAM0_PHYS_BASE) >> 2] ==
AM33XX_PRUSS_INTC_REV)
return PRUSS_V2;
else
return -1;
}
}

`

Especially On the first case of the if.

It was launch by :

`

prussdrv.pru0_dataram_base =
mmap(0, prussdrv.pruss_map_size, PROT_READ | PROT_WRITE,
MAP_SHARED, prussdrv.mmap_fd, PRUSS_UIO_MAP_OFFSET_PRUSS);
prussdrv.version =
__pruss_detect_hw_version(prussdrv.pru0_dataram_base);

`

So as before, if anyone have a clue on what’s going wrong :slight_smile:

Thanks by advance
Regards
Vincent

Hi, finally, I just tried the version 4.1.21-bone-rt-r20 of the kernel and for me it’s work for me.
I figured this out from this post : https://groups.google.com/forum/m/#!topic/beagleboard/p8aD2oXe9Ks

So you have to use the version version 4.1.21-bone-rt-r20 and superior or the v4.1.18-ti-r56 and superior.
Please post it if it’s also work for you. Thanks

Enjoy !
Vincent

Le vendredi 8 avril 2016 11:35:29 UTC+2, Le Costaouec Vincent a écrit :