Our latest full-stack Bluetooth Low Energy module, the BLE121LR, uses the same SDK, source files, hardware definition files, and build tools as our previous two module (BLE112 and BLE113), but there are some differences between the BLE121LR and the other modules which must be considered during the design phase. The main cause of these differences is that the BLE121LR incorporates a power amplifier (PA) and low-noise amplifier (LNA) to allow improved range compared to the other modules. If you are moving a design from the BLE112 to the BLE121LR, there are a few additional considerations which are similar to those necessary when moving from a BLE112 to a BLE113.
One VERY CRITICAL point is to ensure that you follow the PCB layout recommendations shown in the BLE121LR datasheet. The RF design of this module requires more attention to the keepout area and specifically a larger solid ground plane for optimal RF performance. See the BLE121LR datasheet for more detail.
The main differences between the modules that impact the firmware development process are these:
Most everything else is the same as far as the SDK is concerned at a high level, but the internals of the stack are modified to make take advantage of these differences. The hardware footprint of the modules are also different, but this much is shown in each module's datasheet.
From a hardware perspective, the BLE112's two USB data pins (USB+ and USB-) have been swapped out for I2C pins (SDA and SCL). This means that the P1_6 and P1_7 pins required for the BLE112's software I2C should not be used for that purpose, but instead you should use the dedicated hardware I2C pins. No changes to the BGScript or BGAPI commands are necessary to take advantage of this difference; it will be handled automatically.
Finally, the module's P1_0 and P1_1 pins must not be used by your application (and they are not externally available on the module), or else the radio will not operate correctly. If you have moved a previously working project to the BLE121LR and find that the RF range is essentially zero, this is usually the reason. Make sure that P1_7 is also assigned to regulator control in the PMUX setting as described above.
The main thing you have to change in your BLE project's main definition file (usually project.xml or project.bgproj) is to add or modify the device type line. For projects meant for the BLE121LR, this file should include the following line:
<device type="ble121lr-m256k" />
Without this, it will not flash properly onto a BLE121LR. In many of our example projects, you will see multiple project definition files, one of which includes "121lr" somewhere in the name. This makes it easy to reuse the same set of XML files and BGScript files so that the same project can be easily flashed onto either kind of module.
The TX power range for a BLE121LR is 0-9, instead of 0-15 on the BLE112 or 0-14 on a BLE113. This has to do with the actual division of power settings that are available given the unique RF design of the 121LR. If you use a value greater than 9 on a BLE121LR, the stack will behave exactly the same as if you had used 9, so there is no risk of damage or reduce power or anything of that nature.
The other change is to make sure that your hardware.xml definition and (if applicable) your BGScript source file do not enable or reference the USB port or endpoint, as this will not work.
Finally, since P1_7 is reserved for DC/DC converter control (this pin is now in fact labeled "DCDC" in the datasheet), ensure that you do not need or attempt to use the USART1/Alt2 peripheral arrangement. These "alternate" configurations require the use of P1_7, which is not allowed.