Issues running modified Audio SOC example on L138

pradhyum

Hello:

Customer is having the following issue with Audio SOC example. Can someone help out?.

Thanks,

Pradhyum

I'm modifying the audio soc example to work with McBSP and having good luck so far, but for this one issue. I have changed the structure a bit so that I'm dealing with one DSP thread that has a message queue and the linux app which also has a message queue. I am using the same setup as the audio soc example where I have my own message struct that I am passing around (it has the normal header and then a u16* to my data buffer). I allocate the data buffer via a pool on the ARM side:

#define POOL_ID 0

#define BUFSIZE 8192

Uint16* buffer;

Uint16* dsp_addr;

status = POOL_alloc (POOL_ID, (Pvoid*)&buffer, BUFSIZE);

This returns no errors (i.e. DSP_FAILED(status) is false) and then I use POOL_translateAddr to turn that address into a DSP address:

status = POOL_translateAddr (POOL_ID, &dsp_addr, AddrType_Dsp, buffer, AddrType_Usr);

Again, no error. Then I create/locate message queues which seems to be working fine. I then use buffer on the ARM side to store the values 0 to BUFSIZE-1 into buffer. I use MSGQ_alloc to get a MSGQ_Msg* to pass around:

status = MSGQ_alloc (POOL_ID, APPMSGSIZE, (MSGQ_Msg*)msg);

Again no errors. After writing the incrementing test values to buffer, I assign msg->buffer = dsp_addr; and use MSGQ_put to send the address to the DSP. The DSP-side app gets the message and is supposed to walk the buffer and increment the values by 1. It then sends it back to the ARM side. I'm sure that the messages are going back and forth fine (i.e. I can set the message ID and check it, etc. as I would expect, and I've used this to verify that the DSP code is walking the path that increments the buffer). However, the DSP side doesn't appear to change the values in the memory buffer. I always read back the original values on the ARM side. I have played with POOL_writeback on the ARM side (after writing the test values) and BCACHE_inv on the DSP side (both before modifying the test values and after) and I haven't gotten this to work.

I can send more code if you want ... any thoughts?

over 14 years ago

0 Arnie Reynoso over 14 years ago

TI__Expert 6860 points

The issue here seem to be that the data written by the DSP into the MSGQ msg has not been written back to the actual memory and is still in the DSP cache.

The general rule when using the Audio SOC example case is that when a MSGQ msg is received on the DSP, you must first invalidate the cache (calling BCACHE_inv) on the buffer received. Subsequently if you write into a MSGQ msg buffer you must writeback (call BCACHE_wb()) the data from the cache before sending the MSGQ msg buffer back to the ARM.

0 ToddMullanix over 14 years ago in reply to Arnie Reynoso

TI__Guru* 96960 points

Just to add a little to Arnie's comments...

MSGQ takes care of the cache coherency on the message. MSGQ has no idea of the actual contents of the message. So if there is a pointer to a buffer in the message (your case), you must perform the cache coherency calls yourself. As always with cache coherency, make sure the buffer is aligned on a cache line and it's length is a multiple of a cache line.

For example (in pseudo-code), assuming msg->buffer is a pointer to a block of memory

Sending a message:

msg->buffer = some block of memory
BCACHE_wb(msg->buffer, SIZEOFBLOCK);
MSGQ_put(msg)

Receiving a message:

MSGQ_get(&msg)
BCACHE_inv(msg->buffer, SIZEOFBLOCK);
you can now act on the msg->buffer's contents

Processors

Processors forum

Issues running modified Audio SOC example on L138