Generate an RF test pattern in "production" firmware.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
SeFe_4295646
Level 3
Level 3
First like received First like given

I'm looking for a way to generate a fixed frequency (channel center is ok) CW rf emission during production test for our product using the CYW43907.  It would take too long to have to use the wltool, and to re-flash the UUT after functional test, so I want to put an RF test feature in our production firmware.  Its fine if I have to stop threads/services and/or reset the device after test.  For our other radios, our functional test fixture includes a spectrum analyzer and we generate an RF test signal to verify RF matching components are properly placed/soldered during production (the low values, small parts that ICT has trouble detecting accurately).  The test.mfgtest requires the wltool, and would require re-flashing after testing; both make this very unattractive for our purposes.

Any help finding an easy way to deploy an RF test signal would be helpful - our test mode would require physical access in our test fixture that would prevent the device from entering test mode in the field.

Thanks in advance

Sean

0 Likes
16 Replies
Zhengbao_Zhang
Moderator
Moderator
Moderator
250 sign-ins First comment on KBA 10 questions asked

Hello:

    From description,  I think you didn't want to use PC to input UART commands in RF test station, is it right ?

and in the whole process programming is in the first station, but didn't change it until the test is passed.

Normally ,  it should be programmed with MFG image before the hardware tests,   then the board will be programmed with normal image if all hardware tests pass , after that it will be tested in application layer like checking if signal is in a good behavior, if wifi can connect with the test AP. 

   and one more question:

For our other radios, our functional test fixture includes a spectrum analyzer and we generate an RF test signal to verify RF matching components are properly placed/soldered during production (the low values, small parts that ICT has trouble detecting accurately .

    Question:  Only need one fixed RF test command list for RF test , doesn't need a change for different 11b, 11g, 11n test in the process.   if you want to embed different test commands into application, that will be more complicated than just one.

Our devices are programmed in bulk as raw bare devices (not soldered to anything) prior to placing on the PCBa.  The time to program (or reprogram) the product during production test adds too much cost to the process, hence the pre-programming of the flash.  Granted this assembly uses an external flash, but regardless we need a solution that does not require re-flashing after PCB assembly.

We *could* get UART access to the Cypress, but that is not the preferred solution - we have access to another processor on the PCB - and the two processors share information using a proprietary protocol over UART between the devices.  It is our intention to have a factory test command be sent over that interface from the other processor - already designed to communicate with our production test fixture.

We're re-using with minimum modifications existing production test fixtures in our factory location from our previous generation product - which used a different WiFi solution, hence much of the production test flow is already in place.

We've explored connecting to a test AP - but that is both time consuming and lacks resolution - i.e. would work even with an open antenna in close proximity.

What we need is a fixed output that can be analyzed by an RF analyzer which is already part of the test fixture.  Preferably a continuous wave (not modulated) signal; but could live with a continuous modulated pattern, although that does complicate the test fixture code that needs to be developed.  We may test 1 or 2 frequencies per band (i.e. a low and high in each 2.4 and 5 GHz bands) one at a time  That is - signal test signal 1 - record data from analyzer, switch to test signal 2, record data .... stop signal and analyze result.  We do not need to change modes, just a 2 or 4 frequencies (TBD), one at a time.  Again, the purpose here is to provide test coverage for common faults of the RF components we can't cover with an ICT test fixture; we do not need to test the modulation methods in production test - that is only required at validation test and for that we're able to use the test.mfg-test and PC tools.

0 Likes

Hello:

  So your concerns and  actual situations are:

1.  In production stage we can't use UART because it is shared with another MCU.

2.  Need a continuous wave but not modulated, is that carrier wave ?

3.  You will erase the board adn re-proramme it in validation stage, no matter what is the content inside ?

4.  need to test 2 or 3 channel every band.  Here is a question, How will you trigger the channel switch ?  I think a push key may be needed.

5.  The flow lacks the test command lists because final RF test wave is not fixed.

6.  and haven't added test command into application yet.

thanks.

To your points above....

1.  In production stage we can't use UART because it is shared with another MCU.

There are multiple UARTS, and we have one routed to test pins - BUT not a preferred solution as the production test fixture currently does not have a UART port available, could be added, but it is currently deisgned to talk through another MCU which would forward specific instructions to the Cypress UART.

2.  Need a continuous wave but not modulated, is that carrier wave ?

Yes carrier wave output is preferred.

3.  You will erase the board adn re-proramme it in validation stage, no matter what is the content inside ?

Not sure I understand.  Validation (DVT, FCC compliance testing, etc) is not in scope here.  We do not intend to erase / reprogram during or after production test - i.e. production application should support factory test fixture requirements.

4.  need to test 2 or 3 channel every band.  Here is a question, How will you trigger the channel switch ?  I think a push key may be needed.

1 or 2 channels each band.  Would be messages from other processor over our UART channel to start test, switch channels, stop test.

5.  The flow lacks the test command lists because final RF test wave is not fixed.

I have no idea what you mean here. 

6.  and haven't added test command into application yet.

Am trying to add these test commands and functions to our application code now.

0 Likes

Sure, I can understand the requests,  so we can discuss more after command and functions are ready in your application code.

0 Likes

Our application code is as complete as possible - to the point of stubbed out functions to start / stop the test pattern.  Lets discuss ASAP.

0 Likes

hello:

we have scripts in the wiced release , the directory is 43xxx_Wi-Fi\libraries\test\wl_tool\scripts .

For example, the tx_carrier_start.bat :

..\wl%target% --serial %comport% down

..\wl%target% --serial %comport% country ALL

..\wl%target% --serial %comport% band b

..\wl%target% --serial %comport% mpc 0

..\wl%target% --serial %comport% up

..\wl%target% --serial %comport% out

..\wl%target% --serial %comport% fqacurcy 6

since you are planning to add RF pattern into your code , we only need to input all these commands by API .

you can use the api:

     wwd_wifi_set_iovar_value("phy_watchdog",0,) ;

   or use to set the command which doesn't include a value:

    wwd_wifi_set_ioctl_void();

I think what you need to do is :

1. bring up an interface like STA

2.  try these commands firstly to see if it can run well in your application.

3.  Use RF instrument to see if signal is outputted .

4.  according the script to add more different test patterns.

0 Likes

OK, that got me close enough to do some more digging.  Using wwd_wifi_set_iovar_value did not work for band, nor fqacurcy, but did for mpc.  I've solved the band selection.  I cannot get the fqacurcy command nor any replacement to work, I've searched through the wl.exe also, which got me to this:

        result = wwd_wifi_set_ioctl_void( WLC_DOWN, WWD_STA_INTERFACE);          // down

        WPRINT_APP_INFO(("down %d\n",result));

        result = wwd_wifi_set_ioctl_value(WLC_SET_BAND,WLC_BAND_2G,WWD_STA_INTERFACE); // band b

        WPRINT_APP_INFO(("band b %d\n",result));

        result = wwd_wifi_set_iovar_value("mpc",0,WWD_STA_INTERFACE);            // mpc 0

        WPRINT_APP_INFO(("mpc 0 %d\n",result));

        result = wwd_wifi_set_ioctl_void( WLC_UP, WWD_STA_INTERFACE);            // up

        WPRINT_APP_INFO(("up %d\n",result));

        result = wwd_wifi_set_ioctl_void( WLC_OUT, WWD_STA_INTERFACE);           // out

        WPRINT_APP_INFO(("out %d\n",result));

        result = wwd_wifi_set_ioctl_value(WLC_FREQ_ACCURACY,channel,WWD_STA_INTERFACE); // fqacurcy (chanel)

        WPRINT_APP_INFO(("fqacuracy %d %d\n",channel,result));

results are 0 (success) for all except the last.  which gives me 2023 (unsupported).
As mentioned above, this also fails (same error code)        result = wwd_wifi_set_iovar_value("fqacurcy",channel,WWD_STA_INTERFACE);

0 Likes

the variable channel in the above was tested with 1, 3, and 6 as values for channel.

0 Likes

I think it is a MFG firmware issue,  you need to replace the MFG firmware to the normal with same name.

like in the directory: 43xxx_Wi-Fi\resources\firmware\43909

43909B0.bin

43909B0.clm_blob

you need to change the mfg firmware to the above normal firmware, then you can run application with MFG firmware for your RF tests.

SeFe_4295646
Level 3
Level 3
First like received First like given

Ok - doing that, or a far simpler method appears to be to put this line in the application .mk file

WIFI_FIRMWARE_BIN := firmware/$(WLAN_CHIP)/$(WLAN_CHIP)$(WLAN_CHIP_REVISION)-mfgtest.bin

does let me run the test sequence from the API calls above.

However, that firmware does not support normal operation.

Would it be possible to get a firmware that does both?

0 Likes

Yes, that is a better way to use mfg firmware.   For the firmware we have run the two firmware for a very long time. It is hard to say whether we can support normal and mfg function with one firmware, you know it needs a lot of tests and verification before final confirm..

0 Likes
SeFe_4295646
Level 3
Level 3
First like received First like given

Ok - so we can't create a CW output with production firmware.  If I wanted to create a packet stream as a test pattern, the analisys will be more complex, but might be doable for our needs.  I've been modifying my approach to do that?

I've figured out API calls for all the commands in the 802.11n test pattern sequence, except the last one:

"pkteng_start 00:90:4c:aa:bb:cc tx 40 1000 0"

I'm going out on a limb and guessing that there is no packet engine (pkteng) in production wifi firmware.  Can I create one?  Can you direct me to API calls to generate a continuous pakcet stream assuming all the previous configurations in the mfg_test 802.11n sequence are already in place?  At minimum I'd need to be able to call something to send a packet, and know when to start the next one even if I have to build packet myself, I should be able to do this in a loop until commanded to stop.  Again this will only happen in a test fixture at the factory.

0 Likes

Hello:

   Since you are using 43907 for your product, I find  a new way for your RF pattern test , you can compile your image with command_console inside it , also include wl tool for test,  after that , we can add test command like below list :

console_parse_cmd("wl rate");
   console_parse_cmd("wl ver");
   console_parse_cmd("wl band");

  I have tested it sucessfully , you can copy all mk info from console.mk to your makefiles.

Then, you can use wl tool in your application as you wanted,  the weakness is your product image will look lager than before ..

0 Likes
SeFe_4295646
Level 3
Level 3
First like received First like given

Ok, I can get much of that to work, but are you able to call:

console_parse_cmd("wl fqacurcy 1");

and get that to work?

It appears I'm back to that not being supported in the wifi firmware that supports normal operation, or have I missed some step that allows both firmware's to co-exist?

0 Likes

hello:

  I think it should be executed with a MFG firmware .

then it should be operated as a fixed sequence like:

wl down

wl country ALL

wl band b

wl mpc 0

wl up

  wl out

  wl fqacurcy 6

0 Likes