Problems running PRU code on PocketBeagle but not on Beagle Black

General Discussion
, ,
1

Hi,

I have an assembly code(using clpru) that is reading using ECAP a signal meanwhile is generating DShot outputs (both are RC protocols).
The code is running perfectly on beaglebone black, meanwhile the ecap readings are erratic as follow - Erratic Behavior - YouTube

Any clue of what can cause this difference ? I have a similar code - but using pasm and reading the ecap and generating pwm signals working on both beagles.

thanks.

2

Sorry, I don’t understand the video, and I never used clpru.

Kernel version[s]?
How gets the firmware uploaded/startet?
Can u use PASM for that code (max. 2000 instruction isn’t much to translate)?

Regards

3

Hi @DTJF

on the video, the sliders should be changing one slider at time, but using on pocketbeagle, all sliders are changing at same time.
I’m loading the code directly from memory and pru control registers.
both are with kernel 5.10 - black and pocket.
Pasm is not supported by ti, and all pasm code should be migrate to clpru so that is the reason we are migrating.

best regards.

4

When TI doesn’t support the working solution, I don’t follow TI.

BTW: PASM is a TI project.

Good luck!

5

TI is not supporting the PASM anymore, still available for your all risk - GitHub - beagleboard/am335x_pru_package
and the support is “Community” only :slightly_smiling_face:

6

Hi @RobertCNelson

could you please help me understanding one thing.
I was testing with 5.10-ti kernel and I was having this problem with ecap reading.
Downgrading to 4.19 ti kernel, the code is working. There is any relation between how PRU deal with the code in different kernels ?
One difference, the P2_18 pin in kernel 4.19 is configured as ecap meanwhile in 5.10 is ecap_pwm, this can throw this problem I’m having ?

Best regards.