This WIN32 utility is for patching a CC85xx production test image with a startup EHIF Command. This makes it possible to make test images for RF chambers etc. Download the zip and give it a try. The below is a paste of the included readme file:
README file for Generate Automatic Production Test ImageWorks with firmware v1.1.0 rev >= 34708This WIN32 utility is for patching a CC85xx production test image with a startup EHIF Command. This makes it possible to make test images for RF chambers etc.Do as follows:1. Generate a production test hex-image with the PurePath Wireless Configurator. This is done by selecting "Production test" in the "Image type" field in the Flash programming panel. Then hit the "Save generated image to file" button and choose the name and location for your hex.2. Run GenAutoProdTestImage.exe from the command line with the hex as input. GenAutoProdTestImage.exe will modify the hex file. The syntax is as follows:GenAutoProdTestImage.exe -f input.hex 01 02 03 04 05 06 07 08 -f input.hex - filename for input hex file 01 02 03 04 05 06 07 08 - hex data for EHIF command Byte descriptions :b - Delay before command is executed (in ms), Special values : 0xFF - is no command present 0x00 - wait for Audio Device (Codec) to start before issuing command. b - Command type (ref. CC85xx User Guide)b - Command parameter length in bytesb[3-n] - Command parametersExamples :To set a CW with a frequency of 2400MHz and an amplitude of 0dBm: GenAutoProdTestImage.exe -f 8520_CW_2400_0dBm.hex 00 15 03 01 52 00 Command here is RFT_TXTST_CW (0x15),Parameters (0x03),ENABLE (0x01),Channel 2400MHz(0x52),TX_POW 0dBm(0x00)To set an audio tone of 1KHz and 0.5FS output on Left channel: GenAutoProdTestImage.exe -f 8520_Audio_1KHz_0.5FS_Left.hex 00 20 05 00 00 01 00 64 Command here is AT_GEN_TONE (0x20), Parameters (0x05), CHANNEL Left (0x00), RESERVED (0x00), AMP_TONE 0.5FS (0x00), FREQ_TONE 1000Hz (0x64)To set an audio tone of 1KHz and 0.5FS output on Right channel: GenAutoProdTestImage.exe -f 8520_Audio_1KHz_0.5FS_Right.hex 00 20 05 01 00 01 00 64 Command here is AT_GEN_TONE (0x20), Parameters (0x05), CHANNEL Right (0x01), RESERVED (0x00), AMP_TONE 0.5FS (0x00), FREQ_TONE 1000Hz (0x64)To set GIO1 to output with Logic '1' on output : GenAutoProdTestImage.exe -f 8520_GIO1_Test_1.hex 00 23 08 00 00 00 01 00 00 00 01 Command here is IOTST_OUTPUT (0x23), Parameters (0x08), - (0x00), - (0x00), - (0x00), GIO1 (0x01), - (0x00), - (0x00), - (0x00), GIO1 (0x01)To set GIO1 to output with Logic '0' on output : GenAutoProdTestImage.exe -f 8520_GIO1_Test_0.hex 00 23 08 00 00 00 01 00 00 00 00 Command here is IOTST_OUTPUT (0x23), Parameters (0x08), - (0x00), - (0x00), - (0x00), GIO1 (0x01), - (0x00), - (0x00), - (0x00), GIO1 (0x01)
-- Thank you for clicking Verify Answer if this answered your question!
Question about using this tool. We are using host-controlled mode, and the host controls the codec--I have the radio set to not do any codec control. On our production board the radio I2C is not even connected to the codec.
How do I need to modify this process so it will work for us? Do I need to write host code to initialize the radio and the codec and issue the command, but just program the radio flash with a production test image before running it? Do I still use this tool to change the radio image?
Can you give me some more detail on what exactly you are trying to do? And which EHIF command are you interested in running?
There are several commands we would like to be able to run. We'd like to run RFT_TXTST_CW, RFT_TXTST_PN, and RFT_RXTST for RF testing, and maybe AT_GEN_TONE as well.
We'll eventually have a receive module and a transmit module, but initially here we have a microphone slave. I have it configured using the headset configuration (although I'd rather just have a microphone--will that be available soon?), and it's using the INPUT_LEFT channel. I have the audio device set to generic DSP with custom configuration, and I've made all the custom scripts empty. We're controlling with a PIC, and the PIC is initializing the radio and the codec (AIC3254).
I tried the hex-tweaking tool yesterday just on the plain EVM that I have acting as the master/receiver, using the AT_GEN_TONE command, and I must not have gotten all the parameters right because I didn't get any tone out of it. If I connect a headphone I should hear a tone, right? It is configured as the master end of the headset configuration.
RFT_RXTST is not possible to perform with this tool. The reason is that you have to read the RSSI. To do this you have to have a host communicating with the CC85xx over SPI.
The other commands you mention is possible to perform. I had to do some digging in order to make the AT_GEN_TONE work on logical channel "Input left".It turns out that audio channels from master to slave will be enabled by the CHANNEL parameter starting at 0 and increasing. Audio channels from the slave to the master on the other hand will be enabled by the CHANNEL parameter starting at 0a and increasing!
If I understand you correctly you want to perform AT_GEN_TONE on the master to test the functionality of the return channel going from the slave to the master on logical channel "Input left". For a 1kHz tone at the lowest volume (still easily audible) the command should be:
GenAutoProdTestImage.exe -f input.hex 00 20 05 0a 00 01 00 64
-input.hex is your hex file (doesn't have to be named input.hex)
- 00 wait for Audio Device (Codec) to start before issuing command.
- 20 is the hex code for AT_GEN_TONE
- 05 is the number of parameters
- 0a is the CHANNEL parameter
- 00 is reserved bits
- 01 is the lowest amplitude possible
- 00 64 is 1kHz
The user guide will be updated to inform that channels from the slave to the master will start at CHANNEL index 0x0a. Thanks for pointing out that this was missing!
I will also like to inform you that very soon we are releasing a GUI tool for production test of the CC85xx. This is a very powerful tool for doing full automated production tests, and will make GenAutoProdTestImage.exe more or less obsolete. It's also a tool for testing the EHIF interface without having to make an interface with a MCU etc. You simply connect the CC Debugger.
Lastly I can say that microphone application roles most likely will come sometime during Q4.
Thanks for the info. I'm a little hung up on a rather basic question. You said that the tone generated would be "audible". When I use the production test image, will I still set up a second device as the receiver? When I load the production test image, I no longer see the LED that indicates the network status, so I can't tell if the two radios are paired and connected. If I do set up a receiver, does it use a regular image or a production test image? So far I am trying to get it working with just the EVMs as they come out of the box. I have tried using the demo (playback) configuration, as well as our mic/slave arrangement.
The audio test part does not need a receiver. It's meant to be used to test that the HW connection between the CC85xx and the audio device (CODEC etc) works properly for any board. So the device flashed with this tool will output the tone locally on the same board as described in the test parameters.
Hope this helps. Kjetil
--PS. Thank you for clicking Verify Answer if this answered your question!
Thanks again for the help. I did get the AT_GEN_TONE working on my EVM, the other thing I had wrong was I was using the output channel instead of the input channel. (So for the headset microphone, I needed to use channel 0.)
We would like to be able to use the TXTST commands for RF testing (TXTST_CW for example). I have gotten this working on the EVM running in autonomous mode, now I need some guidance on how to make this work on my product with host control. On our board the radio and codec are not connected, the MCU controls the codec and the radio. After loading the production test .hex file on the radio I am resetting the radio and the codec, and I'm not seeing any signal. What else does the MCU code need to do? Are there any settings that need to be initialized on the codec? (We're using the AIC3254.) When I use the GenAutoProdTestImage.exe program I am giving FE as the first argument to maximize the wait time. Actually, my whole command line is: GenAutoProdTestImage.exe -f myfile.hex FE 15 03 01 52 00
Have you selected DSP in the audio device field? You have to do this since you are controlling the audio device with the MCU. Selecting AIC3254 will make CC85xx believe it should be in charge of the audio device and nothing happens since it doesn't get acknowledgements on the I2C bus.
Yes, I have done this. The configuration I'm using is the same one I'm using to run normally, the only change I've made is to select "production test" when saving the image.
I guess my question was more about what the host software needs to do. I modified my normal software to not try and do the usual stream connection. It resets both devices, and on the radio it clear the event flags and looks at the chip info, just to verify that the radio is up and responding. On the codec, it just initializes registers 1,1, 1,2, 1,71, and 1,123 (this is normally enough to get the radios to pair up).
I have a couple followup questions on this. Is there any difference in loading a production test image from loading a normal image? We have written a function to do the flash load over SPI from the host processor. On my EVM it seems as though if I load a production test image, I can't use our function to load another image (the BOOT_RESET and unlock fail), I have to use the CC Debugger to reload the flash. (I have the radio EVM connected to a PIC processor to run in host-controlled mode just like our production board.)
On our real hardware, I have an application image loaded that works, and it appears that I can load production test images, but they're not actually working. I've tried adding commands to my host software such as NVS_GET_DATA and NVS_SET_DATA. On the EVM with the production test image loaded, these give me errors (which I expect). On my real hardware, they seem to work fine (making me suspect perhaps a production test image is not really loaded).
Is there any way to ask the radio what mode it thinks it is in?
I have gotten this working, so I thought I'd post what I've learned so far about the production test mode.
1) The tool in the zip file at the start of this thread is mainly for use if your product runs the radio in autonomous mode. If you run in host-controlled mode, you can just create a production test image with your radio configuration, and your host software should reset the chip and then issue the desired test command directly. There is some sample host code for production test at http://www.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=swra369.
(It may also be possible to create a Configurator configuration for autonomous mode, use the tool to put the command in with a first parameter that is non-zero, and have your host-control software just reset the chip. I think I may have done this accidentally and caused myself a week's confusion.)
Your software can change the running test command, but it must reset the chip first to change the command. Basically you reset and run a command and that's it. You can't do much else without resetting again. (Although GET_STATUS works.)
2) It seems as though the radio operates on its own in production test mode--there is no pairing with another radio. In fact, as the manual indicates, most commands are illegal in production test mode.
3) If you use a test command where you have to specify an audio channel, I believe you need to use an input channel. Our configuration is a microphone slave and a master receiver, we're using the headset configuration since a microphone is not supported yet, and I had to use channel 0 for the mic and channel 10 for the receiver. I got the AT_GEN_TONE to work with this.
4) If you use a test command that produces audio (such as AT_GEN_TONE), you want to use the local microphone output to hear it, not the radio output.
Don't believe everything you read, even what I have just written... :-)
Thanks Susan, this is helpful information.
Thanks for the info!
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.