travisgoodspeed / goodfet Goto Github PK

The data types used in goodfet files are of 3 kinds:

-stdint ones (uint8_t, etc)
-normal C ones (unsigned char, etc)
-some more (u8, etc)

My proposition is to use stdint types in every file.

Is there anything unknown to me that would prevent doing that?

the updater looks for the prebuilt images in http://goodfet.sourceforge.net/dist/. There is no goodthopter12.hex there. It lives in the github repo at https://raw.githubusercontent.com/travisgoodspeed/goodfet/master/firmware/prebuilt/goodthopter12.hex

A couple easy ways to fix this, but I'm not sure which way makes most sense for the project:

1. just copy goodthopter12.hex to the sf dist
2. copy all the files from dist to github firmware/prebuilt and change the FIRMWARE_BASEURL in goodfet.bsl
3. modify goodfet.bsl to support multiple firmware sources and search them all before failing - yuk

Hello,

Trying to program a msp430g2553 via sbw, since the bsl pins are a mess if you want to use a normal UART simultaneously...

This is the message I get:

DEBUG ERROR: Haven't got ASM to flash-pulse SBW.

I see there is no code for :
//Pulse TCLK
//sbw430_tclk_flashpulses(35); //35 standard

Since the TCLK line is the same as SBWTCK, I tried to replace this line by:

//Pulse TCLK
jtag430_tclk_flashpulses(35); //35 standard

I have set APP=0x17 and MSP430APP=0x17 in GoodFETMSP430.py to activate SBW

But the goodfet.msp430 dangeroustest fails like this. Any idea? Thanks.

grx@grxmint ~ $ goodfet.msp430 dangeroustest
Identified as 89. < -- I added this line as a debug to check that some communication happens.
Running an erase/program test.
Testing None.
Testing RAM from 200 to 210.
Failed to write 0xffff to 0x0200
Fault at 000200
Failed to write 0xffff to 0x0201
Fault at 000201
Failed to write 0xffff to 0x0202
Fault at 000202
Failed to write 0xffff to 0x0203
Fault at 000203
Failed to write 0xffff to 0x0204
Fault at 000204
Failed to write 0xffff to 0x0205
Fault at 000205
Failed to write 0xffff to 0x0206
Fault at 000206
Failed to write 0xffff to 0x0207
Fault at 000207
Failed to write 0xffff to 0x0208
Fault at 000208
Failed to write 0xffff to 0x0209
Fault at 000209
Failed to write 0xffff to 0x020a
Fault at 00020a
Failed to write 0xffff to 0x020b
Fault at 00020b
Failed to write 0xffff to 0x020c
Fault at 00020c
Failed to write 0xffff to 0x020d
Fault at 00020d
Failed to write 0xffff to 0x020e
Fault at 00020e
Failed to write 0xffff to 0x020f
Fault at 00020f
Testing identity consistency.
Testing flash erase.
ffe0 unerased, equals 0000
ffe1 unerased, equals 0000
ffe2 unerased, equals 0000
ffe3 unerased, equals 0000
ffe4 unerased, equals 0000
ffe5 unerased, equals 0000
ffe6 unerased, equals 0000
ffe7 unerased, equals 0000
ffe8 unerased, equals 0000
ffe9 unerased, equals 0000
ffea unerased, equals 0000
ffeb unerased, equals 0000
ffec unerased, equals 0000
ffed unerased, equals 0000
ffee unerased, equals 0000
ffef unerased, equals 0000
fff0 unerased, equals 0000
fff1 unerased, equals 0000
fff2 unerased, equals 0000
fff3 unerased, equals 0000
fff4 unerased, equals 0000
fff5 unerased, equals 0000
fff6 unerased, equals 0000
fff7 unerased, equals 0000
fff8 unerased, equals 0000
fff9 unerased, equals 0000
fffa unerased, equals 0000
fffb unerased, equals 0000
fffc unerased, equals 0000
fffd unerased, equals 0000
fffe unerased, equals 0000
Testing flash write.
ffe0 unset, equals 0000
ffe1 unset, equals 0000
ffe2 unset, equals 0000
ffe3 unset, equals 0000
ffe4 unset, equals 0000
ffe5 unset, equals 0000
ffe6 unset, equals 0000
ffe7 unset, equals 0000
ffe8 unset, equals 0000
ffe9 unset, equals 0000
ffea unset, equals 0000
ffeb unset, equals 0000
ffec unset, equals 0000
ffed unset, equals 0000
ffee unset, equals 0000
ffef unset, equals 0000
fff0 unset, equals 0000
fff1 unset, equals 0000
fff2 unset, equals 0000
fff3 unset, equals 0000
fff4 unset, equals 0000
fff5 unset, equals 0000
fff6 unset, equals 0000
fff7 unset, equals 0000
fff8 unset, equals 0000
fff9 unset, equals 0000
fffa unset, equals 0000
fffb unset, equals 0000
fffc unset, equals 0000
fffd unset, equals 0000
fffe unset, equals 0000
Tests complete, erasing.

Hello,

when enabled, the jtag430 app is included twice because of this typo:

joe@nuc:~/goodfet/firmware$ git diff Makefile

diff --git a/firmware/Makefile b/firmware/Makefile
index e7138b7..4eebe5c 100644
--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -160,7 +160,7 @@ ifeq ($(filter jtag430x2, $(config)), jtag430x2)
                libs+= apps/jtag/jtag430asm.o
        endif
        #add in the jtag430 app if not already
-       ifneq ($(filter apps/jtag/jtag430.o, $(apps)), apps/jtag/jtag430.0)
+       ifneq ($(filter apps/jtag/jtag430.o, $(apps)), apps/jtag/jtag430.o)
                apps+= apps/jtag/jtag430.o
                hdrs+= jtag430.h
        endif

Thank you for applying the patch.

using instructions from here

root@kali:/opt/goodfet/firmware# make install
cp platforms/apimote2.h include/config.h
./gen_builddate_h
./gen_apps  monitor.h spi.h ccspi.h
msp430-gcc -mmcu=msp430f2618 -Wall -O1 -fno-strict-aliasing -g   -Duseuart1 -Dapimote -Dmsp430f2618 -Dapimote2 -Dplatform=apimote2 -Dboard=apimote4  -I include -I platforms -Duseuart1 -Dapimote   -c -o lib/apps.o lib/apps.c
msp430-gcc -mmcu=msp430f2618 -Wall -O1 -fno-strict-aliasing -g   -Duseuart1 -Dapimote -Dmsp430f2618 -Dapimote2 -Dplatform=apimote2 -Dboard=apimote4  -I include -I platforms -mmcu=msp430f2618   goodfet.o lib/msp430f2618.o lib/command.o lib/dco_calib.o lib/apps.o lib/msp430.o lib/arduino.o apps/monitor/monitor.o apps/spi/spi.o apps/radios/ccspi.o   -o goodfet
msp430-objcopy goodfet -O ihex goodfet.hex
#Note that 'make install' no longer erases the chip.
#Use 'make reinstall' if you want that.
goodfet.bsl --speed=38400 -p goodfet.hex
Unknown board specified.  Try board=goodfet41 if unsure.
Press Ctrl+C to cancel, or Enter to continue using unknown board.board=apimote2
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 2.13 (Device ID: f26f)
Changing baudrate to 38400 ...
Unknown board specified.  Try board=goodfet41 if unsure.
Press Ctrl+C to cancel, or Enter to continue using unknown board.board=apimote4
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Invoking BSL...
Transmit default password ...
Traceback (most recent call last):
  File "/usr/local/bin/goodfet.bsl", line 1987, in <module>
    main(0);
  File "/usr/local/bin/goodfet.bsl", line 1905, in main
    speed=speed,
  File "/usr/local/bin/goodfet.bsl", line 1166, in actionStartBSL
    self.txPasswd(self.passwd)                  #transmit password
  File "/usr/local/bin/goodfet.bsl", line 1136, in txPasswd
    wait=wait)           #if wait is 1, try to sync forever
  File "/usr/local/bin/goodfet.bsl", line 801, in bslTxRx
    rxFrame = self.comTxRx(cmd, dataOut, len(dataOut))  #Send frame
  File "/usr/local/bin/goodfet.bsl", line 480, in comTxRx
    rxHeader, rxNum = self.comRxHeader()        #receive header
  File "/usr/local/bin/goodfet.bsl", line 386, in comRxHeader
    if not hdr: raise BSLException("Timeout")
__main__.BSLException: Timeout
make: *** [Makefile:357: install] Error 1
root@kali:/opt/goodfet/firmware# make install
cp platforms/apimote2.h include/config.h
./gen_builddate_h
./gen_apps  monitor.h spi.h ccspi.h
msp430-gcc -mmcu=msp430f2618 -Wall -O1 -fno-strict-aliasing -g   -Duseuart1 -Dapimote -Dmsp430f2618 -Dapimote2 -Dplatform=apimote2 -Dboard=apimote4  -I include -I platforms -Duseuart1 -Dapimote   -c -o lib/apps.o lib/apps.c
msp430-gcc -mmcu=msp430f2618 -Wall -O1 -fno-strict-aliasing -g   -Duseuart1 -Dapimote -Dmsp430f2618 -Dapimote2 -Dplatform=apimote2 -Dboard=apimote4  -I include -I platforms -mmcu=msp430f2618   goodfet.o lib/msp430f2618.o lib/command.o lib/dco_calib.o lib/apps.o lib/msp430.o lib/arduino.o apps/monitor/monitor.o apps/spi/spi.o apps/radios/ccspi.o   -o goodfet
msp430-objcopy goodfet -O ihex goodfet.hex
#Note that 'make install' no longer erases the chip.
#Use 'make reinstall' if you want that.
goodfet.bsl --speed=38400 -p goodfet.hex
Unknown board specified.  Try board=goodfet41 if unsure.
Press Ctrl+C to cancel, or Enter to continue using unknown board.board=goodfet41
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 2.13 (Device ID: f26f)
Changing baudrate to 38400 ...
Unknown board specified.  Try board=goodfet41 if unsure.
Press Ctrl+C to cancel, or Enter to continue using unknown board.board=apimote1
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Invoking BSL...
Transmit default password ...
Traceback (most recent call last):
  File "/usr/local/bin/goodfet.bsl", line 1987, in <module>
    main(0);
  File "/usr/local/bin/goodfet.bsl", line 1905, in main
    speed=speed,
  File "/usr/local/bin/goodfet.bsl", line 1166, in actionStartBSL
    self.txPasswd(self.passwd)                  #transmit password
  File "/usr/local/bin/goodfet.bsl", line 1136, in txPasswd
    wait=wait)           #if wait is 1, try to sync forever
  File "/usr/local/bin/goodfet.bsl", line 801, in bslTxRx
    rxFrame = self.comTxRx(cmd, dataOut, len(dataOut))  #Send frame
  File "/usr/local/bin/goodfet.bsl", line 480, in comTxRx
    rxHeader, rxNum = self.comRxHeader()        #receive header
  File "/usr/local/bin/goodfet.bsl", line 386, in comRxHeader
    if not hdr: raise BSLException("Timeout")
__main__.BSLException: Timeout
make: *** [Makefile:357: install] Error 1

I have the API Mote V4 but can not find documentation on just how to flash these...

Hi,

I have an ApiMote that probably has one revision of the CC2420 with the problem you mention at line 170 of file /firmware/apps/radios/ccspi.c:

This_ reads too far on some CC2420 revisions, but on others it works fine.  It probably has to do with whether FIFO drops before or after the SPI clocking. 

software fix is to reset the CC2420 between packets.  This works, but a better solution is desired.

How can I add this reset command to fix the issue?

Thank you for you support!

Federico

Hello,
I'm actually trying to learn how i could do a man in the middle attack and i got the facedancers for this.
Then i saw the ttwe proto who seemed quite useful so i tried to use it wiring a mouse to a facedancer21 to my pc and another pc to another facedancer21 to my pc. And after configuring, i launched the TTWE_host.py, then the TTWE_client and i get this error message :

`$ sudo python3 client/TTWEClient.py -v

Facedancer reset
GoodFET monitor initialized
MAXUSB initialized
MAXUSB enabled
MAXUSB revision 19
Attempting connection
MAXUSB connected device TTWEClient Device
Done connecting
Traceback (most recent call last):
File "client/TTWEClient.py", line 287, in
u.service_irqs()
File "/home/zanatoos/Documents/ttwe-proto/client/MAXUSBApp.py", line 225, in service_irqs
self.connected_device.before_handle()
File "client/TTWEClient.py", line 115, in before_handle
self.snd_ep1.flush()
BrokenPipeError: [Errno 32] Broken pipe
`
I didn't forget to launch the script to create the fifo pipes so i thought it was due ot permission, so i tried to create it with a sudo and without a sudo and it didnt work so i used chmod on those pipes but it didnt fix anything either.

Any help would be very appreciated,
Thanks

EDIT : The problem has been fixed by editing goodfet.py, replacing occurences of 'self.serialport.setTimeout();' by 'self.serialport.timeout=;' and by plugging the client first.

An attribute device_vendor for object USBDevice is used, although it does not exist. So e.g. USBMassStorage crashes.

See:
https://github.com/travisgoodspeed/goodfet/blob/master/client/USBDevice.py#L157

The ccspi application implements CCSPI_TX incorrectly. It uses the first byte of the data to send as length of the message including that byte itself, however according to the documentation, the first byte of the packet (PHR) denotes the length of the rest of the packet (PSDU) (see http://www.ti.com/lit/ds/symlink/cc2420.pdf 16.2 - Length Field "Note that the length field does not include
the length field itself").
Therefore the last byte of the packet is not written to the TX_FIFO.

This is the buggy code:

ccspitrans8(CCSPI_TXFIFO);
for(i=0;i<cmddata[0];i++)
    ccspitrans8(cmddata[i]);

There are two ways to overcome this problem:

1. Use autocrc mode, which mean the last two bytes are the CRC and the transceiver will generate them automatically and ignore the last bytes in the TX_FIFO.
2. Manually put the packet in the TX_FIFO:

goodfet.writecmd(goodfet.CCSPIAPP,0x03,1,[0x9]) # flush
goodfet.writecmd(goodfet.CCSPIAPP,0x03,len(pkt)+1,[0x3e] + map(ord, pkt)) # write TX fifo
goodfet.writecmd(goodfet.CCSPIAPP,0x03,1,[0x4]) # tx on
time.sleep(0.3) # wait SFD?

I haven't tested the workarounds because something is wrong with my setup.
However, I did tried to transmit messages and then peeked the TX_FIFO RAM and found out the last byte is not there.

As this project is not under active development, I don't know if I should also submit a pull request and try to fix it.

The mspgcc project is no longer developed and has been superseded by MSP430-GCC, which is maintained by TI. We should consider moving to that compiler.

Hi,

Does the facedancer currently (21) support USB OTG? I.e. Is it a dual-role-device that can change its status as a host or device dynamically using SRP/HNP? If so, is switching roles currently supported in the Python stack?

Thanks.

Goodfet

Hello all,

I`m trying to make a build for the facedancer21 board. Everything from this page is done (https://ericeastwood.com/blog/15/facedancer21-getting-started-in-windows) but an error occurs when I try to make a build.
Do you know what is the issue an how can be fixed?
Can anybody make for me a facedance21 build?

Thanks.
Best regards!

I have build a GoodFET50 as described here http://goodfet.sourceforge.net/hardware/goodfet50/ but the support for it is missing. "Working software should be ready by early October 2011." maybe the page should be updated!
I have also a TI Launchpad 5529, so we can build a GoodFET with only 12$. 50$ from adafruit is too much.

Hey @travisgoodspeed,

I dug out from an ancient drawer, my eZ Chronos and found that it actually containas an eZ430U USB debugger. Mine contains the 'white' PCB, with revision G4 of the TUSB3410. I'm curious if it is possible to support this variant with GoodFET firmware. I know your own boards replaced this chip with the FTDI one; but overal, the MSP430 is still the same?

Maybe this board IS supported, but I couldn't find any notion anywhere on the interwebs :)

The website refers to the older SVN repo. It should be edited to refer to the Github repo.

Hello, I am hitting a problem at the above location that the program is not continuing. Do I read this line correct, that the program will only continue if it has received a packet? This will cause issues if no packets are received on the selected channel/rate/speed. Is the assumption really that there will always be a packet received? Why can't there be empty channels?

I am running Ubuntu 20.04 LTS on windows 10

I have installed pyserial numerous times and both operating systems recognize the serial ports in python.

When i run "goodfet.bsl --dumpinfo >info.txt" i get the serial port error.

Traceback (most recent call last):
File "/usr/local/bin/goodfet.bsl", line 34, in
import serial, os, glob
ImportError: No module named serial

This is mega frustrating. Why doesn't it see the serial port.

according to the goodfet documentation, the "length" packet of the goodfet protocol frames is 16 bits long.

however the handler functions use a 32 bits integer to hold the length, as in goodfet.c :

void handle(uint8_t const app,
        uint8_t const verb,
        uint32_t const len)

Is there any reason for that? I propose to change all handler functions to use uint16_t instead, but I would like to understand the issue here not to break anything.

I observed issues with macOS (Sierra). For some reason the MAX3420 is only getting repeated requests to set the USB address. The requests will begin with some desired address value and slowly increment (requests come in every few seconds) until roughly 20 attempts were made. Eventually the host gives up and stops requesting the address be set. The OSX host never asks for the descriptor, so the device remains in this unusable state indefinitely.

Has enumeration been tested on OSX? I could not find anything definite through searches, nor anyone reporting this issue.

previously (half year ago?) working goodfet software throws now the following exception:

Traceback (most recent call last):
  File "/usr/local/bin/goodfet.monitor", line 27, in <module>
    client.serInit()
  File "/home/user/soft/goodfet/client/GoodFET.py", line 133, in serInit
    self.pyserInit(port,timeout,attemptlimit);
  File "/home/user/soft/goodfet/client/GoodFET.py", line 264, in pyserInit
    self.serialport.setTimeout(12);
AttributeError: 'Serial' object has no attribute 'setTimeout'

platform is linux (debian jessie), nothing really changed, only regular security updates (including python). updating the goodfet from git does not help (same error).

hardware is working, because commenting out the line "264" makes most things work (ledtest, info, etc)

I've flashed facedancer21 for the first time with this procedure:

1. cd goodfet/firmware
2. board=facedancer21 make clean reinstall

i've had a problem with pyserial: downolading the 2.7version

• pip install "pySerial>=2.0,<=2.9999"

I was able to flash the board.
After the flashing procedure i've tried this command board=facedancer21 goodfet.monitor test with bad feebacks

Performing monitor self-test.
Warning: waiting for serial read timed out (most likely).
Echo test failed.
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
ERROR Fetched 0154, 0302
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
ERROR, P1OUT not cleared.
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
Echo test failed.
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
ERROR Fetched 0100, 0302
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
ERROR, P1OUT not cleared.
..........

What's wrong with this procedure?

I want to use the goodfet to drive a PLL, that requires simple 3-byte SPI transactions to program the chip registers, but there is no "generic" SPI client application that just pass raw buffers to the SPI app.

Hi Travis & anyone else,

Trying to tinker with hardware stuff for the first time, using an im-me as well as a goodfet42 purchased from thepihut:
https://thepihut.com/products/goodfet-v42-by-travis-goodspeed

Followed this wiring from your flickr albums (I added colouring to match my wires, just to make sure I'm not making a mistake):

I did use the power wire too, since I'm powering the device via the connected goodfet. Here's my wiring:

Hooked up to the same pins of the goodfet:

The im-me does power on, when I connect the goodfet to my mac:

So far so good. Next I wanted to try flashing the LCD Test from your tutorial (as well as the other goodfet.cc commands just to try them):
https://travisgoodspeed.blogspot.com/2010/03/im-me-goodfet-wiring-tutorial.html

The goodfet repo readme says I need to set the client, though some parts mention a board env var, so I've just set both. When I try any command, such as this one:

client=goodfet42 board=goodfet42 goodfet.cc status

I see some information from the connected im-me (which disappears if I disconnect the im-me but reconnect the goodfet without it), but none of the commands seem to work because of the chip ID errors:

sh-3.2# client=goodfet42 board=goodfet42 goodfet.cc status
Chip ID is 0xffff, implying a wiring problem.
Status: erase_busy pcon_idle cpu_halted pm0 halt_status locked oscstable overflow 

Any ideas/pointers/nudges on what I may be missing? Are my solders that bad? Any ideas which one, if that's the case?

I just noticed as I was debugging the issues I was having that enabling the DEBUG flag in goodfet.bsl makes it fail in something else than I was debugging.

My command line is: board=facedancer21 goodfet.bsl --speed=38400 -p goodfet.hex
I'm on OSX 10.9.5 with Python 2.7.11 and pyserial-3.0.1

When unsetting the baudrate my issue disappeared, so I'm assuming it's caused by pyserial, although I haven't investigated it further.

Without DEBUG:

MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 2.13 (Device ID: f26f)
Changing baudrate to 38400 ...
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Invoking BSL...
Transmit default password ...
Traceback (most recent call last):
  File "/usr/local/bin/goodfet.bsl", line 1987, in <module>
    main(0);
  File "/usr/local/bin/goodfet.bsl", line 1905, in main
    speed=speed,
  File "/usr/local/bin/goodfet.bsl", line 1166, in actionStartBSL
    self.txPasswd(self.passwd)                  #transmit password
  File "/usr/local/bin/goodfet.bsl", line 1136, in txPasswd
    wait=wait)           #if wait is 1, try to sync forever
  File "/usr/local/bin/goodfet.bsl", line 801, in bslTxRx
    rxFrame = self.comTxRx(cmd, dataOut, len(dataOut))  #Send frame
  File "/usr/local/bin/goodfet.bsl", line 480, in comTxRx
    rxHeader, rxNum = self.comRxHeader()        #receive header
  File "/usr/local/bin/goodfet.bsl", line 386, in comRxHeader
    if not hdr: raise BSLException("Timeout")
__main__.BSLException: Timeout

With DEBUG:

Debug level set to 1
Python version: 2.7.11 (default, Dec  5 2015, 23:51:51) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)]
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
using serial port '/dev/tty.usbserial-A104O89Z'
Actions ...
Invoking BSL...
Transmit default password ...
Autodetect successful: f26f -> F2x family
Current bootstrap loader version: 2.13 (Device ID: f26f)
Current bootstrap loader version: 0x0213
Changing baudrate to 38400 ...
Traceback (most recent call last):
  File "/usr/local/bin/goodfet.bsl", line 1976, in <module>
    main(1)
  File "/usr/local/bin/goodfet.bsl", line 1905, in main
    speed=speed,
  File "/usr/local/bin/goodfet.bsl", line 1256, in actionStartBSL
    self.actionChangeBaudrate(speed)            #change baudrate
  File "/usr/local/bin/goodfet.bsl", line 1392, in actionChangeBaudrate
    self.serialport.setBaudrate(baudrate)
AttributeError: 'Serial' object has no attribute 'setBaudrate'