when I alter the frequency of the flexi tonegenerator during running in PPS on TAS3204-EVM two or three times no tone is produced any more.
Also I will have to alter the tone generator frequency by MCU via I2C. How does a frequency value lets say 0.008333 2(f0/fs) fit into the four byte hex coeficient?
Thanks for any response.
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.
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.
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.
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.
I attached the modified .xml files, I may have made a typo here and there, but the idea is there (they're not tested). When you compare the modified files with the original ones, you will have some idea how it works.
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?
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.
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.
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.
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.
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.
please see the screen shot attached:
the alpha value is right but the beta changes everytime I read the I2C address.
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.