PROCESSOR-SDK-AM62X: AM6234ATCGHAALW use PRU to feed the audio stream to McASP

Hello Kenny,

Yes, if you were able to do something with AM335x PRU, you can absolutely do the same thing with AM62x PRU.

I do not understand your sentences here. Can you please provide additional details?

"

however we met problem on AM62x that we use PRU (Core_cLK 333Mhz) to feed audio stream to McASP, with AHCLK @ 3.072Mhz (that means audio normal sampe rate 48K ), 

then return "XUND RN" , wtih AHCLK 192Khz we'got signal at pin AXR however that can't output nornmal audio.

"

If it is purely a matter of your code being written to run at 200MHz (from the AM335x PRU), and the AM62x PRU core is running too fast at 333MHz, then you can simply select a different clock for the AM62x PRU subsystem to make it run at 200MHz instead. I have not had time to write an FAQ specifically for AM62x yet, but it should follow the same basic ideas as on AM64x: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1049800/faq-pru_icssg-how-to-check-and-set-pru-core-frequency-in-linux

Regards,

Nick

hi Nick,

I am with Kenny. Let me tell the detail and the background.

The product we made is a realtime net audio module, the first generation product is base on AM3358 platform, that is ok. But the AM3358 is old and expensive, so we decide to find a better one to instead it (cheaper, and higher performance), then AM62X is come.

The realtime net audio module system architecture on am3358 is :

1, net tx or rx audio data.

2, cpu handle the data to or from pru.

3, pru handle the data to or from mcasp.

Why do like this,  Why not handle the data(step 2) to or from Linux ALSA? Maybe you have these question. That because ALSA is complicated, it delay is bigger than pru+mcasp,  realtime poor.

So, we think use the same architecture on AM62X, but when mcasp ACLKX set a low frenquency(192khz), the AXR wave can be saw on oscilloscope. if ACLKX set a normal frenquency(3.072Mhz), no AXR wave on oscilloscope, and mcasp XUNDRN error occur.  

it seem the speed of data transfer between pru and mcasp on AM62X is not enough. the data transfer code is same between AM3358 an AM62X. 

hope your replay. 

Regards,

Song

this reply merged into this thread on 8/1/2023

Part Number: AM623

I used AM3358 to receive audio data from the network before, and then from PRU to MASP for output. Now until AM623, the problem has been found:

1. Is there any tailoring of the AM623 compared to the AM3358 PRU function?

2. When the audio data reaches 192K, the MASP output is normal, but at a high frequency of 3.072M, the MASP output is no longer available. Does it not support high frequencies? Or where is the problem?

3. Is it feasible to transplant AM3358 to AM623? What are the differences between the two?

Hello Song,

I assume you are on the same team as Zhang? If so I'll merge his thread into this thread so we keep the discussion in one place: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1253479/am623-3-072m-masp-error

Helpful Documents about the PRU

Your team can find high level differences between the PRU subsystem on AM335x and the PRU subsystem on AM62x here: https://www.ti.com/lit/sprac90

While this migration guide does not include information about AM62x, it does have concepts that might be helpful for moving PRU code from one processor to another: https://www.ti.com/lit/spracj8

I assume your team is already experienced with PRU development, but just in case I'll link to our PRU resources: https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/09_00_00_03/exports/docs/linux/Foundational_Components_PRU_Subsystem.html 

and the getting started labs, for anyone just starting out with PRU development: https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/09_00_00_03/exports/docs/common/PRU-ICSS/PRU-Getting-Started-Labs.html

Debugging what you are observing 

Ok, so XUNDRN = transmix underrun.
From TRM: "A buffer underrun occurs when a serializer is instructed by the transmit state-machine to transfer data from
XRBUFn buffer to XRSRn shift register, but the corresponding (MCASP_XBUFn ) register has not yet been
written with new data since the last time the transfer occurred. When this occurs, the transmit state-machine sets
the XUNDRN flag."

1) How are you performing your data transfers? (both the data between the Linux A53 core and the PRU cores, and the PRU cores and the McASP)

2) How are you controlling the McASP? (i.e., is it enabled in Linux devicetree file and initialized by Linux driver? Is PRU initializing and controlling the peripheral? etc

3) Are you able to see any data at all in the McASP buffers when the underrun occurs? I think your assumption that the data transfer is not keeping up sounds reasonable, but it would be good to check that things also are not just breaking completely when going from 192 kHz to 3MHz.

Regards,

Nick

Hello Nick,

Yes, we are on same team as Zhang. The issue is same.

"1) How are you performing your data transfers? (both the data between the Linux A53 core and the PRU cores, and the PRU cores and the McASP)"

I use a software loop to transfer data from pru to mcasp. As follow:

static void mcasp0_data_put(uint32_t *data, int size)
{
        while (size > 0) {
                *((volatile uint32_t*)MCASP0_DATAPORT) = *data;
                data++;
                size--;
        }
}

MCASP0_DATAPORT is defined as:

#define MCASP0_DATAPORT 0x02B08000

That is mcasp "MCASP0_DMA" register address.

"2) How are you controlling the McASP? (i.e., is it enabled in Linux devicetree file and initialized by Linux driver? Is PRU initializing and controlling the peripheral? etc"

McASP power on by Linux /sys, initialization and configuration by pru code.

"3) Are you able to see any data at all in the McASP buffers when the underrun occurs? I think your assumption that the data transfer is not keeping up sounds reasonable, but it would be good to check that things also are not just breaking completely when going from 192 kHz to 3MHz."

I will try to observe the data size in mcasp fifo buffer to comfirm underrun error.

Regards,

Song

Hello Song,

Sounds good. I will wait to comment more until you are able to take a look at the buffer. In the meantime, I am sending your thread over to a team member more experienced with audio to comment on the general data transfer scheme from the McASP side. They'll pass the thread back to me for PRU discussions later.

Regards,

Nick

Hello Nick,

I made a test for confirm underrun error.

I write some data to MCASP , and read back the MCASP's fifo status reg (MCASP0_WFIFOSTS Register), but the value is always 0. 

It seam no data in fifo. I don't know why. But on AM3358, the data size can be readed by MCASP0_WFIFOSTS Register after write.

So, I can't comfirm the problem.

Regards,

Song

Song

jieoh song said:

#define MCASP0_DATAPORT 0x02B08000

Where are you getting this address?

You are not using DMA, correct? 

When bit clock is set to 3.072MHz,  do you see any activity on the McASP serializer? 

--Paul 

Paul 

There is a "McASPx Data " register on AM3358, but I can't find a similar register on AM62X.

I saw a register defination in AM62X dts file, that is "MCASP0_DMA", so I used it.

The DMA is not used.

I can see fifo data size changeing when mcasp runing on AM3358, but I can't see on AM62X.

Regards,

Song

Hello Song,

Please read the below section and let me know if this helps.

11.3.1.4.2.4 Transmit Operation

Regards,

Sreenivasa

Hello Sreenivasa

I readed this section. But how to use it? Run it on pru or on arm?

I once thought of using DMA, and made some reserch about "DMA using", but the DMA is difficult to use, whether on arm or on pru . 

Regards,

Song

Hello Song,

Thank you.

You should be able to use ARM. The PRUSS on the AM62x does not support the ICSS and hence not sure if the PDMA is supported.

Regards,

Sreenivasa

Hello Zhomng, 

I am adding the Webex discussion below.

Shengyue Zhong said:

 I want to ask if PRUSS on AM62x support Ethernet? Thanks

No.

is PRU-ICSS support ethernet?

Yes.

Refer below for comparison of PRU features:

https://www.ti.com/lit/an/sprac90g/sprac90g.pdf?ts=1691488145169&ref_url=https%253A%252F%252Fwww.bing.com%252F

Regards,

Sreenivasa

Hello Sreenivasa

OK,  Thank you. 

Regards,

Song

Hello Song,

Thank you for the note.

Could we close the thread?

Regards,

Sreenivasa

Hi, Mr Sreenivasa,

do you mean AM62x does not support using PRU to process audio and send to McASP interface as what we( Mr. Song) have impmented on 335x platform?

and the only solution is to use ARM CPU via Linux ASLA?

Hello wu qiang 1,

Thank you for checking.

Could you please help me understand if you are working on this project or similar project.

wu qiang said:

and the only solution is to use ARM CPU via Linux ASLA?

Currently the linux audio is via alsa.

Regards,

Sreenivasa

Hello Sreenivasa,

I am a bit confused here. I thought that wu qiang and team were trying to transmit data from the PRU to the McASP. They do NOT care about whether that data transfer involves a DMA as far as I can tell. On AM335x there was a register location where the PRU could place data, and that data would get sent out through the McASP.

It looks like they should just be able to write to MCASP_XBUFn to send data? e.g., MCASP0_XBUF0?

Regards,

Nick

Hi Mr, Sreenivasa,

yes, Mr. Jieoh Song and I am working on the same project in a team.

we've implemented CPU process audio data into/outof PRU and PRU feed the data to McASP on 3358 platform.

checking why PRU can't feed data to McASP as 3358 can and without underrun.

Hello Sreenivasa

Our 1st project is based on AM3358, that use pru to transfer data to MCASP, not use linux ALSA, not use DMA. It use software loop to feed data to MCASP.

The project backgroud detail is on above, you could see.

Now, we want to use same method on AM62X to develop 2nd project, but some issue.

Regards,

Song

Nick Saulnier said:

I thought that wu qiang and team were trying to transmit data from the PRU to the McASP.

Hi, Nick,

yup, that's our purpose.

Regard

Hello Nick,

Thank you for the inputs.

Regarding the PRU, the AM3358 PRU supports ICSS and the PRUSS on the AM62x does not support ICSS. Dont know if this is a concern. Any thoughts please. We came up with an additional query on enabling ethernet.

As i understand from the design team here McASP on AM62x is supported through PDMA. Could you please provide your thoughts if PDMA could be supported/works without the ICSS capability. 

The important question was on adding additional Ethernet interface using the PRUSS. Customer was looking to enable an additional ethernet using the AM62x PRUSS. This is not supported.

Song/wu qiang, Did we conclude on the need for enabling the ethernet port over PRUSS?

Currently the linux audio is via alsa. Does not seem to be using PRU.

Regards,

Sreenivasa

Hi All, 

I am adding the webex inputs:

I checked with customer, they don't need PRU to support Ethernet.

They just want to transit signal from PRU to McASP, which they have done on AM3358, like the description on the E2E. But the rate of AM62X is much lower than the same process on AM3358, could you please help with this problem?

Thank you for the clarification.

Let me check internally with the device expert.

Regards,

Sreenivasa

Hi Mr. Sreenvivasa,

Kallikuppa Sreenivasa said:

The important question was on adding additional Ethernet interface using the PRUSS.

we DON'T need Ethernet interfacce on PRU.

we want to use PRU to feed data to McASP on both AM62x and AM3358 platform,

BR 

Hello wu qiang,

Thank you for the note.

wu qiang said:

The important question was on adding additional Ethernet interface using the PRUSS.

we DON'T need Ethernet interfacce on PRU.

Thank you for clarifying.

wu qiang said:

we want to use PRU to feed data to McASP on both AM62x and AM3358 platform,

I guess you have this working on AM335x.

Regards,

Sreenivasa

Kallikuppa Sreenivasa

On AM335x there are two McASP memory regions defined per instance, the data and the cfg:

It looks like the memory regions are associated with accessing the McASP from either the Data port, or the configuration bus:

AM62x does not list the McASP data section in the memory map. However, it clearly still exists according to the McASP TRM chapter.

Additionally, the data port should be usable by a CPU host like PRU, not just a DMA:

Can you help us figure out where the Data port is accessed in memory?

Regards,

Nick

Wu Qiang,

To double check, what McSPI memory addresses in AM335x was your PRU code writing audio data to? Is there any other key information about how you were configuring the McASP from Linux, or writing to it from PRU?

Regards,

Nick

Hello Nick, 

Thank you. 

Let me check on the above.

Since the use case for the ICSS and the SS are different, are there any restriction or firewall ext that may have been put in AM62X.

Any thoughts on this please.

Regards,

Sreenivasa

Hello Sreenivasa

I can't find the "Data port" on AM62X. That is the trouble.

Regards,

Song

Hello Nick

The memory addresses  we used is "MCASPX data port" register on AM3358.

On AM62X,  I use 

"echo on > /sys/devices/platform/bus@f0000/2b00000.mcasp/power/control"  to power on MCASP,

init and config the MCASP by pru code.

Regards,

Song

Hello Song,

Thank you for the inputs. 

I guess you would have had a chance to read through the below section in the TRM.

12.1.1.4.10 MCASP Data Transmission and Reception

SPRUIV7A – MAY 2022 – REVISED NOVEMBER 2022

Regards,

Sreenivasa

Hello Sreenivasa

Yes, I have readed it.

Regards,

Song

Hello Song,

Thank you. 

Let me check internally with the expert for any additional suggestions.

Regards,

Sreenivasa

Hello Jieoh,

Please provide the exact address value or values on AM335x you used when writing to "MCASPX data port".

Regards,

Nick

Hello Jieoh,

After talking with PaulM, he would expect that you could transfer data from the PRU to the McASP by using the CFG address space, and writing to the MCASP0_XBUF register(s). No need to write to the McASP DMA address space.

For more information, please reference the Technical Reference Manual chapters. The section Sreenivasa pointed to, "MCASP Data Transmission and Reception", is a good section. You want to make sure you are following the information suggested in the sub-sections, like "Using a Device CPU for MCASP Servicing".

Paul would expect the same process should work with AM335x and AM62x. Since your AM335x code already works, I would suggest first trying to get it the XBUF writes working on AM335x config address space, and then porting the code to AM62x.

I'll grab the thread back from Sreenivasa now in case you have followup PRU programming questions.

Regards,

Nick

Hello Nick

I used the "MCASP0 Data" register, that is the data port register. As follow:

Regards,

Song

Hello Nick

I saw the words "Accessing XBUF0 registers not implemented on a specific device may cause improper device operation.", is it can be accessed by code?

Regards,

Song

Hello Song,

To clarify, "McASP0 Data" is an entire memory region, not a specific register. I am checking with the HW guy to see on AM335x, which register was associated with a 0x0 offset in the McASP0 Data memory region.

The AM62x TRM chapters are written with generic documentation for the different peripherals (i.e., the AM62x McASP and the AM62A McASP chapters should have the exact same text, instead of writing a custom McASP chapter for each new part number). That means that the peripheral chapters do not have device-specific information. The AM62x TRM chapter Module Integration > Audio > MCASP should have the specific information about how the McASP peripheral was integrated into the AM62x.

That TRM section does not mention the XBUF registers, so I assume all documented XBUF registers exist. I am also verifying that information with the HW owner.

Feel free to ping the thread if I do not have another response within a couple of business days.

Regards,

Nick

Hello Nick,

Is there any new message?

Regards,

Song

Hello Song,

Thanks for your patience. After talking with the HW owner, he would expect the first address of the AM335x Data / AM62x DMA memory space to be associated with the first serializer / XBUF reg that is enabled, the next address to be the next serializer / XBUF register that is enabled, etc.

Debugging what is going on

It does not look like you answered Paul's question above, so I will re-ask it here: When bit clock is set to 3.072MHz, do you see any activity on the McASP serializer?

1) If you see the expected audio data with a 192Khz output, AND you do not see all the expected audio data with a 3MHz output, but you are seeing SOME data on the pins that matches the data the PRU is sending, then that tells us that the data is getting transferred, but not getting transferred quickly enough for the 3MHz usecase.

2) If you see the expected audio data with a 192 KHz output, and NO DATA whatsoever on the pins with the 3MHz output, then something else might be going on.

Other things to try 

As discussed in this prior response, you could also write data using the CFG port instead of the DATA port: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1253216/processor-sdk-am62x-am6234atcghaalw/4766177#4766177

Please make sure that the XBUSEL bit is appropriately set, as per note

To perform internal transfers through the DATA port, clear the XBUSEL/RBUSEL bit to 0b0 in
the MCASP_XFMT/MCASP_RFMT register, respectively. Failure to do so may result in software
malfunction.

Regardless of which port you are using to access, you could try watching for a "device ready" signal to write the next PRU signal, as discussed in the TRM sections "Data Ready Status and Event/Interrupt Generation" > "Transmit Data Ready"

Regards,

Nick