Errors and freezes when loading PRU firmware that now allocates memory to PRU Shared RAM

This is the first response of this kind I've received from TI.  Frankly, it's a bit puzzling because I'd think TI would want to support any project that might result in the sale of more chips.   But I know having expertise on the team for every nuance is not cost effective too.

My other questions have been answered even though I'm running the same OS (yes, Debian).  I'm not really sure how you are making a distinction so let me ask this more succinctly before tossing in the towel because I think you do support development in C for the PRUs.

1. Does the approach I have used to allocate variables into PRU shared memory work and do you see any issues with it?

2. Do wi-fi and the IEP interact or conflict?

Hi Walter,

Walter Cromer said:

Frankly, it's a bit puzzling because I'd think TI would want to support any project that might result in the sale of more chips.

Of cause we want to provide the best support on our devices. However it is technically impossible to support any non-TI released software and board designed using our devices. Just give you one example, we don't know what the userspace library versions used in Debian filesystem, we don't know what kernel version runs on Debian, and if any additional kernel patches added by the Beagle community and it is well validated.

Walter Cromer said:

1. Does the approach I have used to allocate variables into PRU shared memory work and do you see any issues with it?

I am routing your query to our PRU expert for comments.

Walter Cromer said:

2. Do wi-fi and the IEP interact or conflict?

Our PRU expert might provide a generic comment on this, but probably won't be specific, as we don't have experience on this community's Beaglebone Black Wireless board, as TI Processor SDK Linux package only supports the community's Beaglebone Black board, not its Wireless variant.

Understood.   I've just received support before for my projects running Debian so it's never been an issue before.    

So just so I am clear, what OS should I be running on a Beaglebone Black to expect support from TI too?

Hello Walter,

SOFTWARE SUPPORT FROM TI
We can answer questions about software that TI developed and tested. For example, we can support Linux questions about the version of Linux distributed in AM335x Linux Processor SDK 6.3 (kernel 4.19) or the next AM335x SDK which releases within a month (kernel 5.4). 

IEP & WIFI?
I have not looked into wifi. However, I would be surprised if the PRU's IEP timer was used by something outside of the ICSS. If you were running PRU Ethernet or PRU networking protocols on your PRU cores, then that firmware would use the IEP in a similar manner to how CPSW Ethernet uses the CPTS.

PRU SUPPORT IN GENERAL
We support general PRU firmware development questions regardless of the version of Linux you are running. Keep in mind that we would still not be able to answer questions about non-TI software like the PASM compiler or a method of loading the PRU that does not use the RemoteProc driver.

You can definitely define areas of memory within the PRU and access it in C. For example, this code from our _Getting Started Labs_ defines variables at a specific location in PRU DMEM:

#include <stdint.h>
#include "resource_table_empty.h"

/* TODO: define c */
/* a, b, and c are stored in a defined location in PRU memory */
#define a  (*((volatile unsigned int *)0x100))
#define b  (*((volatile unsigned int *)0x104))
#define c  (*((volatile unsigned int *)0x108))

/*
 * main.c
 */
void main(void)
{
...

	a = 1;
	b = 2;
	
	/*
	 * TODO: store the sum of the numbers at memory locations a and
	 * b in memory location c
	 */
	c = a + b;
...
}

It sounds like you've made some progress since your initial post, so I'll wait for your response before trying to answer any more questions.

Regards,

Nick

Nick, 

Thank you for all of this information. It's helpful to a newbie like me.  We are focused on using the Beaglebone Black series right now.  I didn't initially realize that the Beaglebone Black Wireless doesn't use a TI chip but instead uses a chip that has AM355x mask within it.   So, I certainly can't expect TI to support that all in.  

I don't think the IEP is being used by the wi-fi now.   But the wi-fi is tossing some warnings so I moved off it to a basic Beaglebone Black with a tethered ethernet connection.   The precise timing I'm getting from my program using the IEP is rock solid so I do not think the IEP is impacted by tethered ethernet either.   

I have successfully allocated some arrays into the shared RAM of the PRUs and that seems to work without a hitch.   Here's my code in case you might see a problem with it.  Basically, I want to place these four arrays in the shared memory starting at the beginning of shared memory and then put them one after the other without any overlap.

#define SHARE_MEM 0x10000

#define E_RING_BUFFER_SIZE 60

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);

Later in my code, I use them like this where pnr is an index into the array.

DetBSampleSet[pnr]=RawAnalog;

Do you see anything obviously wrong with this approach?  It's working fine so far.

I am using remoteproc because I definitely want to use something that is supported by TI.   It works for me so far but I have a weird problem that I cannot figure out.   I doubt this is something TI can support but I'll toss it out there just in case.

My code is all written in C.

The PRU code comes up and waits for a message from the host code.  The host code sends specific code words through the RPMSG to the PRU and when the PRU gets an interrupt and reads the message, it then executes based on what the message is.  This works fantastic until...

In one particular action the PRU needs to take, I have two unsigned int variables that I initialize at startup.  If I DO NOT also include them inside a particular case statement and set their values there, the PRU doesn't respond to the message from the host and start the action it's being instructed to do.  It's extremely weird.  I can't imagine this has anything to do with the processor.  I've been trying to declare and initialize these two variables differently but nothing is taking care of the problem.   It's probably a C issue and I'm just not seeing it yet.  So close....

I appreciate all the help I get from these communities.  I am working alone and it's tough when you hit a problem like this as I am sure that many others can attest to this too.

Walter

Hello Walter,

I apologize for the delayed response. Let me know if you need us to continue the conversation.

Regards,

Nick

Nick, 

I was able to eliminate the problem by renaming the two variables so I guess it could be a problem in the toolchain somewhere.  But I have other variables that use a similar naming structure.

They were originally Start_of_Pulse and End_of_Pulse.  The code runs but the PRU does not respond to a message sent by the host if the line

Start_of_Pulse = -1;

is not present.

I needed to be able to set Start_of_Pulse to the place in the array where the currently read data is stored.  Like this, 

Start_of_Pulse = pnr; // pnr is the current position in the ring buffer array.  Both are unsigned int.

If I changed the line to this, 

PulseStart = pnr; 

everything works!

Very strange.  I've moved on but it would be nice to know what caused this.

I know people say this all the time but the only thing I would change between 'working' and 'not working' was the line 

Start_of_Pulse = -1; 

to 

Start_of_Pulse = pnr;