If the flash has been written several times, list_filesystem will lose the ability to read the filenames. If you read those files via UART some magic on the cc3200 is done, so the files are found even in that state. If you are using a flashdump this doesn't work. You may dump the file by index in that case.

So we need to find out what this magic does and implement it inside the tool.

This isn't really a problem with the tool itself as much as it's a problem with drivers and confusion on macOS with new updates.

I'm using the CC3200 Launchpad, not a toniebox, so my use-case is probably different here,
but basically when I connect the launchpad, the device doesn't show up in the /dev directory, so I can't pass a /dev port to cc3200tool.

My fix (which I have not made into a PR, since I don't know if this is a common issue or if it fits the use case) is to use pyftdi as a backend for pyserial so that I can instead pass a custom ftdi url (ftdi://ti:launchpad:cc3101/2) to the cc3200tool to access the serial port directly as a usb device. I had to change the serial.Serial() instantiation into a factory function call to serial_for_url, which takes pretty much the same arguments, but better supports the device url format.

Just thought I'd leave this here in case anyone ran into a similar issue. And was interested.

To be clear, the cc3200 still showed up with lsusb with the name USB <-> JTAG/SWD device initially, there was just no corresponding /dev port open.

My fork is here.

I'm on Windows 10 and tend to use the git bash for everything I do cmdline wise.

Trying to flash the OTA Service pack, I found that due to the combination, it interprets the cc_filename as a whole (local) system path, instead of a target filepath.

This is reproducable, even when explicitly using "cc_filename=/sys/servicepack.ucf" as argument and with all kinds of combinations of single and double quotes around the name.

In all instances, git bash seems to expand the path and feeds it to the cc3200tool.
So this may be more of a git bash problem, but maybe something could be done to prevent this here as well?

cc3200tool is not (yet) compatible with python 3.10 - switched to 3.8 resolved this:

python cc.py -p /dev/ttyUSB0 --reset dtr read_all_files ./2022-11-12 read_flash backup-box.bin 2022-12-12 07:22:10,439 -- Connecting to target... 2022-12-12 07:22:12,813 -- timed out while waiting for ack 2022-12-12 07:22:13,083 -- Connected, reading version... 2022-12-12 07:22:13,094 -- connected to target 2022-12-12 07:22:13,094 -- Version: CC3x00VersionInfo((0, 4, 1, 2), (0, 0, 0, 0), (0, 0, 0, 0), (0, 0, 0, 0), (16, 0, 0, 0)) 2022-12-12 07:22:13,095 -- This is a CC3200 device 2022-12-12 07:22:13,095 -- Switching to NWP bootloader... 2022-12-12 07:22:13,110 -- Switching UART to APPS... 2022-12-12 07:22:13,126 -- Resetting communications ... 2022-12-12 07:22:14,406 -- Uploading rbtl3100s.dll... 2022-12-12 07:22:14,407 -- Getting storage list... Traceback (most recent call last): File "/opt/TonieBox-Hack/cc3200tool/cc.py", line 1227, in <module> main() File "/opt/TonieBox-Hack/cc3200tool/cc.py", line 1177, in main cc.switch_to_nwp_bootloader() File "/opt/TonieBox-Hack/cc3200tool/cc.py", line 880, in switch_to_nwp_bootloader self._raw_write(0, dll_data('rbtl3100s.dll')) File "/opt/TonieBox-Hack/cc3200tool/cc.py", line 731, in _raw_write while sent < len(data): TypeError: object of type 'NoneType' has no len()

I tried using write_flash to put a backup of my bricked toniebox onto a replacement board, but it doesn't work:

cc3200tool -p /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A4001LXA-if00-port0 write_flash tonieboxCC3200backup.bin 
Traceback (most recent call last):
  File "/usr/local/bin/cc3200tool", line 33, in <module>
    sys.exit(load_entry_point('cc3200tool==1.2.0', 'console_scripts', 'cc3200tool')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/cc3200tool-1.2.0-py3.11.egg/cc3200tool/cc.py", line 1357, in main
  File "/usr/local/lib/python3.11/dist-packages/cc3200tool-1.2.0-py3.11.egg/cc3200tool/cc.py", line 634, in __init__
TypeError: expected str, bytes or os.PathLike object, not BufferedReader

list_filesystem, read_flash, read_file, even write_file all work just fine. So I used write_file at first (to switch certs for teddycloud). Now I wanted to start playing around with firmware patches, so I wanted to make sure my backups can be applied, and dug in to find the issue.

I read that this errormessage comes when a file has already be open (and might not yet have finished closing) when it's attempted to be opened again.

first some debug output: - I added

print(args.image_file)

in line 1357 (before the call to CC3200Connection())

<_io.BufferedReader name='tonieboxCC3200backup.bin'>

since a string is expected, I tried passing image_file=args.image_file.name instead of image_file=args.image_file. But this gave me these errors:

Traceback (most recent call last):
  File "/home/thefool/cc3200tool/cc3200tool/cc.py", line 1442, in <module>
    main()
  File "/home/thefool/cc3200tool/cc3200tool/cc.py", line 1411, in main
    cc.write_flash(command.image_file, not command.no_erase)
  File "/home/thefool/cc3200tool/cc3200tool/cc.py", line 1193, in write_flash
    self._erase_blocks(0, count, storage_id=STORAGE_ID_SFLASH)
  File "/home/thefool/cc3200tool/cc3200tool/cc.py", line 802, in _erase_blocks
    self._send_packet(command, timeout=self._erase_timeout)
  File "/home/thefool/cc3200tool/cc3200tool/cc.py", line 733, in _send_packet
    self.port.write(len_blob + csum + data)
    ^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'write'

-> self.port.write() didn't have a serial port to write to!

I then double-checked the code:

using write_flash always gets you into the if not args.image_file is None: in line 1357, but serial ports only get opened and communication started in the else part of that check!
I did a quick check before then verifying my suspicion, and changing the if check to if False: to guarantee me landing in the else indeed worked!

My suspicion was correct: you just shouldn't have named the argument image_file (of type Filetype('rb'))

248

parser_write_flash.add_argument(
        "image_file", type=argparse.FileType('rb'),
        help="gang image file prepared with Uniflash")

because that's already a general option (of type string):

183:

parser.add_argument(
        "-if", "--image_file", type=str, default=None,
        help="Use a image file instead of serial link (read)")

Solution

rename image_file to gang_image_file or something else in these lines:
249: "image_file", type=argparse.FileType('rb'),
1410: cc.write_flash(command.image_file, not command.no_erase)

that's it!

python3 cc3200tool/cc3200tool/cc.py -p /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A4001LXA-if00-port0 write_flash tonieboxCC3200backup.bin 
2023-12-11 02:54:53,334 -- Connecting to target...
2023-12-11 02:54:55,595 -- timed out while waiting for ack
2023-12-11 02:54:58,789 -- timed out while waiting for ack
2023-12-11 02:54:59,065 -- Connected, reading version...
2023-12-11 02:54:59,075 -- connected to target
2023-12-11 02:54:59,076 -- Version: CC3x00VersionInfo((0, 4, 1, 2), (0, 0, 0, 0), (0, 0, 0, 0), (0, 0, 0, 0), (16, 0, 0, 0))
2023-12-11 02:54:59,077 -- This is a CC3200 device
2023-12-11 02:54:59,077 -- Switching to NWP bootloader...
2023-12-11 02:54:59,091 -- Switching UART to APPS...
2023-12-11 02:54:59,106 -- Resetting communications ...
2023-12-11 02:55:02,378 -- timed out while waiting for ack
2023-12-11 02:55:02,658 -- Uploading rbtl3100s.dll...
2023-12-11 02:55:02,838 -- Getting storage list...
2023-12-11 02:55:03,553 -- APPS version: CC3x00VersionInfo((0, 4, 0, 2), (0, 0, 0, 0), (0, 0, 0, 0), (0, 0, 0, 0), (16, 0, 0, 0))
2023-12-11 02:56:32,278 -- Getting storage list...
2023-12-11 02:57:38,087 -- Getting storage list...
2023-12-11 02:57:38,119 -- All commands done, bye.

🥳

As mentined in my forum post and confirmed by SciLor/badbee, the slashes might be wrong when using windows (even from a git bash, apparently).

It should be easy to do a replace at the given line to mitigate that "issue" (although as also mentined in the post, the box seems to be able to boot, but I have yet to finish the initialisation).

Either a .replace("\\","/") or
import posixpath and then posixpath.normpath(ccpath)
should do the trick.