The purpose of the PTI (Packet Trace Interface) is to support analyzing the packets sent / received by the firmware using the built-in network analyzer of Simplicity Studio. This interface uses three signals: PTI Clock, PTI Data and PTI Sync (often referred as PTI Frame).
Most of the radio boards' PB13 pin is connected to the board controller's PTI Sync input. If a customer firmware uses PB13 as an arbitrary output and there is a high frequency signal on this pin (for example a few hundred kHz) the board controller cannot tolerate it and stops communicating on USB interface. As a result, if the radio board with that kind of firmware is inserted into the WSTK, it is not possible to erase the firmware since the tools (Simplicity Studio, Simplicity Commander) will be unable to connect to the WSTK.
If it happened that a firmware renders the WSTK unusable, follow the guide below:
There is one side effect of this method: the PTI (and thus Network Analyzer) will not work.
Below listed are the Tx Gaussian symbol shaping coefficient values for various BT products. These values go to API properties MODEM_TX_FILTER_COEFF8 to 0. These values can be applied to all Si446x based Tx/TRx ICs on both revB1B and revC2A.
Note that if BT >= 0.65 the deviation value must also be doubled in API property pair MODEM_FREQ_DEV.
BT Fd*2 coeff8 coeff0
0.25 0 3A 39 36 31 2B 25 1E 18 12
0.27 0 3C 3B 38 32 2B 24 1D 16 10
0.30 0 3F 3D 39 32 2A 21 19 12 0C
0.35 0 48 46 3F 35 29 1E 15 0D 08
0.40 0 52 4F 45 37 28 1A 10 09 04
0.45 0 5D 57 49 37 25 16 0C 05 02
0.50 0 67 60 4D 36 21 11 08 03 01
0.55 0 71 68 50 34 1C 0D 05 02 00
0.60 0 7B 6F 52 31 18 0A 03 01 00
0.65 1 43 3B 29 17 0A 03 01 00 00
0.70 1 48 3F 29 14 08 02 00 00 00
0.75 1 4D 42 29 12 06 01 00 00 00
0.80 1 52 45 28 10 04 01 00 00 00
0.85 1 57 47 26 0E 03 01 00 00 00
0.90 1 5C 49 25 0C 02 00 00 00 00
0.95 1 62 4C 23 0A 02 00 00 00 00
1.00 1 67 4D 21 08 01 00 00 00 00
Si4x6x radios offer High-performance and Low-power operation modes. Selecting one over the other affects 3 RX mode parameters: RX current, RX Sensitivity, Adjacent Channel Selectivity. The following table summarizes the actual differences between these 2 modes:
|High-performance mode||Low-power mode|
|RX Current||~3mA higher||~3mA lower|
|RX Sensitivity||~2dB better||~2dB worse|
|~2dB better||~2dB worse|
The desired performance mode can be selected in GLOBAL_CONFIG API property:
- GLOBAL_CONFIG = 0 --> High-performance mode
- GLOBAL_CONFIG = 1 --> Low-power mode
The following KBA was written using an EFR32MG14 radio board (BRD4169A) under Flex SDK 2.5.1 (RAIL 2.6), but the process should be the same on all EFRs and all Flex SDKs since version 2.0.
The main goal to share information about what CTune means, and how can it be configured to reach optimal radio link quality. In most cases, this is done through the RAIL APIs. A good starting point is the RAILTEST Application which implements CLI commands to do the calibration. This KBA focuses only to HFXO calibration but the LFXO has its own capacitor bank.
EFR32 devices are equipped with a configurable internal capacitor bank to load external crystals for proper operation and frequency calibration. We usually call the configuration value of this capacitor bank CTune.
This CTUNE value is applied during the startup phase of the HFXO. The following equation gives the relation between the programmed and the real value of the capacitance:
Ctune = Cpar + CTUNE<8:0> * 40fF,
as the reference manual states (EFR32MG14 reference manual), where Cpar means parasitic capacitance, which depends on the board type, the layout, the temperature and the type of the crystal. The internal capacitor size inversely proportional to the frequency, therefore the higher capacitor value lead to lower HFXO frequency.
The CTune is responsible for the quality of the radio link, because it sets up HFXO clock properly which is used for the radio clock as well. This radio clock is used by the synthesizer. Thus incorrect setting may lead to broke a radio link between two devices.
The CTune calibration value can be stored in non-volatile memory of the device. All Silicon Labs modules and radio boards are factory calibrated, and the CTune value is stored on the device information page, while other Silicon Labs radio boards equipped with an external EEPROM which holds the CTune value. For further information, see this KBA for Bluetooth or this KBA for RAIL and Connect.
However, on custom boards, the calibration should be always performed. It is a preferable way to measure 10-20 board's HFXO frequency per design, and get the average CTune value which can be used for all devices. In this way a good enough calibration value can be taken. Obviously the optimal calibration can be done for each board, but it takes more longer.
This KBA focuses on this calibration process. Once an optimal CTune value has been found for a given circumstance (given board, layout, temperature etc.), the above KBAs can be used to store it on the device.
The easiest way to set CTune value is to call the
RAIL_SetTune() API. The first argument is the RAIL handle (similarly to most RAIL APIs) and the second is the CTune calibration value to use. Though the latter is a
uint_32 type variable, the API is only using the lower 9 bits (masking with 0x1FF), therefore the valid range for that argument is between 0 and 511. RAIL API does not reject higher values, it's the application's responsibility to prevent misconfiguration.
Issue the following commands on a device programmed with RAILTEST in order after reset for the initialization of the calibration:
> rx 0 > setPower 1 > getCTune > setCTune <0x[hex-value] or [decimal value]> > setTxTone 1
RAILTEST starts the device in rx mode, therefore first the device should switch to IDLE mode, because the PA Power can be changed in
RAIL_RF_STATE_IDLE state only. The purpose of this step will be explained in the next section. The actual CTunevariable can be read with
getCTune command. Then write over this value, which can be done with the
setCTune command. After the configuration the
setTxTone 1 command sets the radio to transmit mode with CW signal.
For changing CTune value issue these commands:
> setTxTone 0 > rx 0 > setCTune <0x[hex-value] or [decimal value]> > setTxTone 1
This procedure is very similar to the initialization process. After disabling the transmit mode and calling
rx 0 the radio is able to get a new CTune value.
CMU_HFXOAutostartEnable() as its name states enables auto starting after a Wake-up from EM2/3. If this API is called with either of the last two argument as
true, it prevents the restart of the HFXO and therefore the change of the CTune value. Note that this feature is enabled by default in the Bluetooth stack.
The measurements had been done with a spectrum analyzer, and with an EFR32MG14 Radio Board (BRD4169A) at 868 MHz. It's recommended to do these calibrations with conducted RF connection. It is also recommended to use the low power output during the measurements (configured by
RAIL_SetTxPower() API) to avoid calibration drift which is caused by the increased temperature, caused by the current consumption of the PA.
The optimal test signal is the CW signal which can be transmitted by calling
RAIL_SetTxStream() API. For better resolution smaller Video Bandwidth was selected.
The first capture shows the achievable resolution with low capacitance: The frequency is measured with CTune values 0 to 9.
The average frequency step is 1540 Hz in this frequency region.
The resolution is not linear on the full frequency range. That has been showed with the following picture:
Each spike is measured with CTune increased by 50 from 0 to 250.
After learning the general configuration possibilities it's possible to find the optimal CTune value with an iterative approach. Set the marker to the desired frequency (in this case it is 868 MHz) and change the CTune value until the radio transmits at this frequency. In our case the optimal value was
317 (The factory calibration was
322). The third picture shows the the optimal calibration with the neighbor values.
With a higher transmission power the optimal value is harder to find, due to chip is warming up affecting the crystal's resonance frequency. The above picture captured with "max hold" mode during 2 minutes when higher transmission power was applied. It is shown that the frequency drift was 0.5 KHz, which could result inaccurate calibration.
1. Access CTUNE token with Simplicity Commander
Wireless Gecko (EFR32™) portfolio devices support configuring the crystal oscillator load capacitance in software. The crystal oscillator load capacitor tuning (CTUNE) values are tuned during the production test of both Wireless Gecko-based modules and Silicon Labs Wireless Starter Kit (WSTK) radio boards. For Silabs modules, the optimal value for each device is written to the Device Information (DI) page in flash. For Silabs radio boards, the optimal value for each board is written to an EEPROM that is inaccessible to the software running on the target device, but readable by Simplicity Commander.
The CTUNE commands support reading out the stored CTUNE values from these locations, and writing and reading the CTUNE manufacturing token.
How to issue these commands provided by Simplicity Commander to access the CTUNE token?
Firstly, open Command Prompt of Windows (open “Search Windows” at the bottom left of the windows and type “cmd” to search it).
Secondly, move to the installation directory which includes the Simplicity Commander, e.g., in my computer, the path is “C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\commander”.
Thirdly, issue the get command below to get the CTUNE value, e.g., the device I used is EFR32MG12P433F1024GL125 and the serial number is 440033733.
We can see the values from DI (device information) page, EEPROM on the board and MFG token. Since the DI page doesn’t include the CTUNE value, the value is displayed as “Not set”.
Additionally, we can also issue the set command below to set a new value for CTUNE token in the USER DATA page, e.g., the device I used is EFR32MG12P433F1024GL125 and the serial number is 440033733.
See more details about these commands in document UG162: simplicity-commander-reference-guide.
Silicon Labs recommends that User Data and Lock Bits page tokens be written using Simplicity Commander at the same time as programming the main flash. Simplicity Commander also allows for patching and reprogramming the manufacturing blocks as many times as necessary. For the User Data and Lock Bits page tokens, the relevant IC’s Reference Manual or Data Sheet describe the location of each manufacturing token as an offset to the starting address of the relevant block. We can also see document AN961: custom-nodes-efr32 to learn more about this.
2. Access CTUNE token in Connect example
Connect automatically sets the CTUNE from the manufacturing token during initialization.
Some situations may require that a manufacturing token be programmed at runtime from code running on the chip itself. At the proprietary side, in the Connect stack the manufacturing token module of the HAL provides a token API to write the manufacturing tokens. However, this API only writes manufacturing tokens that are in a completely erased state. If a manufacturing token must be reprogrammed, you must use an external utility.
We can use the functions halCommonGetMfgToken()and halCommonSetMfgToken() to access the CTUNE tokens.
See chapter 3 of AN1154-token-for-non-volatile-storage and chapter 3 of AN961-cutomer-nodes-efr32 for more details.
3. Access tokens in Rail example
Rail doesn’t provide the relevant functions to access the manufacturing tokens in User Data page. To get and set the token value in User Data Page, we can use the functions of MSC.
We can use function HalMfgToken_GetTokenValueFromUserPage() below to get the value from User Data page and the function HalMfgToken_SetTokenValueToUserPage() below to set the value into the tokens in User Data page. Note that before writing the manufacturing tokens should be in a completely erased state.
For implement of the functions, see the attached c/h files. When we use the two functions, we should include hal_ctune.h in source code file. For the tune of crystal we can use these functions to get the CTUNE token value from User Data page, and then write it to the CMU->HFXOSTEADYSTATECTRL register, so it can make the tune of crystal effect. Before writing, make sure that the radio state is idle. See the chapter 188.8.131.52 of the document efr32_reference_manual for details about HFXO configuration.
In the test code, we erase the entire page at first, and then write the value at the address offset 0x0100 in User Data page, where the CTUNE value should be stored.
//Test code below is for setting and getting the CTUNE value in the User Data page uint16_t ctuneValueIn= 332, ctuneValueOut = 0; MSC_ErasePage((uint32_t*)USERDATA_BASE); HalMfgToken_SetTokenValueToUserPage(0x0100, (uint8_t*)&ctuneValueIn, 2); HalMfgToken_GetTokenValueFromUserPage(0x0100, (uint8_t*)&ctuneValueOut, 2); //before setting ctune, remove the radio from rx and tx states RAIL_Idle(railHandle, RAIL_IDLE, true); RAIL_SetTune(railHandle, (uint32_t)ctuneValueOut);
4. Access CTUNE with the Railtest example
The Railtest example provides a way to access the CTUNE control registers. The command setCtune can be used to write the value of CTUNE to the CMU->HFXOSTEADYSTATECTRL register. Note that when we intend to set the value of CTUNE, we should make the radio state be idle with command “rx 0”.
The command getCtune allows us to get the value of CTUNE from the CMU->HFXOSTEADYSTATECTRL register.
With Railtest example, we can also use command getmemw to get CTUNE token value stored in the User Data page. The address of CTUNE token is 0x0fe00100. Note that the only 2 low bytes of the word are valid, because it is limited to get a word at a time using this command and the size of CTUNE value is just 2 bytes.