Setting the MAC address on a Texas Instrumens CC26x2

The MAC address of the TI CC2652 can be set as factory configuration or as customer configuration.

In the first case, and as stated in the CC26xx memory map, the address value is stored in the Factory Configuration Area (FCFG1), specifically in the registers MAC_15_4_0 and MAC_15_4_1, corresponding to the addresses  0x500012F0 (address offset 0x02F0) and 0x500012F4 (address offset 0x02F4).

In the second case (address set as customer configuration) the values are stored in the Customer Configuration Area (CCFG), specifically in the registers IEEE_MAC_0 and IEEE_MAC_1, corresponding to the addreses 0x50004FC8 (address offset 0x1FC8) and 0x50004FCC (address offset 0x1FCC).

Though in both cases the values stored in these addresses are read-only at runtime, the values stored in the Customer Configuration Area can be set in the firmware source code. By default, the CCFG IEEE_MAC_0 and IEEE_MAC_1 address values are defined in the Core SDK driverlib startup_files/ccfg.c file, and therefore set for all the developed applications through the macros SET_CCFG_IEEE_MAC_0 and SET_CCFG_IEEE_MAC_1, both set by default to 0xFFFFFFFF.

As the CCFG documentation states, in case of being set to 0xFFFFFFFF, the IEEE_MAC_0 and IEEE_MAC_1 values must be considered invalid and the FCFG1 MAC_15_4_0 and MAC_15_4_1 values must be used. In practice that means that if the user is not setting an specific MAC address, the default, factory MAC address will be used. This behaviour is coded in the main.c of most (fi not all) SDK examples.

Then, how the user can set the MAC address to an specific, user value? To do that, the macros SET_CCFG_IEEE_MAC_0 and SET_CCFG_IEEE_MAC_1 must be re-defined in the application-specific ccfg.c file. This file is empty by default and its purpose is, specifically, redefining CCFG macros with custom-user values. Specifically, SET_CCFG_IEEE_MAC_0 contains bits 31 to 0 of the MAC, whereas SET_CCFG_IEEE_MAC_1 contains bits 63 to 32.

Have in mind that the CCFG area will be only flashed if, apart of stating specific values as previously explained, the debugger flash settings are set to rewrite (not to keep) it. To proceed in that way uncheck the CCFG protection as shown in the image below. Have in mind that, once the user address was writen in CCFG, it is not necessary rewriting it every time the program changes, unless the whole address changed.

Last but not least, it is very important to consider that, in case of defining a user-specific MAC address, it must be considered as local (not universal) and therefore the second-least-significant-bit of the first octet must be set to 1. That means that the least significat byte of SET_CCFG_IEEE_MAC_0 must have its second bit set to 1 (for instance being set to 0x00000002).

If a Texas Instruments reserved universal MAC address is being used (converting it to local according to that explained in the previous paragraph), a list of the TI vendor-specific three first octects can be checked here. Notice that, since they are universal and not local, all the shown values have the second bit of the least significant byte set to 0.

As an example, if the reserved 0xFC0F4B universal address prefix is being used, first it must be converted from universal to local by setting to 1 the second bit of the least significant byte. In that way, the prevouls value would be converted to 0xFE0F4B. Taking it as base, a valid, local MAC address would be FE:0F:4B:00:00:00:00:01. Therefore, the SET_CCFG_IEEE_MAC_0 macro would be set to 0x004B0FFE and SET_CCFG_IEEE_MAC_1 would be set to 0x01000000.

Read More

Elbert: CC26x2 Launchpad + XBee 802.15.4 integration

The first tests for integrating a TI CC26x2 Launchpad as 802.15.4 end node in a PAN coordinated by a Digi Xbee Pro S1 module have been performed with relative successful results: Though the integration is feasible, there are still some stability issues that must be solved.

The tests have been performed taking as base the TI CC26x2 SDK 802.15.4 "sensor" example program, that implements an end-node able to join to a coordinator and send periodically temperature samples (among other data). On the original code, these changes have been performed:

• Application/2_4g/config.h: macro CONFIG_SECURE set to false to disable network encryption
• Application/2_4g/config.h: macro CONFIG_PAN_ID set to 0x0001 to match the PAN id set on the Coordinator side (Xbee ID parameter)
• Application/2_4g/config.h: macro CONFIG_CHANNEL_MASK bytes 1 & 2 (first byte is byte 0) set to 0xF0 and 0xFF to allow end node using all the channels in which the Xbee Pro module can work (from channel 12, or 0x0C, to channel 23, or 0x17). Note however that this channel usage must match the channels enabled on the Xbee coordinator side (parameter SC)

In the other side, a Xbee Pro S1 module with firmware 10EF (last version available) performs the tasks of PAN coordinator, both being installed on a Connectport X2 with the radio forwarded to a serial port or on a XBIB-U-DEV board. The relevant parameters modified in the Xbee module are:

• Coordinator association (A2) mask set to 0x6, indicating that the coordinator will establish the network in the best of the enabled channels (read on) and that the coordinator allows association of end nodes
• Coordinator enable (CE) set to 1: Module working as coordinator
• Encryption enable (EE) set to 0: Encryption disabled
• Mac Mode (MM) set to 2: Module working on legacy 802.15.4 with ACKs enabled
• Network address (MY) set to 0: The coordinator address will be the address 0
• PAN identifier (ID) set to 0x0001
• Scan channels (SC) set to 0x1FFE, meaning that the coordinator will try to establish the network only on all the XBee Pro available channels (from channel 0x0C, or 12, to channel 0x17, or 23).

With these settings, the CC26x2 joins as end node to the PAN created by the Xbee coordinator and a third party is able to receive the temperature data sent by the CC26x2 via the coordinator. Some issues have to be considered, though:

• It is highly recommended to open a Monitor session to the CC26x2 serial port (on Code Composer Studio, via the JTAG interface) to know exactly what is happening on it. The network changes are reported using these numeric codes:
• 0: Module not started, waiting for user to start
• 1: Module trying to join to a network
• 2: After a reboot, the module has found network information on non-volatile memory and it is trying to join the network it was joined before the reboot
• 3: Module successfully joined to a network
• 4: Module successfully rejoined to a network
• 5: Module has lost the network and right now is orphan
• The CC26x2 will always try to rejoin a previously known network. To avoid it, it is necessary rebooting erasing the non-volatile memory by holding button 2, then pressing and releasing the reset button, then releasing button 2.
• If the CC26x2 channel mask is broad, ie, if it has to search a coordinator in many channels, it is possible that the joining was not instantaneous after rebooting: Finding the coordinator channel will take some time (in the order of tens of seconds).
• If the Xbee module serial port is not open, the module locks after receiving 3-5 frames from the CC26x2. It is the explanation to the fact that, if the Xbee module is set on the XBIB-U-DEV board just powered, but with the USB port not mapped in the computer side, it becomes locked. However it does not happen if the same board is connected to a computer that maps the USB port.
• Even being joined, the X2 coordinator does not show the CC26x2 in the list of detected devices. It is possible that only Xbee devices were shown in that list, with information obtained from the Digi extra header added to the 802.15.4 header when the Xbee MM parameters is set to 1 (that is not this case).

At this point it has been confirmed that the connection is feasible. However some stability issues must be investigated:

• In some circumstances, the CC26x2 is not able to find the coordinator network. This usually happens after resetting/reflashing the CC26x2, with the module staying in state 1 (trying to join) permanently. It is necessary to check if, in these circumstances, a reset with nvmem erase (by holding button 2, as explained before) solves the problem.
• In some circumstances, the CC26x2 joins the network and sends samples, but the coordinator is unable to receive data: Neither data is output in X2 gateway mode, nor the X2 counters increment in non-gateway mode, nor the radio signal strength leds in XBIB or X2 show activity.

Read More

Colorado projects started

A new branch in the project repository addressed to develop two new subprojects has been created. The new subprojects are:

• Litem (Mount) Elbert project, addressed to develop a set of Litems based on the Texas Instruments CC26x2 Lauchpad evaluation board (see evaluation board clicking here), using 802.15.4 as network protocol for communicating with the gateway. The code is localted in the subdirectory SteamProject/software/litems/802.15.4/ti-cc26x2-lp/elbert/ of the GitHub repository (direct access clicking here). Given that Elbert works will be developed on a evaluation board, all the results will be considered as experimental.
• Gateway Colorado (river) project, addressed to develop a gateway running on Raspberry Pi (Raspbian OS) implementing 802.15.4 in the underlying network by integrating a Digi Xbee module as interface. The code is located in the subdirectory SteamProject/software/gateways/802.15.4/raspbian/colorado/ of the GitHub repository (direct access clicking here). Colorado source code will be developed in Java and the expected result will be potentially feasible to be put into production.

These two projects will run in parallel, since it is necessary their mutual integration to have a practical result (litem without gateway and viceversa is nonsense). However, even being closely related, it is important to state that the individual results will be compatible with the STEAM specification, ie, Elbert will be compatible with any STEAM 802.15.4 gateway and Colorado will be compatible with any STEAM 802.15.4 litem.

Since both the Colorado river and the mount Elbert have strong relationship with the Colorado state, the above icon is selected to represent graphically these two projects.

For detailed Elbert project information (description, planning and current status) click here. For detailed Colorado project information (description, planning and current status) click here.

Read More

Texas Instruments CC26x2 Launchpad

UPDATE: Pre-production silicon versions earlier than Revision E (from Jan 2019 on) will only support CC26X2 SDK 2.30 and earlier (SDK available clicking here). Silicon revision E and later will only be compatible with CC26X2 SDK 2.40 and later. Production silicon is expected to be launched on early second quater 2019.

As defined in the project roadmap, in the first stage some technology will be developed in parallel to the definition of interfaces and protocols.

To do that it is necessary to choose a powerful yet flexible evaluation board that allowed developing and testing different devices (vehicle controller, discrete actuator,...)

Texas Instruments has recently launched a new SOC (System On Chip) called CC2652R with interesting features:

• Supports wireless communications based on the protocol 802.15.4 (as Bluetooth Low Energy, Zigbee, Thread or raw 802.15.4)
• Supports wired communications as RS-232, I2C or SPI
• Supports a wide range of analog and digital IOs and sensors (as, for instance, PWM outputs)
• Allows programming from a solid, free, environment (Code Composer Studio, or CCS) in C/C++ over real time operating systems (both Texas Instruments RTOS or FreeRTOS)
• It has a small form factor (VQFN) and contained price (around 3$)

In order to "play" with this little wonder, Texas Instruments has launched too an evaluation board called Simplelink CC26x2R Launchpad (shown in the photo) that allows an optimal integration between the CC2652R MCU and the programming environment (Code Composer Studio) thanks to its included JTAG interface. As can be seen, the evaluation board allows access to most of the MCU IOs, specifically the mapping of these IOS is defined in this table:

GPIO Id	Pin	Type	Description	CC26x2 Launchpad mapping	Launchpad usage	User usage
DIO_0	5	Digital	Sensor controller	DIO0	-	DIO
DIO_1	6	Digital	Sensor controller	DIO1_RFSW	?	?
DIO_2	7	Digital	Sensor controller	UART(0)_RX	UART	-
DIO_3	8	Digital	Sensor controller	UART(0)_TX	UART	-
DIO_4	9	Digital	Sensor controller	I2C_SCL	I2C interface	-
DIO_5	10	Digital	Sensor controller, high drive	I2C_SDA	I2C interface	-
DIO_6	11	Digital	Sensor controller, high drive	PIN_RLED, PWMPIN0	Launchpad red led, PWM0	DIO high drive (removing Launchpad led jumpers)
DIO_7	12	Digital	Sensor controller, high drive	PIN_GLED, PWMPIN1	Launchpad green led, PWM1	DIO high drive (removing Launchpad led jumpers)
DIO_8	14	Digital		SPI0_MISO	SPI	-
DIO_9	15	Digital		SPI0_MOSI	SPI	-
DIO_10	16	Digital		SPI0_CLK	SPI	-
DIO_11	17	Digital		-	Not used / Not documented	?
DIO_12	18	Digital		DIO12, LCD_EXTCOMIN	Sharp LCD boosterPack	-
DIO_13	19	Digital		PIN_BTN1	Launchpad button 1	-
DIO_14	20	Digital		PIN_BTN2	Launchpad button 2	-
DIO_15	21	Digital		DIO15	-	DIO
DIO_16	26	Digital	JTAG_TDO, high drive	DIO16_TDO	-	DIO high drive
DIO_17	27	Digital	JTAG_TDI, high drive	DIO17_TDI	-	DIO high drive
DIO_18	28	Digital		UART(0)_RTS	JTAG UART	UART (removing JTAG Rx/Tx jumpers)
DIO_19	29	Digital		UART(0)_CTS	JTAG UART	UART (removing JTAG Rx/Tx jumpers)
DIO_20	30	Digital		SPI_FLASH_CS	SPI	-
DIO_21	31	Digital		DIO_21	-	DIO
DIO_22	32	Digital		DIO_22, LCD_ENABLE	Sharp CLD boosterPack	-
DIO_23	36	Digital/Analog	Sensor controller, analog	DIO23_Analog, LCD_POWER	Sharp CLD boosterPack	-
DIO_24	37	Digital/Analog	Sensor controller, analog	DIO24_Analog, LCD_CS	Sharp CLD boosterPack	-
DIO_25	38	Digital/Analog	Sensor controller, analog	DIO25_Analog	-	Analog
DIO_26	39	Digital/Analog	Sensor controller, analog	DIO26_Analog	-	Analog
DIO_27	40	Digital/Analog	Sensor controller, analog	DIO27_Analog	-	Analog
DIO_28	41	Digital/Analog	Sensor controller, analog	DIO28_Analog	-	Analog
DIO_29	42	Digital/Analog	Sensor controller, analog	DIO29_Analog	-	Analog
DIO_30	43	Digital/Analog	Sensor controller, analog	DIO30_Analog	-	Analog

The evaluation board pricing is around 40$ and, together with the fantastic CC26X2 Software Development Kit (available for Windows, Linux and MacOS) and Texas Instrument online developer tools allows start developing code in a record time.

This evaluation board together with all the defined software is chosen as technological resource for developing the LItems on the Elbert project

Some detailed photos of the evaluation board can be seen below:

General evaluation board view, with CC2652R MCU on first plane

Detail of the CC2652R MCU, its small size can be appreciated by comparing it with the left jumpers

Detail of the CC2652R MCU. At right and left the pins giving access to the MCU IOs can be seen

JTAG interface, on first plane the microUSB connector and reset button. The CC2652R MCU can be fully isolated from the onboard JTAG by removing all the jumpers on the photo, allowing both using external JTAG or using the onboard JTAG with other MCUs

Read More