Flexi Tone Generator TAS3204-EVM

Thomas,

I am not sure why that after couple of times of changing the frequency, it's stuck, maybe you need to wait for some time before change again? I've never used this generation myself, so not sure what happened.

But for the I2C message, I checked the code, you need to send the index, not the real frequency to DAP. say the first one on the list the index is 0, the frequency is 25 Hz for 48kHz sampling rate. the second one on the list the value you send would be 0x00000001 and that would be 32Hz for 48kHz sampling rate.

Hope this helps.

Susan

Thomas,

As you described in your email, what you need is a tone generator that would take a parameter at runtime to generate a tone at certain frequency.

To realize that and take into account the resource in TAS3x, I think it's doable, we need to do the following:

1) calculate the initial two samples based on the desired frequency(f0) and sampling rate (fs)and the target amplitude (A):

    y(0) = -1*A*sin(2*pi*f0/fs)

    y(1) = 0;

2) send these two numbers over the I2C, to realize this

     a) you could reuse most of the .asmx code in flextoneGen, I think the modification would be minor if there's any

     b) you need to modify the .xml file when publishing the component, you need to change the I2C interrupt handler from 97 to 2, 97 is the special handler for flextonegen, 2 is the general handler for 48 bit data transfer

Please let me know if there's any further info you need from me.

regards,

Susan

Second thought:  We could just calculate alpha and beta as described in the help file and send them through I2C, then we should be able to reuse the template file from flexToneGen.

Yes Susan, but how do we get an I2C address to write the alpha and beta values to?

Thanks for the effort you take.

Thomas

Thomas,

One I2C message is 20 bytes long, one data value is 6 bytes long, so we don't need another I2C sub address to do this, we can use the one that is used to transfer the index right now to transfer the alpha and beta into DAP.  Ok, I'll modify it and attach it here later today and you compare it with the origianl one and you would know what I am talking about.

Regards,

Susan

Seems I can only attach one at a time.  Here is the other one.

Thank you Susan,

I just can not find the reason for this eror during code generation because I am not familiar with the whole building process:

Error: dsp_init_cmds.objectx(17) : undefined property : 'ToneGeneratorFrequency'

Please see th picture attached as well.

Do you have any idea?

Thomas

Thomas,

It seems to me that you didn't publish the component properly.  Here is my suggestions:

1) read the document regarding how to use the component publisher, you could find it in GDE help content

2) copy everything from FlexToneGen from component cache folder to a separate folder and rename it something else (by renaming the .xml file)

3) copy the two .xml files I sent you and overwrite the existing ones (also remember to rename the .xml

4) open the component publisher and load the .xml with the component name and then resave it, then when you reload it, you should be able to see the .xml with the new name (the name you choose) appears in the file list.

5) Close GDE, publish the component and reopen GDE, see whether the problem still exists.

Regards,

Susan

Susan,

still the same error.

But I did search the files for ToneGeneratorFrequency and found it in the dsp_init_cmds.objectx:

 -- DSP initialization code for %%prop(InstanceId)
-- see 8051 file init.c for details
-- Priority
&H02
-- Handler Function
%%objecthex(%%prop(HandlerFunction1),0,2)
-- DSP Address
## Data address - must be offset by 0x0400
%%objecthex(%%prop(DSPDataBlockStart1),0x0400,2)
-- Delay - N/A
&H00
&H00
-- Length
&H04
-- Data
## The value of an enumerated property is the integer value, which is what is wanted here
%%objecthex(%%prop(ToneGeneratorFrequency),0,4)

Do we have to alter this?

Thanks for any help.

Thomas

Thomas,

I suggest that we get rid of the second line under "recipes" tab in the component publisher and publish the component again,  I think the purpose of .objectx is for the special I2C handler function that was used by the normal fexitongen which we don't use anymore, so you could delete that file from your component file list.

Let's try this first and see how it goes and also always remember to close and reopen GDE when republish the component.

Regards,

Susan

Well Susan, I do get a tone when I run the PF on the EVM. But it is 200 Hz even if it is set to 1kHz alpha = 1.98288... and beta = -0,13052... when I disable and reenable the tonegenerator I sometimes get nothing or a 200Hz square wave or a stange waveform with 12kHz.... Then I did reset the EVM and it goes back to 200Hz. Then I left it enabled and set alpha to 4kHz = 1.7320...and left beta untouched and I get a 4000kHz sinewave! I update beta to -0.5 and it stays fine even if I disable and enable again. Then I try to go back to 1kHz: disable, update alpha and beta, enable no output! disable enable does not change anything: no output. I reset . Back to 200Hz. I leave it enabled and set alpha to anything and then back to 1kHz and I do get a 1khz tone. I update alpha to 200Hz and get a 200Hz squarewave when I then update beta as well the output goes to 0.

It seem to be working somehow but either not stable or with an unpredictable output.

Do you have any idea how we can get this right?

Thanks for any thoughts.

Thomas

Thomas,

There are couple of things we could check:

1) whether the correct value is transferred to DSP via I2C, this we could check with tool->I2C memory tool, after you updated alpha and beta, first read back from the corresponding I2C subaddress to see whether the values are correct.  Then write the correct value using I2C memory tools to see whether the generator still behave the same

2) check whether we have correct value in DAP memory.  There is a .lst file under main_rate48 that you could find the address of the alpha and beta used which you could find in the .asmx file.

3) at the mean time, I'll check the 8051 code to see whether there's anything special about the I2C interrupt handler that was used before, whether there's any scaling involved, which I assumed there isn't.

regards,

Susan

Susan,

please see the screen shot attached:

the alpha value is right but the beta changes everytime I read the I2C address.

Thanks,

Thomas

Thomas,

I check the .asmx code, the memory location for beta is used to hold the temporary output, so it was overwritten for each sample, what you observed is correct.  But at least we got alpha right :)

I also checked 8051 code, there's no scaling for the beta and alpha passed into DAP, so we should be fine.

We could try couple of things:

1) try to debug using a smaller .pfw, just an input and output, see whether that makes any difference. 

2) can you take a look at your resource usuage, how many cycles you already used?  under view-> resources window

3) could you give me your component, so I could run it in the simulator to see how it's doing.  Of course, if you could do it yourself, it would be better, because it would take some time before I could do it.

Regards,

Susan