The Si4010 Key Fob Development users Guide free essay sample

Si4010-Key Fob-DK Si4010 K EY F O B D EVELOPMENT K IT U SER ’ S G UIDE 1. Key Fob Development Platform The Si4010 key fob development platform is a flexible platform for comfortably developing software and testing the whole system using the Silicon Laboratories software development IDE. The platform also allows programming of the NVM on chip. The kit has two versions: one for the 434 MHz band (P/N 4010-DKKF_434) and one for the 868 MHz band (P/N 4010-DKKF_868). 1. 1. Kit Content Table 1. Kit Content Qty Part Number 4010-DKKF_434 2 1 1 1 1 1 1 1 1 1 2 1 2 1 5 1 1 1 1 1 1 1 2 1 4010-UBPB_434 MSC-DKPE1 Si4010-C2-GS 4010-DKPB434-BM 4313-DAPB_LB MSC-PLPB_1 MSC-BA5 MSC-BA4 EC3 MSC-DKCS5 CRD2032 MSC-DKSW1 4010-DKKF_868 4010-UBPB_868 MSC-DKPE1 Si4010-C2-GS 4010-DKPB868-BM 4313-DAPB_HB MSC-PLPB_2 MSC-BA5 MSC-BA4 EC3 MSC-DKCS5 CRD2032 MSC-DKSW1 Description Si4010 Key Fob Development Kit 434 MHz Si4010 key fob demo board 434 MHz w/o IC SOIC/MSOP socketed development board Si4010-C2-GS transmitter IC, SOIC Package Si4010 MSOP key fob development board 434 MHz, SMA Si4313 LED receiver board low band pcb ant Key Fob Plastic Case (translucent grey) Programming interface board Burning adapter board USB Debug Adapter USB Cable CR2032 3 V coin battery Wireless Development Suite disc Si4010 Key Fob Development Kit 868 MHz Si4010 key fob demo board 868 MHz w/o IC SOIC/MSOP socketed development board Si4010-C2-GS transmitter IC, SOIC Package Si4010 MSOP key fob development board 868 MHz, SMA Si4313 LED receiver board high band pcb ant Key Fob Plastic Case (translucent red) Programming interface board Burning adapter board USB Debug Adapter USB Cable CR2032 3 V coin battery Wireless Development Suite disc Rev. We will write a custom essay sample on The Si4010 Key Fob Development users Guide or any similar topic specifically for you Do Not WasteYour Time HIRE WRITER Only 13.90 / page 0. 2 4/11 Copyright  © 2011 by Silicon Laboratories Si4010-Key Fob-DK Si4010-Key Fob-DK 1. 1. 1. Burning Adapter (P/N MSC-BA4) The programming interface board serves as an interface in between the debug adapter and the Socketed Key Fob Development Board or the Development Key Fob. It provides 6. 5 V for NVM programming. The power source is activated by a sliding switch on the board. It is required when the user wants to program the internal NVM memory on the chip. The programming interface board contains an 8-pin header, to which GPIO0 to GPIO5, along with power and ground, are connected from the socketed or battery platform. Therefore, the user can tap to that header to control or monitor the chip pins. 1. 1. 2. Si4010 Socketed Key Fob Development Board (P/N MSC-DKPE1) Socketed (both SOIC and MSOP) key fob board with SMA connector. 2 Rev. 0. 2 Si4010-Key Fob-DK 1. 1. 3. Si4010 MSOP Key Fob Development Board 434 MHz, SMA (P/N 4010-DKPB434-BM) This development board has an unburned soldered Si4010, five push buttons, SMA RF output, battery clip, and battery switch. This board allows running user application from RAM during program development even while board is disconnected and powered by the battery. The SMA output connector allows wired measurements of the RF output signal. 1. 1. 4. Si4313 LED Receiver Board Low Band PCB Ant (P/N 4313-DAPB_LB) Receiver board for link testing with the key fob development board loaded with the rke_demo example program. 1. 1. 5. Programming Interface Board (P/N MSC-BA5) Adapter board for interfacing customer PCB to the debug adapter. Rev. 0. 2 3 Si4010-Key Fob-DK 1. 1. 6. 4010 Key Fob Demo Board 434 MHz without IC (P/N 4010-UBPB_434) 1. 1. 7. Key Fob Plastic Case (translucent grey) (P/N MSC-PLPB_1) 1. 1. 8. Wireless Development Suite Disc (P/N MSC-DKSW1) Wireless Development Suite CD including Si4010 documentation kit, NVM burning application, example projects, and header files. 1. 1. 9. Si4010 sample, SOIC package (P/N Si4010-C2-GS) 1. 1. 10. USB Cable (P/N MSC-DKCS5) Cable to connect EC3 Debug Adapter to PC. 1. 1. 11. EC3 Debug Adapter (P/N EC3) Silicon Labs debugging adapter, used by other Silicon Labs’ MCU products as well, compatible with the development platform. 4 Rev. 0. 2 Si4010-Key Fob-DK 1. 2. Other Boards The following boards are not part of the development kit but can be ordered separately from Silicon Labs. Part Number 4010-DKPB434-BS 4010-DKPB_434 4311-DKEB1 4312-DKEB1 4311-DACB_LB 4312-DACB_LB Description Si4010 SOIC key fob development board 434 MHz, SMA Si4010 key fob development board 434 MHz Si4311 demo board Si4312 demo board Si4311 LCD FSK Receiver 434 MHz Si4312 LCD OOK Receiver 434 MHz 1. 2. 1. Si4010 SOIC Key Fob Development Board 434 MHz, SMA This board is similar to the board described in â€Å"1. 1. 3. Si4010 MSOP Key Fob Development Board 434 MHz, SMA (P/N 4010-DKPB434-BM)† but contains the SOIC package version of the Si4010. 1. 2. 2. Si4010 Key Fob Development Board 434 MHz This is also a key fob development board, but with a pcb antenna instead of the SMA connector. 1. 2. 3. Si4311 Demo Board and Si4312 demo board These boards are simple receiver demo boards for FSK and OOK respectively, with SMA antenna input, and SMA raw data output. For details see the Si4311-DB Users Guide and Si4312-DB Users Guide documents, available on www. silabs. com. 1. 2. 4. Si4311 LCD FSK Receiver 434 MHz and Si4312 LCD OOK Receiver 434 MHz Development boards for the Si4311 and Si4312 receivers, with a microcontroller, pushbuttons and LCD display. These boards are preloaded with the example program that is capable to receive the packets of the Si4010 Key Fob Demo with AES Capability. For details see the Si4010 Key Fob Demo Kit with AES Capability Users Guide available on www. silabs. com. Rev. 0. 2 5 Si4010-Key Fob-DK 1. 3. Usage of the Key Fob Development Platform The Silicon Labs IDE communicates with the USB Debug Adapter through the USB bus. The following debugging scenarios are possible: 1. EC3 debug adapter ? Burning adapter? Si4010 socketed key fob development board This setup is suitable for downloading, running, and debugging the program in RAM or burning the program in the NVM and running it. The antenna or measuring instrument can be connected through an SMA connector. Since sockets on board allow use of unsoldered ICs, this is the ideal scenario for burning the NVM memory of Si4010. 2. EC3 debug adapter ? Burning adapter? Si4010 MSOP key fob development board This setup is suitable for downloading, running, and debugging the program in RAM. This board has a PCB antenna and battery, so after downloading the program and starting the execution by disconnecting in the IDE, the board can be physically disconnected from the programming interface and tested in mobile form. A switch is provided on the board to connect/disconnect the battery. Note: Although burning is also possible with this setup, it is not practical since Si4010 is soldered on the key fob development board. 6 Rev. 0. 2 Si4010-Key Fob-DK 3. EC3 debug adapter ? Programming adapter? User’s own application In this setup, the user can incorporate the debugging capabilities into the final application using a cheap 4-pin header connection. Silicon Labs’ ToolStick USB Debug Adapter (not part of the development kit) is also compatible with the key fob development platform and can be used in the above scenarios. 2. Debugging an Application To debug an application the user is provided with the Silicon Laboratories IDE (Integrated Development Environment). The IDE has an integral help. This section is not a user manual for the IDE, but highlights the items which are important when working with the IDE. 2. 1. Installing the IDE and USB Debug Adapters Download the Silicon Labs IDE (Integrated Dvelopment Environment) from the following URL: http://www. silabs. com/products/mcu/Pages/SiliconLaboratoriesIDE. aspx and install it on your computer. The IDE gets installed into its own directory. The main executable file is IDE. exe. The IDE works with the USB Debug Adapter, shown in the section above. When the IDE recognizes the Silicon Labs USB debug adapters, it queries whether its internal firmware is compatible with the Si4010. If not, then it notifies the user and requests permission to update the adapters firmware. Silicon Labs also provides a program, usb_debug_adapter_firmware_reset. xe, to clear the adapters firmware manually before connection to the IDE. The program resides in the same directory as the IDE main executable. With the Si4010 debugging chain it is required that the manual adapter firmware clearing is done for each USB adapter before using the key fob debugging chain. That o peration needs to be done only once per USB Debug Adapter. The IDE will then program the correct firmware into the adapter. The reset firmware executable will scan USB ports and give the user a list of connected Silicon Labs USB adapters. The USB Debug Adapter name starts with EC. Users can have more than one USB adapter connected to the computer. 2. 2. Keil toolchain integration The project files in examples assume that the Keil toolchain is installed into: C:Keil directory. The location of the Keil toolchain can be easily changed in the Silabs IDE in the Project—Tool Chain Integration menu. An evaluation version of the Keil toolchain can be downloaded from the Keil website at http://www. keil. com/. This free version has a 2 kB code limitation and starts the code at the 0x0800 address. The Keil free evaluation version can be unlocked to become a 4 kB version with no code placement limitation by following the directions given in application note AN104 about Keil toolchain integration and license management. Unlock code can be found on the WDS CDROM in the root folder in the Keil_license_number. txt file. Contact your Silicon Laboratories sales representative or distributor for application assistance. Rev. 0. 2 7 Si4010-Key Fob-DK 2. 3. IDE Features The IDE allows the following: 1. Download the OMF-51 linker output format (Keil BL51 linker output, for example) and match the source code lines with the compiled file. This allows source code debugging, including variable value viewing, setting breakpoints, single-stepping, etc. Note that the output of the Keil LX51 linker is not understood by the IDE. 2. Download the IntelHEX file for the application. When using the IntelHEX file the source code debugging is not available. The user can set a breakpoint for a specific code address by going through the Debug ? Breakpoints (Alt+B) menu item. The user can also single-step through the disassembly of the loaded code. 3. Setting at least 4 breakpoints with a possible maximum of 8. The actual number of breakpoints available is determined by the IDE from the factory setting of the chip. 4. Single-stepping through the disassembly of the code. If the OMF file is loaded, the single-stepping is matched with the source code. 5. Viewing and changing variables, SFR registers, XREG registers, and the contents of both DATA/IDATA RAM and CODE/XDATA RAM on the fly during debugging. When the changes are made by the user in the corresponding windows, the user must press the Refresh Values (Alt+R) button on the toolbar to update the values in the device. Just changing values in the IDE will not automatically update them in the device. 2. 4. IDE Debugging Session The typical IDE debugging session consists of the following sequence: 1. Connect the IDE to the chip by hitting the Connect or invoking menu Debug ? Connect menu item. 2. Download the OMF file either by hitting the Download code (Alt+D) toolbar button or from the Debug ? Download object code menu item. The latter also allows IntelHEX download, but without the source code debugging capability. 3. After the code download, the device is automatically halted at address 0x0000 in CODE/XDATA RAM. Then the user can set breakpoints, single-step, animate, etc. 4. The user can hit the Reset (Ctrl+R) toolbar button any time the device is halted (not running). The internal digital system level reset is invoked and the device goes through the boot sequence. The previously loaded code by the user into the CODE/XDATA RAM is preserved and the device is halted at the address 0x0000 of CODE/XDATA RAM. 5. When a bug is found, the user can download a new OMF file whenever the device is halted. There is no need to disconnect the device from the debug chain or to hit reset. The download, item 2 above, will automatically reset the device after the OMF/IntelHEX new code download is finished. It is very important to note that whenever the Disconnect toolbar button is hit or the Debug ? Disconnect menu item is invoked, the debugging chain does the following: †¢ Enables the LED driver. During the debugging sessions the LED current driver is forcibly disabled. †¢ Clears all the breakpoints. †¢ Releases the device from halt and lets it run from the point when it was halted. 2. 5. Important Note about Single-Stepping Over ROM Code Single-stepping through the ROM code is disabled. Whenever the user encounters the call to the ROM API functions he or she should use the Step Over (F10) toolbar button rather than the Step (F11) or Multiple Step button. Even though single-stepping through the ROM API function using the Step (F11) button works from the user’s point of view, the CPU timing is modified and real-time performance is not guaranteed when using the Step (F11) or Multiple Step buttons over the ROM API functions. Therefore, it is highly recommended to use the Step Over (F10) toolbar button when stepping over the ROM API functions in IDE. Single-stepping over the bMtp_Write() function using Step (F11) or Multiple Step buttons may yield unpredictable results in the MTP (EEPROM) and is highly discouraged. One should use the Step Over (F10) tool, run to cursor, or setting a breakpoint when debugging around the MTP write function. 8 Rev. 0. 2 Si4010-Key Fob-DK . 6. Device Version 1. The device ID information can be read through the IDE through Views ? Debug Windows ? Si4010 ? XREG Regs. The last item bREV_ID is the device revision. The user can also call the API function bSys_GetRevId(). 2. The trim version can be read by t he Silicon Labs IDE as External Memory through Views ? Debug Windows -; External Memory at location 0x11D6. There is a macro bSys_TrimId_c defined in the headers for use in customer code as well. The user needs to know the TrimId before writing any code, so the manual access to it is adequate. The trim version will rarely change and customers will be notified about the change. The provided NVM burner program reads both the bREV_ID device revision and the trim version bSys_TrimId in the [Device] tab after the burner is connected to the device. 2. 7. Debugging Application which Drives LED To maximize utilization of the package pins, the LED current driver output is shared with the debug chain clock signal C2CLK. To share the functionality and be able to use the IDE for debugging there are some limitations to note and rules to follow. The following figure shows the recommended connection of the USB 10-pin debug header to the device in the user application. Note: The LED must be isolated by the 470 ? resistor for the debug chain to work. Rev. 0. 2 9 Si4010-Key Fob-DK Facts about using the LED with IDE chain: 1. The IDE chain can connect to the device only if the LED current driver is off and the LED is not lit. 2. Once the IDE chain is connected to the device it blocks the device LED driver. Therefore, the application can be written in a normal fashion using LED as desired in the final application without worry of being disconnected from the debug chain. The only limitation is that the LED will not be lit from the application during the IDE debug session. The user will still observe LED activity, but that activity is related to the debug chain communicating with the device, not the user application driving the LED. 3. Once the IDE chain is disconnected from the device (for example, by pressing the Disconnect button in the IDE), the device is released from halt and at the same time the blocking of the LED driver is removed. From that point on, the application behaves and runs as a regular application and the LED activity reflects what the application desires to do with the LED. 4. If the user wants to reconnect the IDE to the device the only requirement is that the LED must not be lit by the application and the C2 debug interface must be active, not being actively turned off by the application. Therefore, if the device user software is stuck in an infinite loop and driving the LED constantly or the C2 interface was turned off by the application, the IDE chain will not be able to connect to the device. In such a situation, the device power has to be cycled to invoke internal power on reset. (See item 1 above. ) Cycling the power to the part in this context means either physical removal of the power to the device or calling the vSys_Shutdown() function from within the application, which achieves the same result. 2. 8. Hardware Issue with Debugging LED Application There is an issue with the LED turning on and off and the functionality of the GPI04. There is no issue when the part is programmed as the Run part and runs the final application code. Therefore, the issue affects only the application development. There are several possible software workarounds, depending on the approach the user wants to take. 2. 8. 1. Application LED Control The user can control the LED intensity and whether the LED is on or off. The LED intensity has 4 values, 0 to 3: Off, 0. 3 mA, 0. 6 mA, and 1 mA current. The user can set the intensity any time, but the LED is not going to be turned on until the GPIO_LED is set to 1. The GPIO_LED is an alias for the P0. 5 bit. After the reset the P0. 5 bit is set to 1, so it is recommended that the user use GPIO_LED = 0 at the beginning of the user application. To turn the LED off at the very beginning of the user application: /* Clear the GPIO_LED.. reset will set this bit! */ GPIO_LED = 0; To turn the LED on and off inside the user application: /* Set LED intensity .. cceptable values are 0 (off) or 1, 2, and 3 */ vSys_LedIntensity( 3 ); †¦ /* To turn the LED on at currently set intensity */ GPIO_LED = 1; †¦ /* To turn the LED off, keep the intensity setting */ GPIO_LED = 0; 10 Rev. 0. 2 Si4010-Key Fob-DK The intensity setting can be changed any time, even when the GPIO_LED = 1. This is basically how the LED control operates. This approach will work when the part status is finalized as the Run device, since for that program level the C2 interface is turned off after the boot-by-boot routine. However, when the code above is used for a device in the Factory or User programming state, then the GPIO4 will stop working after the first LED blink. The LED must be seen to be turned on and off by the application (to blink) to experience this problem. 2. 8. 2. Solution 1: Living with the Limitation The simplest solution is to know about the issue and decide to live with it. After the first LED blink, the GPI04 will not work. In this scenario, the user may decide to test the GPI04 only when the part is fully programmed as the Run part. 2. 8. 3. Solution 2: Controlled Compilation The user may use a #define C statement to define a LED on value. For button press debugging purposes when the LED can be off the code is compiled with value set as 0, so the LED will never light up and the GPIO4 will always function. For debugging the LED, and for final application compilation for the Run state of the device, the user will compile the application with the LED on value set to 1. For example: #ifdef DEBUG #define gLedOnValue_c #else #define gLedOnValue_c