Skip to content

Program the Zolertia platforms

Antonio Lignan edited this page Sep 29, 2016 · 28 revisions

Program the Zolertia Platforms

To start working with the Zolertia platforms you only need three things:

In this section we are going to show you how to program (or flash) the compiled binary images to your Zolertia Platforms. Normally this process is done just right after compiling and it is handled by the Operative System itself, so you don't have to worry about external tools and extra steps, as this is done via USB.

If you are interested in how does this work read below, else just skip to the next section.

How does programming over USB works?

All Zolertia platforms have a Serial To USB converter on-board, meaning you can directly connect the devices to one of your USB ports without any additional hardware but a cable. The defacto connector used by Zolertia is a microUSB (pretty much the same used to charge most Android phones nowadays).

Flashing is done via USB by transferring the compiled binary to the device, where the ROM bootloader executes the image after reset. The details on how the serial bootloader works depends on the platform, to be discussed below.

Serial Bootloader on the Zoul-based platforms (RE-Mote, Firefly, etc.)

The RE-Mote has 2 on-board Micro USB ports, one for programming/debugging, and the other to use native USB 2.0 applications. Check out the RE-Mote pin-out section for more details on the ports locations.

The CC2538 device family has an on-chip ROM which contains utility function library and serial bootloader (UART and SPI/SSI based). The bootloader will be normally executed directly after reset, if there is no valid image exists in the flash. The flash is assumed to be empty or without valid image, if no flash vector table is configured in the Customer Configuration Area (CCA). However even if there is a valid image in the flash memory, it is possible to execute the ROM bootloader after reset by configuring the "Bootloader backdoor" byte in the CCA memory. -- Texas Instruments Wiki

As mentioned before the RE-Mote (and the Firefly as well) has an on-board USB converter, namely the CP2104. Besides printing over USB the debug information from the platform, it also allows to flash the RE-Mote over USB. It communicates with an on-board MCU (Microchip PIC12F519) to automatically unlock the bootloader upon flashing the RE-Mote.

In cases in which it is required to manually unlock the bootloader, this can be done by pressing and holding the user button (mapped to pin PA3) then pressing the RESET button and releasing... like a secret handshake!

Serial Bootloader on the Zolertia Z1 mote

Todo

Flashing my Zolertia devices

Zolertia RE-Mote platform

The RE-Mote uses the cc2538-bsl python script developed by Jelmer Tiete. The script is commonly used in both Contiki and RIOT to flash the CC2538 and the Zoul based platforms like the RE-Mote, so it will be already available in your working copy, no need to download twice!

If you want to get the script for external use, below are instructions to clone:

git clone https://github.com/JelmerT/cc2538-bsl
cd cc2538-bsl

You might need to install the following dependencies:

pip install intelhex
pip install python-magic

Be sure to install the required CP2104 drivers (Linux users not not required as it is already installed):

Get the CP2104 driver

Connect the RE-Mote using USB:

And then to flash the devices:

python tools/cc2538-bsl.py -e -w -v -p /dev/ttyUSB0 image.bin

Replace /dev/ttyUSB0 accordingly depending on your operative system (COM10, /dev/tty.SLAB_USBtoUART) and the assigned port, and image.bin with the name of the binary (.elf or .bin) or image to flash to the devices.

A similar output should appear if the device has been properly flashed:

Opening port /dev/ttyUSB0, baud 500000
Reading data from zoul-demo.bin
Firmware file: Raw Binary
Connecting to target...
CC2538 PG2.0: 512KB Flash, 32KB SRAM, CCFG at 0x0027FFD4
Primary IEEE Address: 06:16:0E:74:00:12:4B:00
Erasing 524288 bytes starting at address 0x00200000
    Erase done
Writing 524288 bytes starting at address 0x00200000
Write 16 bytes at 0x0027FFF0F8
    Write done                                
Verifying by comparing CRC32 calculations.
    Verified (match: 0x8e273276)

Note: if this doesn't seems to work with you, you should in any case ensure you are using the latest cc2538-bsl script. The current version correspond to the following commit:

commit 4340542370d3e319d692f9f969c5683231fce438
Merge: a3b762b 2e42819
Author: Jelmer Tiete <jelmer@tiete.be>
Date:   Mon Feb 29 13:29:55 2016 +0100

    Merge pull request #51 from g-oikonomou/contrib/invert-lines  
    Add option to invert the bootloader lines (RTS and DTR).

To find out if your version matches or supersedes the above then you are good to go. In Contiki this script lives in tools/cc2538-bsl, in RIOT at dist/tools/cc2538-bsl.

If you are running Contiki and have a version behind the aforementioned, run the following commands at the top of contiki root location:

git submodule init
git submodule update

If the problem persist, try and increase the timing at the tools/cc2538-bsl/cc2538-bsl.py file, locate the following line time.sleep(0.002) and replace with a higher value like time.sleep(0.1):

        set_bootloader_pin(1 if not dtr_active_high else 0)
        set_reset_pin(0)
        set_reset_pin(1)
        set_reset_pin(0)
        time.sleep(0.002)  # Make sure the pin is still asserted when the chip
                           # comes out of reset. This fixes an issue where there
                           # wasn't enough delay here on Mac.
        set_bootloader_pin(0 if not dtr_active_high else 1)

        # Some boards have a co-processor that detects this sequence here and
        # then drives the main chip's BSL enable and !RESET pins. Depending on
        # board design and co-processor behaviour, the !RESET pin may get
        # asserted after we have finished the sequence here. In this case, we
        # need a small delay so as to avoid trying to talk to main chip before
        # it has actually entered its bootloader mode.
        #
        # See contiki-os/contiki#1533
        time.sleep(0.002)

You can also manually put the RE-Mote in programming mode, that is, to manually do what the on-board PIC does as shown above. This is useful if you want to put the RE-Mote in an IDLE state, or if you have problems flashing the RE-Mote as described above.

To enter programming mode manually just: press and hold the user button, then press and hold the reset button, and proceed to release the reset button and the user button. The video below shows how to do it:

Flashing the RE-Mote over JTAG

The RE-Mote has a JTAG connector to flash and debug using a JTAG probe. Note in the photo below it shows the CC2538 JTAG connector, the other non-populated connector corresponds to the on-board PIC.

The JTAG connector product number is M50-3500542, available in Digikey, Farnell and other vendors.

Below are two ways to flash the RE-Mote over JTAG, depending on the hardware available and the Operating system.

Flash the RE-Mote using the SmartRF06 board

This is perhaps the simplest way to flash the RE-Mote over JTAG, if are lucky and have one of this boards then you are good to go.

The SmartRF06 from Texas Instruments is commercially available, and over JTAG you can also do some cool stuff, like controlling the CC2538 built-in 2.4GHz interface using SmartRF Studio.

Additionally you will need the SmartRF flash programmer.

Note on the photo the RE-Mote is also powered over its own USB connector, and should be powered externally!

Just connect over USB, choose the CC2538 in the Connected devices tab, and select the binary to be flashed. Next mark the Erase and Program Actions box fields and hit the button (the one with the white arrow inside the blue circle). Don't worry if the first time fails, the second time normally works as the flash memory should be erased by then.

Note you must specify a starter address, depending on the image you want to flash, it could be either 0x00200000 or 0x00202000. The latest is the default one if using an updated version of Contiki, and the 0x00200000 is the default one for the CC2538.

Flash the RE-Mote using a J-Link from Segger

Another way to flash the RE-Mote is to purchase a J-Link programmer from Segger.

Note on the photo the RE-Mote is also powered over its own USB connector, and should be powered externally!

Note also you will need an adapter to match the 10-pin JTAG connector on the RE-Mote to the 20-pin connector of the J-Link:

First install the required software:

Download the J-Link library (x86 or 64 bits):

http://www.segger.com/jlink-software.html?step=1&file=JLinkLinuxDEB32_4.84.6
http://www.segger.com/jlink-software.html?step=1&file=JLinkLinuxDEB64_4.84.6

Then install:

sudo dpkg --install jlink_4.84.6_x86_64.deb

Open a JLink connection:

$ JLinkExe -device CC2538SF53
SEGGER J-Link Commander V4.84f ('?' for help)
Compiled May  9 2014 20:12:00
Info: Device "CC2538SF53" selected (512 KB flash, 32 KB RAM).
DLL version V4.84f, compiled May  9 2014 20:11:58
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware: V8.00
S/N: 268006863 
OEM: SEGGER-EDU 
Feature(s): FlashBP, GDB 
VTarget = 3.345V
Info: TotalIRLen = 10, IRPrint = 0x0011
Info: Found Cortex-M3 r2p0, Little endian.
Info: FPUnit: 6 code (BP) slots and 2 literal slots
Info: TPIU fitted.
Found 2 JTAG devices, Total IRLen = 10:
#0 Id: 0x4BA00477, IRLen: 04, IRPrint: 0x1, CoreSight JTAG-DP (ARM)
#1 Id: 0x8B96402F, IRLen: 06, IRPrint: 0x1, TI ICEPick
Cortex-M3 identified.
Target interface speed: 100 kHz
J-Link>

This will show the following:

J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
J-Link>halt
PC = 00202708, CycleCnt = 40000000
R0 = 20004EF8, R1 = 00000001, R2 = 00000001, R3 = 0001B3CE
R4 = 20004EF8, R5 = 200041E8, R6 = 20004F28, R7 = 00000FB9
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 00002000
SP(R13)= 200070C8, MSP= 200070C8, PSP= 00000000, R14(LR) = 00204625
XPSR = 01000000: APSR = nzcvq, EPSR = 01000000, IPSR = 000 (NoException)
CFBP = 00000000, CONTROL = 00, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 00
J-Link>erase
Erasing device (CC2538SF53)...
Info: J-Link: Flash download: Total time needed: 10.945s (Prepare: 2.229s, Compare: 0.000s, Erase: 6.678s, Program: 0.000s, Verify: 0.000s, Restore: 2.037s)
Erasing done.

Then open a GDB connection:

$ JLinkGDBServer -device CC2538SF53
SEGGER J-Link GDB Server V4.84f Command Line Version

JLinkARM.dll V4.84f (DLL compiled May  9 2014 20:11:58)

-----GDB Server start settings-----
GDBInit file:                  none
GDB Server Listening port:     2331
SWO raw output listening port: 2332
Terminal I/O port:             2333
Accept remote connection:      yes
Generate logfile:              off
Verify download:               off
Init regs on start:            on
Silent mode:                   off
Single run mode:               off
Target connection timeout:     5 sec.
------J-Link related settings------
J-Link Host interface:         USB
J-Link script:                 none
J-Link settings file:          none
------Target related settings------
Target device:                 CC2538SF53
Target interface:              JTAG
Target interface speed:        1000kHz
Target endian:                 little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware: V8.00
S/N: 268006863
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 3.34 V
Listening on TCP/IP port 2331
Connecting to target...
J-Link found 2 JTAG devices, Total IRLen = 10
JTAG ID: 0x4BA00477 (Cortex-M3)
Connected to target
Waiting for GDB connection...

On another terminal use the arm-none-eabi-gdb to configure our remote target. You can copy and paste the commands below the arm-none-eabi-gdb line.

$ arm-none-eabi-gdb
target remote localhost:2331
monitor interface jtag
monitor speed 5000
monitor endian little
monitor flash download = 1
monitor flash breakpoints = 1
monitor reset

On out previous JLink terminal we should see something like:

Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x00000000 (Data = 0x20008000)
Read 2 bytes @ address 0x00000000 (Data = 0x8000)
Select JTAG as target interface
Target interface speed set to 4800 kHz
Target endianess set to "little endian"
Flash download enabled
Flash breakpoints enabled
Resetting target

Now we are prepared to flash the RE-Mote, note it only accepts .elf binaries. Note also the starting flash address is 0x00202000.

load hello-world.elf
Loading section .text, size 0x11892 lma 0x202000
Loading section .data, size 0x684 lma 0x213894
Loading section .ARM.exidx, size 0x8 lma 0x213f18
Loading section .flashcca, size 0x2c lma 0x27ffd4
Start address 0x27ffd4, load size 73546
Transfer rate: 4488 KB/sec, 3502 bytes/write.

On the JLink terminal something similar as below should be read:

Downloading 4096 bytes @ address 0x00202000
Downloading 4096 bytes @ address 0x00203000
Downloading 4096 bytes @ address 0x00204000
Downloading 4096 bytes @ address 0x00205000
Downloading 4096 bytes @ address 0x00206000
Downloading 4096 bytes @ address 0x00207000
Downloading 4096 bytes @ address 0x00208000
Downloading 4096 bytes @ address 0x00209000
Downloading 4096 bytes @ address 0x0020A000
Downloading 4096 bytes @ address 0x0020B000
Downloading 4096 bytes @ address 0x0020C000
Downloading 4096 bytes @ address 0x0020D000
Downloading 4096 bytes @ address 0x0020E000
Downloading 4096 bytes @ address 0x0020F000
Downloading 4096 bytes @ address 0x00210000
Downloading 4096 bytes @ address 0x00211000
Downloading 4096 bytes @ address 0x00212000
Downloading 2194 bytes @ address 0x00213000
Downloading 1668 bytes @ address 0x00213894
Downloading 8 bytes @ address 0x00213F18
Downloading 44 bytes @ address 0x0027FFD4

Writing register (PC = 0x0027ffd4)
Read 4 bytes @ address 0x0027FFD4 (Data = 0xF3FFFFFF)
Read 2 bytes @ address 0x0027FFD4 (Data = 0xFFFF)
Clone this wiki locally