jelmert / cc2538-bsl Goto Github PK

Hi all,

I am using the script to upgrade my CC2650 but got a timeout issue when upgrade firmware. Does anyone have any suggestion?

Following is the log:
[/home/george/Downloads/cc2538-bsl-master]$./cc2538-bsl.py -e -w -v -V -b 115200 -p /dev/ttyUSB0 ./BLEPeripheral.hex
Opening port /dev/ttyUSB0, baud 115200
Reading data from ./BLEPeripheral.hex
Your firmware looks like an Intel Hex file
For more solid firmware type auto-detection, install python-magic.
Please see the readme for more details.
Connecting to target...
*** sending synch sequence
Got 0 additional bytes before ACK/NACK
*** GetChipId command (0x28)
Got 0 additional bytes before ACK/NACK
*** received 6 bytes
*** GetStatus command (0x23)
Got 0 additional bytes before ACK/NACK
*** received 3 bytes
Command Successful
Version 0x8000F000
Unrecognized chip ID. Trying CC13xx/CC26xx
*** Mem Read (0x2A)
Got 0 additional bytes before ACK/NACK
*** received 6 bytes
*** GetStatus command (0x23)
Got 0 additional bytes before ACK/NACK
*** received 3 bytes
Command Successful
*** Mem Read (0x2A)
Got 0 additional bytes before ACK/NACK
*** received 6 bytes
*** GetStatus command (0x23)
Got 0 additional bytes before ACK/NACK
*** received 3 bytes
Command Successful
*** Mem Read (0x2A)
Got 0 additional bytes before ACK/NACK
*** received 6 bytes
*** GetStatus command (0x23)
Got 0 additional bytes before ACK/NACK
*** received 3 bytes
Command Successful
*** Mem Read (0x2A)
Got 0 additional bytes before ACK/NACK
*** received 6 bytes
*** GetStatus command (0x23)
Got 0 additional bytes before ACK/NACK
*** received 3 bytes
Command Successful
*** Mem Read (0x2A)
Got 0 additional bytes before ACK/NACK
*** received 6 bytes
*** GetStatus command (0x23)
Got 0 additional bytes before ACK/NACK
*** received 3 bytes
Command Successful
*** Mem Read (0x2A)
Got 0 additional bytes before ACK/NACK
*** received 6 bytes
*** GetStatus command (0x23)
Got 0 additional bytes before ACK/NACK
*** received 3 bytes
Command Successful
*** Mem Read (0x2A)
Got 0 additional bytes before ACK/NACK
*** received 6 bytes
*** GetStatus command (0x23)
Got 0 additional bytes before ACK/NACK
*** received 3 bytes
Command Successful
CC2650 PG2.2 (4x4mm): 128KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x0001FFD8
Primary IEEE Address: 00:12:4B:00:07:EB:75:82
Erasing all main bank flash sectors
*** Bank Erase command(0x2C)
Got 0 additional bytes before ACK/NACK
*** GetStatus command (0x23)
Got 0 additional bytes before ACK/NACK
*** received 3 bytes
Command Successful
Erase done
Writing 131072 bytes starting at address 0x00000000
*** Download command (0x21)
Got 0 additional bytes before ACK/NACK
*** GetStatus command (0x23)
Got 0 additional bytes before ACK/NACK
*** received 3 bytes
Command Successful
*** Send Data (0x24)0x00000000
Got 0 additional bytes before ACK/NACK
*** GetStatus command (0x23)
Got 0 additional bytes before ACK/NACK
*** received 3 bytes
Command Successful
*** Send Data (0x24)0x000000F8

Traceback (most recent call last):
File "./cc2538-bsl.py", line 1057, in
if cmd.writeMemory(conf['address'], firmware.bytes):
File "./cc2538-bsl.py", line 620, in writeMemory
self.cmdSendData(data[offs:offs+trsf_size]) # send next data packet
File "./cc2538-bsl.py", line 536, in cmdSendData
if self._wait_for_ack("Send data (0x24)",10):
File "./cc2538-bsl.py", line 233, in _wait_for_ack
% (info,))
CmdException: Timeout waiting for ACK/NACK after 'Send data (0x24)'
ERROR: Timeout waiting for ACK/NACK after 'Send data (0x24)'

There is still some code in the script for a progress bar during upload. This doesn't work properly at the moment because we skip parts of the code that have values of 0xFF. This makes the bar not advance gradually. It also needs an extra lib, that probably most user don't have.

Fix this or remove it.

I've designed a custom board* using the CC2640, and tried twice to use this script to program it. In both cases, it was able to read flash OK, but failed during the flashing process:

sudo ./cc2538-bsl.py -w /home/rena/projects/ccstudio/hello_CC2650DK_7ID_TI/Debug/hello_CC2650DK_7ID_TI.hex -p /dev/ttyUSB0
[sudo] password for rena: 
./cc2538-bsl.py:971: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if int(value) % int(device.page_size) is not 0:
./cc2538-bsl.py:976: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if int(value, 16) % int(device.page_size) is not 0:
Opening port /dev/ttyUSB0, baud 500000
Reading data from /home/rena/projects/ccstudio/hello_CC2650DK_7ID_TI/Debug/hello_CC2650DK_7ID_TI.hex
Firmware file: Intel Hex
Connecting to target...
CC2640 PG2.3 (5x5mm): 128KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x0001FFD8
Primary IEEE Address: FF:FF:FF:FF:FF:FF:FF:FF
Writing 131072 bytes starting at address 0x00000000
Write 128 bytes at 0x0001FF800
ERROR: Timeout waiting for ACK/NACK after 'Get Status (0x23)'

This seems to have also locked or damaged the chips, as they now neither turn on the LED (DIO_9) at startup nor respond to UART or JTAG. (Tried with two boards, same result both times. TDO and TX just remain high. JTAG was working before flashing.)

The first time, I mistakenly flashed an ELF file; the second time, I flashed the attached Hex file, which is generated by CCStudio. I'm still not really sure if that's the correct file to be flashing; it could be entirely my mistake, although the fact that it times out, and doesn't warn that I'm about to lock the bootloader, makes me suspect there is a bug as well.

I have three more boards and need at least one of them working, so I'm reluctant to try flashing any more, but I'll keep trying to find a way to get JTAG working again.

Of note, although reading flash didn't generate any errors, it was very slow and produced a file containing all 0xFF. I assume this is just because the flash was empty.

OS: Arch Linux AMD64
Serial adapter: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC at 3.3V
JTAG adapter: https://github.com/myelin/teensy-openocd-remote-bitbang

• unfortunately I forgot to save a backup of the actual board before making changes, so this version is slightly different and has some missing GND connections. I might be able to recover the original design.

Hi,

is there any issue know with the actual python library in ubuntu (14.04)? The bsl-script fails to receive the ACK on the synch sequence in about 50% of the times. We checked that the ACK is send correctly (sending 0x55 0x55 by hand using a windows terminal program). Maybe caused by this issue:

https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1501345

I hade similar problems with python using another script (https://github.com/g-oikonomou/sensniff)

Regards

Ulf

Hello!

Something that would be really cool and handy would be to restart a device over USB, is this feature available, or on the roadmap?

Thanks!

See if it is possible to make this script compatible with python3, and not break python2 compatibility. (Python 3 doesn't seem to come standard on all platforms at the moment)

Great script, could you add a licence to it so it's clear? Looking at integrating into some of our tooling.

Standard CC2538EM on SmartRF06EB, programmed with valid image, bootloader bound to KEY_SELECT.

$ python cc2538-bsl.py -p /dev/tty.usbserial-00001014B -r foo.bin
Opening port /dev/tty.usbserial-00001014B, baud 500000
Connecting to target...
    Target id 0xb964, CC2538
Reading 524288 bytes starting at address 0x200000
ERROR: ord() expected string of length 1, but int found

and then with -V

$ python cc2538-bsl.py -p /dev/tty.usbserial-00001014B -V -r foo.bin
Opening port /dev/tty.usbserial-00001014B, baud 500000
Connecting to target...
*** sending synch sequence
*** SetXOsc command (0x29)
Opening port /dev/tty.usbserial-00001014B, baud 1000000
Reconnecting to target at higher speed...
*** sending synch sequence
*** GetChipId command (0x28)
*** received 6 bytes
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
    Target id 0xb964, CC2538
Reading 524288 bytes starting at address 0x200000
*** Mem Read (0x2A)
*** received 6 bytes
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
Traceback (most recent call last):
  File "cc2538-bsl.py", line 787, in <module>
    mdebug(5, " 0x%x: 0x%02x%02x%02x%02x" % (conf['address']+(i*4), ord(rdata[3]), ord(rdata[2]), ord(rdata[1]), ord(rdata[0])), '\r')
TypeError: ord() expected string of length 1, but int found
ERROR: ord() expected string of length 1, but int found

$ git show
commit c0269598b28fff8c496fc38e2b959c8e56f3f955
Merge: 41459b1 a15306c
Author: Jelmer Tiete <[email protected]>
Date:   Wed Sep 2 13:35:32 2015 +0200

    Merge pull request #24 from lab11/disable-backdoor

    Add --disable-bootloader option

Hi,

is seems that the default baud rate used for your script is 500000. Did you test this speed with the cc2538? http://www.ti.com/lit/an/swra466a/swra466a.pdf states that the cc2538 only supports 460800.

Regards

Ulf

Hi,

I am using srf06EB. I am trying to flash cc1310 with contiki demo code. I gettign ACK-NACK error.

PS:- I already modified BL setting as per suggestion mention in the README.

Command:-
sudo make TARGET=srf06-cc26xx BOARD=srf06/cc13xx cc26xx-demo.upload

Error:-

python ../../tools/cc2538-bsl/cc2538-bsl.py -e -w -v -p /dev/ttyUSB0 cc26xx-demo.bin
Opening port /dev/ttyUSB0, baud 500000
Reading data from cc26xx-demo.bin
Firmware file: Raw Binary
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'
make: *** [cc26xx-demo.upload] Error 1

Br
Amit Sharma

@JelmerT I have read through the MSP432 (http://www.ti.com/lit/ug/slau622a/slau622a.pdf) and compared to the CC2538/CC2650 (http://www.ti.com.cn/cn/lit/an/swra466a/swra466a.pdf) documentation, and the BSL implementation seems different. However, the communication mechanisms between the chip and the PC are similar, so I am wondering if you/someone would be interested in adding support for the MSP432 chip to the current implementation.

I've tried this script on a CC1352P and found the following:

• device_id:0x2bb4102f
• wafer_id:0xbb41
• pg_rev:2
  user_id:0x2282f00
  rev_minor=0xff
  FLASH_SIZE=0x2c

In the case of the CC1352 the FLASH_SIZE sector size is 8192 instead of 4096 so the following patch would make this work for CC1352 but I'm sure that would break some other CC13xx variant. What is the right way to detect the difference between CC1352 and whatever other CC13xx variant that has a sector size of 4096?

@@ -828,15 +832,23 @@ class CC26xx(Chip):
         # We can now detect the exact device
         if wafer_id == 0xB99A:
             chip = self._identify_cc26xx(pg_rev, protocols)
-        elif wafer_id == 0xB9BE:
+        elif wafer_id == 0xB9BE or wafer_id == 0xBB41:
             chip = self._identify_cc13xx(pg_rev, protocols)
 
         # Read flash size, calculate and store bootloader disable address
         self.size = self.command_interface.cmdMemReadCC26xx(
-                                                 FLASH_SIZE)[0] * 4096
+                                                 FLASH_SIZE)[0] * 8192

How to replicate:

halley@Tinyhub:~$ python ~/cc2538-bsl/cc2538-bsl.py -p /dev/ttyS1 -b 115200 -w ZNP.bin
Opening port /dev/ttyS1, baud 115200
Reading data from ZNP.bin
Cannot auto-detect firmware filetype: Assuming .bin
Connecting to target...
CC2538 PG2.0: 512KB Flash, 32KB SRAM, CCFG at 0x0027FFD4
Primary IEEE Address: 00:12:4B:00:10:05:FF:DB
Writing 503808 bytes starting at address 0x00200000
Write 120 bytes at 0x0027AF888
    Write done
halley@Tinyhub:~$ python ~/cc2538-bsl/cc2538-bsl.py -p /dev/ttyS1 -b 115200 -r read.bin
Opening port /dev/ttyS1, baud 115200
Connecting to target...
CC2538 PG2.0: 512KB Flash, 32KB SRAM, CCFG at 0x0027FFD4
Primary IEEE Address: 00:12:4B:00:10:05:FF:DB
Reading 524288 bytes starting at address 0x200000
    Read done

Comparison example:

We tested different baud rates both slower and faster including the default with no changes.

Hardware: CC2538. No issues with communication over serial when running as ZNP (flashed with Flash Programmer 2 via JTAG)

Good day

I am having an issue with your script on my SmartRF06 Eval board with a cc2538sf53 on. Please have a look at the output below. Am I doing something wrong?
Erasing works perfectly fine and programming starts off well, but then gets interrupted with the message:
ERROR: No response from target on status request. (Did you disable the bootloader?)

I have tried your script on Linux and OSX on different computers with the same result.
Can you please advise?

Regards
Johan-Henry

Command Successful
*** Send Data (0x24)0x20C5A0
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
*** Send Data (0x24)0x20C698
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
*** Send Data (0x24)0x20C790
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
*** Send Data (0x24)0x20C888
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
*** Send Data (0x24)0x20C980
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
*** Download command (0x21)
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
*** Send Data (0x24)
*** GetStatus command (0x23)
No response to Get Status (0x23)
ERROR: No response from target on status request. (Did you disable the bootloader?)

The device is hardwired for DIO 2 & 3 for Bootloader UART comm.
While trying to flash the board using the script, the following error turns.
terminal log also attached for the reference.
How to solve this ?

screen1.log

Hello,
I can't say if is a CC2538 bug, but after flashing a generic CC2538 512k module with the Contiki's udp-client.bin example, I lost the bootloader access (pulling down PA3 and reset). There was previously an other valid image in the flash. The CC2538-bsl doesn't check the bootloader backdoor field before flashing ? I did something wrong ? I'm afraid in loosing more modules, becaause I dont have the JTAG connection ...
The procedure in Windows was:
C:>python cc2538-bsl.py -p com7 -e -w -v client.bin
Opening port com7, baud 500000
Reading data from client.bin
Connecting to target...
Target id 0xb964, CC2538
Erasing 524288 bytes starting at address 0x200000
Erase done
Writing 524288 bytes starting at address 0x200000
Write done
Verifying by comparing CRC32 calculations.
Verified (match: 0x003d1dfb)

C:>python cc2538-bsl.py -p com7 -e -w -v udp-client.bin
Opening port com7, baud 500000
Reading data from udp-client.bin
Connecting to target...
Target id 0xb964, CC2538
Erasing 524288 bytes starting at address 0x200000
Erase done
Writing 524256 bytes starting at address 0x200000
ERROR: No response from target on status request. (Did you disable the bootloade
r?)

as discussed in #11

-e becomes a general 'mass-erase', which is probably used most often, and we add an option --erase-page which you can give a single page number, a page range, a single address or an address range.
This way it stays clear that when you specify an address, you'll still be erasing a page, because of the name of the option.

I am trying to load the bootloader to cc1352, if I erase completely with uniflash I can program the new firmware, but once with the new firmware I can't reload other firmware

Thanks

Running the command to flash my zzh.
./cc2538-bsl.py -p /dev/ttyUSB0 -e -v -w blink.bin

I get the following error:

Opening port /dev/ttyUSB0, baud 500000
Reading data from blink.bin
Cannot auto-detect firmware filetype: Assuming .bin
Connecting to target...
ERROR: local variable 'chip' referenced before assignment

It looks like the error is from the following line of python. Chip value is not assigned.

        mdebug(5, "%s (%s): %dKB Flash, %s SRAM, CCFG.BL_CONFIG at 0x%08X"
               % (chip, package, self.size >> 10, sram,
                  self.bootloader_address))

With a whole bunch of new TI parts supporting BSL (also a good time to rename? #41), it would be really handy if this script could be installed with a simple: pip install cc2538-bsl

A very similar example is the stm32loader project.

Not a Python expert but I can have a go at modularising and adding the necessary bits if this is something you would consider?

Can this be imported as a module instead of executing using cli? I am trying to bundle my application using pyinstaller, with it invoking the command "python3 cc2538-bsl.py -p /dev/ttyUSB0 -e -w -v firmware.hex" using subprocess.run. It seems to try to use my pc's python environment instead of the bundled runtime (it could be argued that this should be handled by pyinstaller, but I am looking into this on both fronts). This would not be an issue if I could import it and use it as a module. The reason this is an issue is because it defeats the purpose of pyinstaller, the user now must have a python runtime installed.

Hi there
I try to download .bin to cc2538em with SmartRF06 . But still fail.
I do not quite understand how to enter the bootloader mode. I reset the chip when holding select button all the time. However it still fails.
I am a beginner of contiki-OS . I know it's quite stupid.
Thank you anyway.

When trying to read memory I get "ERROR: ord() expected string of length 1, but int found".
When removing the mdebug at the read section, I get similar error when it tries to write data to file - "ERROR: sequence item 0: expected string, int found".

From time to time with no reason I get this. First I started to get it when I specified baud rate with "-b". Then removed the option and got back okay again. Then later I started to get this with "-p" option. And then I started to test what exactly is wrong.
18:42:43-user@instank-contriki:/Folder/ ((0a8645b...))$ python cc2538-bsl.py
ERROR: could not open port /dev/ttyUSB0: [Errno 13] Permission denied: '/dev/ttyUSB0'
18:42:51-user@instant-contiki:/Folder/ ((0a8645b...))$ sudo python cc2538-bsl.py
ERROR: [Errno 22] Invalid argument

Can you explain what is the cause of this? Seems like there is nothing to do with the arguments? More and more I start to feel like there is something wrong with the serial fd.

Hi @JelmerT ,

I have been using you python script for uploading program to openmotes. But I accidentally changed the target to cc2538dk and now I am not able to unlock the bootloader. I don't get any ACK when I send 0x55 x055 on serial terminal.

Is there a way out? I am not able to find any web page on this issue. I can get the J LINK SEGGER debugger if required.

Thanks,
Lovelesh

So the CC26xx has a pretty similar (I suspect identical) bootloader protocol as the CC2538. The main difference is that code starts at 0x00000000 instead of 0x200000, flash size is limited to 128KB, different chip identifier. I have configured my chip to enter bootloader mode

• The erase command seems to ignore the address argument and it would be nice to make size configurable, thus changes required here:

$ git diff
diff --git a/cc2538-bsl.py b/cc2538-bsl.py
index 32565b6..55ba7a7 100644
--- a/cc2538-bsl.py
+++ b/cc2538-bsl.py
@@ -718,8 +718,8 @@ if __name__ == "__main__":

         if conf['erase']:
             # we only do full erase for now (CC2538)
-            address = 0x00200000 #flash start addr for cc2538
-            size = 0x80000 #total flash size cc2538
+            address = conf['address'] # flash start addr for cc2538
+            size = conf['size'] # total flash size cc2538
             mdebug(5, "Erasing %s bytes starting at address 0x%x" % (size, address))

             if cmd.cmdEraseMemory(address, size):

• But even after fixing address and size, there still seems to be a problem - see below. I will try to track it down but pointers would be welcome. The fact it works fine with CC2538 suggests it could be related to the chip ID?

$ python ../../tools/cc2538-bsl/cc2538-bsl.py -a 0 -e -V -b 500000
Opening port /dev/tty.usbserial-00002014B, baud 500000
Connecting to target...
*** sending synch sequence
*** GetChipId command (0x28)
*** received 6 bytes
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
Warning: unrecognized chip ID 0xf000
Erasing 131072 bytes starting at address 0x0
*** Erase command(0x26)
*** GetStatus command (0x23)
*** received 3 bytes
ERROR: unhashable type: 'list'

• The write command seems to program the chip correctly.
• It looks like I'll need to look at verify too. Any pointers?:

$ python ../../tools/cc2538-bsl/cc2538-bsl.py -a 0x00000000 -b 500000 -V -v -w cc26xx-demo.bin 
Opening port /dev/tty.usbserial-00002014B, baud 500000
Reading data from cc26xx-demo.bin
Connecting to target...
*** sending synch sequence
*** GetChipId command (0x28)
*** received 6 bytes
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
[128, 2, 240, 0]
Warning: unrecognized chip ID 0xf000
Writing 131072 bytes starting at address 0x0
*** Download command (0x21)
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
*** Send Data (0x24)0x0
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
*** Send Data (0x24)
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
    Write done                                
Verifying by comparing CRC32 calculations.
*** CRC32 command(0x27)
*** received 6 bytes
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
*** Reset command (0x25)
ERROR: NO CRC32 match: Local = 0x909cd098, Target = 0xffffffff

Hi,
I am using CC1310 LAUNCHPADXL. I am trying to flash cc26xx-demo code of Contiki.

I have modified the bootloader settings in cc26xxware/startup_files/ccfg.c file in reference to the document http://www.ti.com/lit/ug/swcu117h/swcu117h.pdf on the page:725.
BOOTLOADER_ENABLE = 0xC5 (Bootloader enable. SET_CCFG_BL_CONFIG_BOOTLOADER_ENABLE in CC13xx/CC26xxware)
BL_LEVEL = 0x1 (Active low. SET_CCFG_BL_CONFIG_BL_LEVEL in CC13xx/CC26xxware)
BL_PIN_NUMBER = 0xFF (DIO 11. SET_CCFG_BL_CONFIG_BL_PIN_NUMBER in CC13xx/CC26xxware)
BL_ENABLE = 0xC5 (Enable "failure analysis". SET_CCFG_BL_CONFIG_BL_ENABLE in CC13xx/CC26xxware)

For the Command:-
sudo make TARGET=srf06-cc26xx BOARD=launchpad/cc1310 cc26xx-demo.upload

Displayed ERROR:

While checking the Serial ports at /dev, the board gets resolved as ttyACM0 and ttyACM1.

Can you help a way to upload the code on the launchpad?

hello JelmerT:
I am using you code to flash the image to cc2650 LaunchPad, I run the cmd like this:
'''python ../../tools/cc2538-bsl/cc2538-bsl.py -e -w -v -b 115200 -e -w -v build/cc26x0-cc13x0/launchpad/cc2650/hello-world.bin --bootloader-invert-lines'''

it work not so good:
Opening port /dev/tty.usbmodemL10002881, baud 115200
Reading data from build/cc26x0-cc13x0/launchpad/cc2650/hello-world.bin
Cannot auto-detect firmware filetype: Assuming .bin
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

and if I do what you say to start boot loader by select + reset, it works well.
so how can I invoke the bootloader without togglling any pins?
I am very thank you for your any reply.
@JelmerT

@JelmerT Requesting this now as @puddly posted in zigpy/zigpy-znp#14 saying that he implemented the MT command based serial bootloader protocol (f67e8a4) implemented in CC2530 and CC2531 bootloader interface as used by the SerialBootTool (Windows only) utility by Texas Instruments mentioned in Koenkk/zigbee2mqtt#320 into zigpy-znp.

zigpy-znp is new open-source TI ZNP 3.x client written in Python that is in early development for zigpy and ZHA in Home Assistant. For more information check out https://github.com/zha-ng/zigpy-znp/

zigpy-znp developer was able to backup (read) and upgrade (write) flash his already pre-flashed Texas Instruments CC2531 adapter with a newer firmware without using any external tools, so as a standalone application to flash an adapter (in his case he tested it with a CC2531 adapter from ITead which is now known to be shipped with an older firmware from the factory)

• zigpy/zigpy-znp@f67e8a4

ip install zigpy-znp
$ python -m zigpy_znp.tools.flash_read /dev/serial/by-id/radio -o flash.bin
$ python -m zigpy_znp.tools.flash_write /dev/serial/by-id/radio -i flash.bin

Suggest considering adding the ability to upgrade these older Texas Instrument CC2530 and CC2531 coordinator firmware via cc2538-bsl to make it also compatible with those as well.

(TI's rialBootTool which also comes with IAR can otherwise be download separately here http://processors.wiki.ti.com/index.php/File:SerialBootTool_1_3_2.zip ).

Using CC1310 on a SMARTRF06, git rev a38cfc889ebb2197b8775c79763e04c592fd4b77, I get:

~/contiki/examples/hello-world$ make TARGET=srf06-cc26xx BOARD=srf06/cc13xx hello-world.upload PORT=/dev/ttyUSB1
  CC        ../../cpu/cc26xx-cc13xx/lib/cc13xxware/startup_files/ccfg.c
  CC        ../../cpu/cc26xx-cc13xx/./ieee-addr.c
  AR        contiki-srf06-cc26xx.a
  CC        ../../cpu/cc26xx-cc13xx/./fault-handlers.c
  CC        ../../cpu/cc26xx-cc13xx/lib/cc13xxware/startup_files/startup_gcc.c
  CC        hello-world.c
  LD        hello-world.elf
arm-none-eabi-objcopy -O binary --gap-fill 0xff hello-world.elf hello-world.bin
python ../../tools/cc2538-bsl/cc2538-bsl.py -e -w -v -p /dev/ttyUSB1 hello-world.bin
Opening port /dev/ttyUSB1, baud 115200
Reading data from hello-world.bin
Cannot auto-detect firmware filetype: Assuming .bin
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'
make: *** [hello-world.upload] Error 1
rm obj_srf06-cc26xx/startup_gcc.o hello-world.co obj_srf06-cc26xx/fault-handlers.o

(I manually set the baud to 115200 which I believe is correct. 500000 failed the same way.)

Hi all,

I follow the instruction on Zolertia/Resources/wiki/6lbr
then I have a problem while flash the 6lbr image to the Zolertia Ethernet IoT Gateway.

user@ubuntu:~/6lbr/examples/6lbr$ ls -l /dev/ttyUSB0 
crw-rw---- 1 root dialout 188, 0 Dec  8 03:50 /dev/ttyUSB0
user@ubuntu:~/6lbr/examples/6lbr$ python ../../tools/cc2538-bsl/cc2538-bsl.py -e -w -v bin_zoul/cetic_6lbr_smart_bridge.bin
Opening port /dev/ttyUSB0, baud 500000
Reading data from bin_zoul/cetic_6lbr_smart_bridge.bin
Connecting to target...
ERROR: Can't connect to target. Ensure boot loader is started. (no answer on synch sequence)

i have also tryed with config the -p /dev/ttyUSB0 and -b 115200, it does not work either.

Is there anyone expertise could help me to solve the problem?

Thanks a lot!

ps: but it can be flashed with the contiki/examples/hello-world as a zoul when make TARGET=zoul MOTES=/dev/ttyUSB0 hello-world.upload login

GetChipID only reads the chip id at the moment. (Which is 0xb964 apparently)

We could expand this to also read the info page, which would give us SRAM size, Flash size and both IEEE addresses.

This would in turn give us the possibility to better check the boot loader backdoor enable bit.

Figure out how to do some kind of unit testing.

This will be pretty complicated since real hardware is probably needed to do all the tests (and there's currently 3 different supported platforms).

See #41 and #89
Time for a (non-binding) poll:

Hi there,

Ive been using the script to program the cc2538 for a while now and it works great.

I have a little issue when programming the chip. After the chip goes into the bootloader the first attempt seems to always fail. Here are the traces below for the first and second attempt. The second attempt succeded.

First:

python ../../../tools/cc2538-bsl/cc2538-bsl.py -e -w -v -V -b 115200 udp-client.bin                           
Opening port /dev/ttyUSB0, baud 115200                                                                        
Reading data from udp-client.bin                             
Connecting to target...                      
*** sending synch sequence            
Unrecognised response 0x0 to Synch (0x55 0x55)                                                                
ERROR: Can't connect to target. Ensure boot loader is started. (no answer on synch sequence)     

Second:

python ../../../tools/cc2538-bsl/cc2538-bsl.py -e -w -v -V -b 115200 udp-client.bin
Opening port /dev/ttyUSB0, baud 115200
Reading data from udp-client.bin
Connecting to target...
*** sending synch sequence
*** GetChipId command (0x28)
*** received 6 bytes
*** GetStatus command (0x23)
*** received 3 bytes
Command Successful
    Target id 0xb964, CC2538
Erasing 524288 bytes starting at address 0x200000
*** Erase command(0x26)
*** GetStatus command (0x23)
*** received 3 bytes
[... etc]

I tried putting delays between the reset and the programming and also tried to flush the serial port before the programming starts.

Im using Ubuntu 14.04 64bit.

Let me know if you have any ideas.

Thanks.

Thx for the great script.

In my opinion/perception the CC2652P is not yet fully supported by your script.
The chip is identified as CC1352P and "Verify" is not correctly implemented for it.

Are there any plans to add this features?

O.

Any chance of adding support for cc2530/cc2531?

python cc2538-bsl.py -h
/Users/w/cc2538-bsl/cc2538-bsl.py:971: SyntaxWarning: "is not" with a literal. Did you mean "!="?
if int(value) % int(device.page_size) is not 0:
/Users/w/cc2538-bsl/cc2538-bsl.py:976: SyntaxWarning: "is not" with a literal. Did you mean "!="?
if int(value, 16) % int(device.page_size) is not 0:
Traceback (most recent call last):
File "/Users/w/cc2538-bsl/cc2538-bsl.py", line 59, in
from intelhex import IntelHex
File "/Users/w/.pyenv/versions/3.9.0b5/lib/python3.9/site-packages/intelhex/init.py", line 44, in
from intelhex.compat import (
File "/Users/w/.pyenv/versions/3.9.0b5/lib/python3.9/site-packages/intelhex/compat.py", line 60, in
array_tobytes = getattr(array.array, "tobytes", array.array.tostring)
AttributeError: type object 'array.array' has no attribute 'tostring'

Running cc2538-bsl on Mac OS with python 3.7 provides the following errors:

"ERROR: string argument without an encoding"

This seems to be related to the handling of bytearrays in recent python versions. If I understand it correctly recent python version require the encoding to be explicitly stated in the bytearray function if the parameter is a string. This seems to be the case in the script. When providing an encoding (tried with 'utf8'), the error disappeared.

Found this interesting line in the Tech Ref Manual of the CC1350

If the backdoor pin configuration matches one of the UART0 or SSI0 pins, the external user must deassert the backdoor signal before transmitting on the UART0 or SSI0 interface.

Pretty sure this wasn't possible with the CC2538, but probably it is with the CC26xx. So if we use the RX line for the bootloader enable pin, we could make entering the bootloader slightly easier. Instead of having to do the select + reset finger dance, you'd just need to reset the chip.

On the Raspberry Pi (raspbian wheezy) it fails to flash a RE-Mote/Firefly as follows:

contiki/tools/cc2538-bsl $ python cc2538-bsl.py -b 115200 -e -w -v -a 0x00202000 /home/pi/zoul-demo.bin
Opening port /dev/ttyUSB0, baud 115200
Reading data from /home/pi/zoul-demo.bin
Firmware file: Raw Binary
Connecting to target...
CC2538 PG2.0: 512KB Flash, 32KB SRAM, CCFG at 0x0027FFD4
Primary IEEE Address: 06:15:AB:25:00:12:4B:00
Erasing 524288 bytes starting at address 0x00200000
ERROR: Timeout waiting for ACK/NACK after 'Erase memory (0x26)'

I followed the requirements as stated here. Any clue?

With the added support for CC26XX and CC13XX chips in version 1.2, the original name of the script and this repository is slightly outdated.

Do we need a new name? If yes, which one?

Renaming a github repo looks pretty painless, all existing links should still work afterwards. Makefiles in Contiki would need to be updated, but this would be possible to tackle in one PR without breaking anything.

On Zolertia Zoul Firefly, with cc2538-bsl 4340542:

$ ./tools/cc2538-bsl/cc2538-bsl.py -V -b 115200 -e
Opening port /dev/ttyUSB0, baud 115200
Connecting to target...
*** sending synch sequence
Traceback (most recent call last):
  File "./tools/cc2538-bsl/cc2538-bsl.py", line 1040, in <module>
    if not cmd.sendSynch():
  File "./tools/cc2538-bsl/cc2538-bsl.py", line 369, in sendSynch
    return self._wait_for_ack("Synch (0x55 0x55)", 2)
  File "./tools/cc2538-bsl/cc2538-bsl.py", line 253, in _wait_for_ack
    % (info,))
CmdException: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

$ ./tools/cc2538-bsl/cc2538-bsl.py -V -b 115200 -a 0x0 -l 0x20000 -r rom.bin
Opening port /dev/ttyUSB0, baud 115200
Connecting to target...
*** sending synch sequence
Traceback (most recent call last):
  File "./tools/cc2538-bsl/cc2538-bsl.py", line 1040, in <module>
    if not cmd.sendSynch():
  File "./tools/cc2538-bsl/cc2538-bsl.py", line 369, in sendSynch
    return self._wait_for_ack("Synch (0x55 0x55)", 2)
  File "./tools/cc2538-bsl/cc2538-bsl.py", line 253, in _wait_for_ack
    % (info,))
CmdException: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

The common condition to these errors seemed to be the lack of input file to read, which made me test if this was a timing issue with the following patch:

diff --git a/cc2538-bsl.py b/cc2538-bsl.py
index dd912de..5715d36 100755
--- a/cc2538-bsl.py
+++ b/cc2538-bsl.py
@@ -1035,6 +1035,8 @@ if __name__ == "__main__":
             mdebug(5, "Reading data from %s" % args[0])
             firmware = FirmwareFile(args[0])

+        time.sleep(0.1)
+
         mdebug(5, "Connecting to target...")

         if not cmd.sendSynch():

And it now works. This is not a clean fix, but only a workaround indicating where to look. That's why I have opened an issue and not a pull request for this.

Is there a way to hardwire CC1350 sensor tag to interact with this script ?

With #90 we can now add the proper cmd line argument for the script

Hi Jelmer,

First of all, thanks a lot! for the useful tool. I am facing a small issue that the tool exists abruptly from the main loop: "while lng > trsf_size:" The exit always occurs while writing the second last packet (i.e. when lng = 264) with the following error:
ERROR: ord() expected string of length 1, but NoneType found

However, as it happens while writing the second last packet, program is correctly uploaded most of the time although verification never starts.

@JelmerT Jelmer, I've been thinking perhaps we should bump version number to 2.0 😄 and open a pull on Contiki?

There needs to be a better way to check which version of the script you're using. see #77
Getting the version from the git repo isn't really working.

Hello all,
I'm getting this Error
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'
when am flashing the code second time
I will explain step by step:

1. I have 10 openMote-B Rev-1.4
2. I started working with RIOT. I'm confused where to and how to start so I mailed to RIOT Developer's
   they said as you are a beginner you can try RIOT--TUTORIALS like that
   https://github.com/RIOT-OS/Tutorials
3. So I started working with the TUTORIALS, I have installed the necessary packages
4. I have connected only one OpenMote-B to my PC having ubuntu18.04
5. I went to this Directory /home/Tutorial/Task-01
6. I Provided This Comment ** BOARD=openmote-B make flash all term** For tranfer the program into
   my openmote-B
7. The Code was transferred successfully and a terminal Opened there I gave PS, Reboot and Help
   Command that was also working well
8. Now i went the Task-02 Directory /home/Tutorial/Task-02
   Here I gave this command BOARD=openmote-B make flash all term For tranfer the TASK-02 program to my openmote-B
   But this Time I got the Following Error
   ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

I got to know by my analysis there is problem with the Bootloder kind of things only
openMote-B developer Mr.per tuset he said the following
Hello,
You have probably flahsed a RIOT image that has the wrong pin configuration for the bootloader in the Flash. To fix it:

1. Use a JTAG probe to flash an empty image or am image with the proper bootloader Flash settings
2. Change the RIOT image to make sure that the same bootloader Flasg setting are used
   For your reference, the pin that is used to trigger the bootloader on the OpenMote-B board is PORTA PIN7 using a low level.
   Kind regards,
   Pere
   I analysed and found the below line
   #define CCA_BACKDOOR_PORT_A_PIN (6) /**< BSL_BOOT Pin */
   by Pere Tuset approval i changed the pin number 6 into 7

but then also not working and again he said like this
Hello,
This is really unfortunate.
I am not very familiar with RIOT, but there must be something else going on.
For example the CCA configuration is stored in Flash as described in this file -> https://github.com/RIOT-OS/RIOT/blob/master/cpu/cc2538/vectors.c
The specific line is : 0xe0ffffff | (CCA_BACKDOOR_ENABLE << 28) | (CCA_BACKDOOR_ACTIVE_LEVEL << 27) | (CCA_BACKDOOR_PORT_A_PIN << 24)
If done the math and it matches the configuration I am unsing on my projects, so that should work.
One thing to try is using a slower baudrate (i.e. 400000) just in case.

but I'am confused where to change what to change i did so many thing
i have total 10 in that 5 boards are locked remaining 5 boards are there i'm fearing to check more things
please help me out of this

(I got the idea to recover the other 5 openmote-B board using JTAG programmer I'm going to make it work)

But i sould work with other boards by solving this error
please help to solve this error

Thanks

https://github.com/JelmerT/cc2538-bsl/blob/master/cc2538-bsl.py#L217,
if isinstance(self.sp, serial.serialposix.Serial): may cause some platform issue, as on windows, it should be serialwin32, other than serialposix