• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 751 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

AM335x PRU access to I2C and other peripherals on L4_PER bus

AM3351: Read/write to registers on the AM355x

Danilo A.
Mastermind 28640 points
Part Number: AM3351

Hi Team,

We would like to ask your help regarding our customer's inquiry below.

“Hello,I am currently developing software for the Beaglebone black and I was wondering how to read/write to specific registers on the am355x. I am specifically interested in the i2c registers. I was wondering if there were some header files I needed to include in a c program to gain this functionality. I know that when writing firmware for the prus they have header files that allow you to access the registers on the pru so I am wondering if there is something similar for the ARM side? Thank you”

I would like to use the solution laid out in the link below about how to provide the pru access to the i2c bus, however the solution in the link below is not clear. If i could get some help on this as well it would be great. 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/458311/am335x-pru-access-to-i2c-and-other-peripherals-on-l4_per-bus

Regards,

Danilo

  • 0
    TI__Guru 58905 points

    Hello Danilo,

    Are you trying to do this in Linux environment?

    Thanks and regards,

    Jianzhong

  • 0 in reply to Jianzhong Xu
    TI__Mastermind 28640 points

    Hi Jianzhong,

    Yes, the customer is using Linux.

    Regards,

    Danilo

  • 0 in reply to Danilo A.
    TI__Guru 58905 points

    Danilo,

    Thanks for the confirmation. I'll let our PRU expert to respond.

    Regards,

    Jianzhong

  • 0 in reply to Jianzhong Xu
    TI__Mastermind 28640 points

    Hi Jianzhong,

    We will be waiting for our PRU expert's feedback.

    Regards,

    Danilo

  • 0 in reply to Danilo A.
    TI__Guru** 100920 points

    Hello Danilo,

    To confirm: are you trying to directly access registers using C code running on a PRU cores? Or are you trying to access registers using C code running on the AM335x ARM core?

    If you are trying to access registers from the AM335x ARM core, I want to clarify further. What OS is running on the AM335x ARM core? (What Jianzhong said "Linux environment", he was talking about Linux running on the AM335x ARM core, not using a Linux PC as a development environment). If Linux is running on the AM335x ARM core, are they trying to access the registers from the terminal, from Linux userspace, from a Linux kernel driver?

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Mastermind 28640 points

    Nick,

    Here is the response of our customer,

    I am trying to directly access registers using C code running on a PRU cores. I just tried using mmap() with the function open() to do so but I don’t know if these functions work with pru firmware(can you please confirm this?).

    Regards,

    Danilo

  • 0 in reply to Danilo A.
    TI__Mastermind 28640 points

    HI Nick,

    According to our customer,

    So, after doing some reading I’ve come to believe that you can not use mmap on the PRU due to the lack of an OS on the PRU (correct me if I am wrong). So, I came up with an idea to get access to the am335x registers from the pru by using mmap from the ARM side in the user space and I would like to know if it could work or if you have any ideas. My idea is to call mmap from a user space program and have it create a block of memory that has access to /dev/mem (so mapped I/O) and mmap will return the starting address to this block of memory that contains the mapped I/O. This starting address is then stored into the PRU-ARM 12KB shared RAM and then the PRU can access the mapped I/O from the starting address that’s stored into the shared RAM. I believe this will provide the PRU access to the I2C registers that are on the ARM side. I included an image to try to make this a bit clearer.

    Regards,

    Danilo

  • 0 in reply to Danilo A.
    TI__Guru** 100920 points

    Hello Danilo,

    First caveat: check the AM335x version 

    Note that AM3351 does not have PRU-ICSS. Make sure the customer references the AM335x Datasheet "Device Features Comparison" to make sure they are using a part number with PRU in it.

    Accessing memory locations from the PRU

    Please point the customer to the PRU Software Support Package. You can find that in the Linux Processor SDK under example-applications/pru-icss-x.x.x, or at the git repo: https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/
    I    f using the git repo, please make sure you are using the version of PSSP that corresponds to your version of Linux. For example, if the customer is using Linux kernel 5.4 or earlier, they should use PSSP v5.9 or earlier. The PSSP packaged in the Linux SDK will always be compatible with the Linux SDK kernel version.

    For an example of using PRU to control another peripheral on the processor (including how to access specific register and memory locations), take a look at examples/am335x/PRU_ADC_onChip/pru_adc_firmware.c. The PRU can directly access the I2C registers without ARM involvement. See the example README for more.

    The PRU can read any area of memory, and write to any area of memory that does not require elevated permissions (e.g., PRU does not have the permissions to change pinmux settings).

    From pru_adc_firmware.c:

    /* Control Module registers to enable the ADC peripheral */
#define CM_WKUP_CLKSTCTRL  (*((volatile unsigned int *)0x44E00400))
#define CM_WKUP_ADC_TSC_CLKCTRL  (*((volatile unsigned int *)0x44E004BC))

...

void main(void)
{

    ...

	/* 
	 * Allow OCP master port access by the PRU so the PRU can read 
	 * external memories 
	 */
	CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
	
	init_adc();
}
void init_adc()
{

	/* set the always on clock domain to NO_SLEEP. Enable ADC_TSC clock */
	while (!(CM_WKUP_ADC_TSC_CLKCTRL == 0x02)) {
		CM_WKUP_CLKSTCTRL = 0;
		CM_WKUP_ADC_TSC_CLKCTRL = 0x02;
		/* Optional: implement timeout logic. */
	}
}

  • 0 in reply to Nick Saulnier
    TI__Mastermind 28640 points

    Hi Nick,

    According to our customer,

    Hi, this does resolve my issue but I was wondering if since I am accessing the i2c from the pru is the performance still deterministic with no jitter? Or can I expect the same i2c performance on the pru side as if I was accessing the it from the arm side?

    Regards,

    Danilo

  • 0 in reply to Danilo A.
    TI__Mastermind 28640 points

    Hi Nick,

    May we request an update to this inquiry?

    Regards,

    Danilo

  • 0 in reply to Danilo A.
    TI__Guru** 100920 points

    Hello Danilo,

    Thank you for the pings.

    For information on PRU read latencies, please see this app note:
    https://www.ti.com/lit/sprace8

    In general, reads to memory locations within the PRU-ICSS are deterministic. (the one edge case is if a core external to the PRU-ICSS is accessing that memory at the exact same time - in that case, bus arbitration needs to occur. But it doesn't sound like we need to do a deep dive on that concept for this customer usecase).

    Reads outside of the PRU-ICSS use the system busses. Those reads are no longer 100% deterministic, because other cores might be using the busses at the same time. However, I would still expect PRU accesses to the I2C to have less jitter than ARM accesses since you don't have to deal with all the scheduling challenges of the Linux OS.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Mastermind 28640 points

    Hi Nick,

    Our customer's inquiries have been resolved. Thank you very much for your help!

    Regards,

    Danilo