PRU code to read ADC freezes after declaring variables in Shared RAM

I am using a BeagleBone Black Wireless system to do some A/D work. The output of is at the end of this message.

I use PRU0 to read three channels of A/D in a loop that takes about 2.75 ms on average. I need to store the data from two of these channels in an array so that when an event is detected in the analog input, I stop and analyze the collected data. Although in production we do not need to send data back to the host program, we are doing it now via RPMSG so we can collect the data and store it in a file for analysis.

I use the counter in the IEP to get precise interval timing to associate with each data collection event.

Late last week, as I started to add more functionality step by step, I started to have some issues I have not seen before and appreciate help understanding these. I am not a kernel or driver guy. I run what I download on recommendations of others. The changes I have made have not changed the remoteproc, virtio, etc. setups (as far as I know, at least not directly) and they have been working in prior versions of this code.

I have established four unsigned int arrays in the PRU’s shared memory space. Using the C code below.

#define SHARE_MEM 0x10000


volatile unsigned int *DetTSampleSet = (unsigned int *) SHARE_MEM;

volatile unsigned int *DetBSampleSet = (unsigned int *) (SHARE_MEM + (E_RING_BUFFER_SIZE * sizeof(unsigned int)));

volatile unsigned int *TimeSampleSet = (unsigned int *) (SHARE_MEM + (E_RING_BUFFER_SIZE * sizeof(unsigned int)*2));

volatile unsigned int *PressureSampleSet = (unsigned int *) (SHARE_MEM + (E_RING_BUFFER_SIZE * sizeof(unsigned int)*3));

I added them one by one and the code worked as each one was added. Then I began to put my A/D raw data into the array variables and pass it to a routine that right now only adds two of them together and sends the result back as an unsigned int too.

Based on research and information in resources such as Molloy’s book and Yoder’s cookbook, I think this is the right approach but could have something screwed up of course.

Also, in case it might be important, I boot from an SD card and the data that is collected is written to that card as well. As the data is returned from the PRU to the Host via RPMSG, I write one message per cycle to the screen using printf to know where we are in the process and write the data to the file on the SD card in CSV format. Each record has 10 fields. So at the end of each record there is output to the screen. I have noticed that this output tends to slow down or ‘freeze’ for a second or two more often as I have worked with this project more and more.

So I have a couple of primary questions about this and a few more observations are shared below.

  1. Could it be that the SD card is going bad or wearing down with use? I would not have expected this based on its age.
  2. The current rev of the PRU code is freezing the system completely. Only the PWR, WL and BT leds are on and they are full on. I have to cycle the power to restart the system.
  3. I am using the IEP. Is this related to the wi-fi somehow? I do not think so but wanted to confirm this.

I also get a variety of errors in the journal and would appreciate any insights into them as I don’t understand them.

Here’s the first (the last line of this block of messages). The program has run even when this message is logged. What does this mean?

May12 12:33] remoteproc remoteproc1: powering up

[ +0.000679] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 122452

[ +0.013186] pruss 4a300000.pruss: configured system_events[63-0] = 00000000,00030000

[ +0.000022] pruss 4a300000.pruss: configured intr_channels = 0x00000005 host_intr = 0x00000005

[ +0.011886] remoteproc remoteproc1: registered virtio0 (type 7)

[ +0.000022] remoteproc remoteproc1: remote processor is now up

[ +0.088779] virtio_rpmsg_bus virtio0: rpmsg host is online

[ +0.001103] pm33xx pm33xx: PM: Unable to allocate memory from ocmcram

[ +0.040430] pm33xx: probe of pm33xx failed with error -12

Here’s the second… I think this has to do with the wi-fi trying to establish something it can’t. Is there a way to kill this?

My thought is that it’s taking cycles away on the Linux host side that I need to avoid.

[May12 12:50] wlcore: WARNING no fw rx ba on tid 2

I got this once yesterday and it forced a hard reset. I have received is this one in the terminal window. I have never seen it before.

Message from syslogd@beaglebone at May 11 16:35:05 …

systemd[1]: Caught , dumped core as pid 32667.

Broadcast message from systemd-journald@beaglebone (Tue 2021-05-11 16:35:05 EDT):

systemd[1]: Caught , dumped core as pid 32667.

Message from syslogd@beaglebone at May 11 16:35:05 …

systemd[1]: Freezing execution.

Broadcast message from systemd-journald@beaglebone (Tue 2021-05-11 16:35:05 EDT):

systemd[1]: Freezing execution.

debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/

[sudo] password for debian:




dogtag:[ Debian Buster IoT Image 2020-04-06]

bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2018.03-00002-gac9cce7c6a]:[location: dd MBR]

UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]

UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]

UBOOT: Loaded Overlay:[BB-ADC-00A0]

UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]

UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]

UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]

UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]



/boot/uEnv.txt Settings:








pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]






groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc admin spi iio docker tisdk weston-launch xenomai cloud9ide]

cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]

dmesg | grep remote

[ 69.444537] remoteproc remoteproc0: wkup_m3 is available

[ 69.731914] remoteproc remoteproc0: powering up wkup_m3

[ 69.731947] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217148

[ 69.732222] remoteproc remoteproc0: remote processor wkup_m3 is now up

[ 71.971917] remoteproc remoteproc1: is available

[ 71.982645] remoteproc remoteproc2: is available

dmesg | grep pru

[ 71.971917] remoteproc remoteproc1: is available

[ 71.972101] pru-rproc PRU rproc node pru@4a334000 probed successfully

[ 71.982645] remoteproc remoteproc2: is available

[ 71.982788] pru-rproc PRU rproc node pru@4a338000 probed successfully

dmesg | grep pinctrl-single

[ 0.951277] pinctrl-single 44e10800.pinmux: 142 pins, size 568

dmesg | grep gpio-of-helper

[ 0.964973] gpio-of-helper ocp:cape-universal: ready


Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Hi Walter!

Your solution gets pretty simple when you use libpruio in MM mode with a pre trigger. See

for details.