It seems that the EDMA does not run at all (I am assuming this, by polling
the Transfer Complete bit, which doesn't seem to be set at all).
Basically all that happens is that I get an initial very short "blip"
noise, i am assuming that if the EDMA worked and that I got the source address
wrong or something like that, that I would at least get continuous noise. (But
like I said, I have checked this by using this very code to succesfully output
sine waves).
The only difference in procedure between the working and non working code seems
to be that in the working case, I am explicitly copying each sample into the
output buffer (array), from a different predefined array, and in the non-working
case, I am using the decoding algorithm to deposit the samples into the output
buffer, by specifying the starting address of the buffer and the number of bytes
to deposit.
I have thought about the fact that the decoder sees the buffer as an array of
bytes, while the EDMA outputs 16 bit samples at a time, but in my opinion this
shouldn't cause a problem, because the EDMA only needs a starting address
and gets explicitly programmed to output data of certain size. (Also output of
the decoded buffers work using polling).
Anyway, thanks for the reply and sorry about the long mail!
Any input would be greatly appreciated!
Daniel.
More information on 6711 DSK EDMA problem
Started by ●November 18, 2005
Reply by ●November 18, 20052005-11-18
Daniel,
see comments below.
mikedunn
--- s22088840@s220... wrote:
> It seems that the EDMA does not run at all (I am
> assuming this, by polling the Transfer Complete bit,
> which doesn't seem to be set at all).
>
> Basically all that happens is that I get an initial
> very short "blip" noise, i am assuming that if the
> EDMA worked and that I got the source address wrong
> or something like that, that I would at least get
> continuous noise. (But like I said, I have checked
> this by using this very code to succesfully output
> sine waves).
It would appear that you are only outputting 1 or 2
buffers of data and your code is not getting back to
reload/re-enable them. You can verify this by
doubling or halving the buffer size - I predict that
the blip will be twice [or half] as long. You may be
able to step through your code to see the problem.
Step over the input/output functions and follow the
'control code'.
>
> The only difference in procedure between the working
> and non working code seems to be that in the working
> case, I am explicitly copying each sample into the
> output buffer (array), from a different predefined
> array, and in the non-working case, I am using the
> decoding algorithm to deposit the samples into the
> output buffer, by specifying the starting address of
> the buffer and the number of bytes to deposit.
>
> I have thought about the fact that the decoder sees
> the buffer as an array of bytes, while the EDMA
> outputs 16 bit samples at a time, but in my opinion
> this shouldn't cause a problem, because the EDMA
> only needs a starting address and gets explicitly
> programmed to output data of certain size. (Also
> output of the decoded buffers work using polling).
Two questions enter my mind - the phrase "The only
difference ..." and "output of the decoded buffers
work using polling". I am not sure what you are
'polling' - does the polling have to do with the input
to the decoder or the output from the decoder??
I suggest that you re-evaluate the similarity of your
two scenarios - after all, the problem is 'in the
difference' between them.
>
> Anyway, thanks for the reply and sorry about the
> long mail!
>
> Any input would be greatly appreciated!
>
> Daniel. >
> c6x-unsubscribe@c6x-...
see comments below.
mikedunn
--- s22088840@s220... wrote:
> It seems that the EDMA does not run at all (I am
> assuming this, by polling the Transfer Complete bit,
> which doesn't seem to be set at all).
>
> Basically all that happens is that I get an initial
> very short "blip" noise, i am assuming that if the
> EDMA worked and that I got the source address wrong
> or something like that, that I would at least get
> continuous noise. (But like I said, I have checked
> this by using this very code to succesfully output
> sine waves).
It would appear that you are only outputting 1 or 2
buffers of data and your code is not getting back to
reload/re-enable them. You can verify this by
doubling or halving the buffer size - I predict that
the blip will be twice [or half] as long. You may be
able to step through your code to see the problem.
Step over the input/output functions and follow the
'control code'.
>
> The only difference in procedure between the working
> and non working code seems to be that in the working
> case, I am explicitly copying each sample into the
> output buffer (array), from a different predefined
> array, and in the non-working case, I am using the
> decoding algorithm to deposit the samples into the
> output buffer, by specifying the starting address of
> the buffer and the number of bytes to deposit.
>
> I have thought about the fact that the decoder sees
> the buffer as an array of bytes, while the EDMA
> outputs 16 bit samples at a time, but in my opinion
> this shouldn't cause a problem, because the EDMA
> only needs a starting address and gets explicitly
> programmed to output data of certain size. (Also
> output of the decoded buffers work using polling).
Two questions enter my mind - the phrase "The only
difference ..." and "output of the decoded buffers
work using polling". I am not sure what you are
'polling' - does the polling have to do with the input
to the decoder or the output from the decoder??
I suggest that you re-evaluate the similarity of your
two scenarios - after all, the problem is 'in the
difference' between them.
>
> Anyway, thanks for the reply and sorry about the
> long mail!
>
> Any input would be greatly appreciated!
>
> Daniel. >
> c6x-unsubscribe@c6x-...
Reply by ●November 18, 20052005-11-18
Not sure if this is the cause of the problem, but it may be worth
checking. The AD535 codec uses the LSB of the DAC input to select
between control data and conversion signal data. So, when you write
your 16 bit PCM samples to the EDMA buffer, you have to clear the LSB.
Getting a 1 in the LSB causes the codec to go to secondary
communication mode and will interpret subsequent serial port data as
control data to set control registers. You can find more info in the
AD535 data sheet.
Niro.
--- s22088840@s220... wrote:
> It seems that the EDMA does not run at all (I am assuming this, by
> polling the Transfer Complete bit, which doesn't seem to be set at
> all).
>
> Basically all that happens is that I get an initial very short "blip"
> noise, i am assuming that if the EDMA worked and that I got the
> source address wrong or something like that, that I would at least
> get continuous noise. (But like I said, I have checked this by using
> this very code to succesfully output sine waves).
>
> The only difference in procedure between the working and non working
> code seems to be that in the working case, I am explicitly copying
> each sample into the output buffer (array), from a different
> predefined array, and in the non-working case, I am using the
> decoding algorithm to deposit the samples into the output buffer, by
> specifying the starting address of the buffer and the number of bytes
> to deposit.
>
> I have thought about the fact that the decoder sees the buffer as an
> array of bytes, while the EDMA outputs 16 bit samples at a time, but
> in my opinion this shouldn't cause a problem, because the EDMA only
> needs a starting address and gets explicitly programmed to output
> data of certain size. (Also output of the decoded buffers work using
> polling).
>
> Anyway, thanks for the reply and sorry about the long mail!
>
> Any input would be greatly appreciated!
>
> Daniel.
___________________________________________________________
Yahoo! Model Search 2005 - Find the next catwalk superstars - http://uk.news.yahoo.com/hot/model-search/
