LIBUSB error when programming CW308T-FE310

Embedded Security ChipWhisperer Software
2

Small update to make my problem clear:

The command that I’m trying to execute to program the CW308T-FE310 is :

./run_openocd.sh -p /home/alkafa/chipwhisperer/hardware/victims/firmware/simpleserial-glitch-riscv/simpleserial-glitch-CW308_FE310.elf lite jtag -- -f "/home/alkafa/chipwhisperer/openocd/fe310.cfg"

To which I get the error you see at my post, however, besides the error, jupyter also prints :

Setting up MPSSE mode… Done
running -s /home/alkafa/chipwhisperer/openocd -f cw_openocd.cfg -c ‘ftdi vid_pid 0x2b3e 0xace2’ -c ‘transport select jtag’ -f fe310.cfg -c ‘init; targets; halt; program /home/alkafa/chipwhisperer/hardware/victims/firmware/simpleserial-glitch-riscv/simpleserial-glitch-CW308_FE310.elf verify reset exit’

Then the error then :
Disabling MPSSE mode… Done

What I think is wired is that there’s nothing next to -s option. When we look at the run_openocd.sh file, the -s option should be preceded by a path which is the openocd_path, In run_openocd.sh we have :

if [[ -z $OPENOCD_PATH ]]; then
    OPENOCD_PATH=`which openocd`
fi

I put an echo in there and it prints which means that OPENOCD_PATH is indeed empty.

I don’t know what I’m doing wrong since in “run_openocd.sh” there’s a provided example which I followed correctly

UPDATE :
I figured why I get no dir before -s, it was because OpenOCD xasn’t installed (stupid error from me), anyway, it is installed now but I get this error :

Setting up MPSSE mode... Done
running /usr/local/bin/openocd -s /home/alkafa/chipwhisperer/openocd -f cw_openocd.cfg -c 'ftdi vid_pid 0x2b3e 0xace2' -c 'transport select jtag' -f /home/alkafa/chipwhisperer/openocd/fe310.cfg -c 'init; targets; halt; program /home/alkafa/chipwhisperer/hardware/victims/firmware/simpleserial-glitch-riscv/simpleserial-glitch-CW308_FE310.elf verify reset exit'

Open On-Chip Debugger 0.12.0+dev-01183-g329b10754 (2023-05-09-16:57)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
none separate
jtag
Error: failed to reset FTDI device: LIBUSB_ERROR_PIPE
Error: unable to open ftdi device with description '*', serial '*' at bus location '*'

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/alkafa/chipwhisperer/software/chipwhisperer/__init__.py", line 387, in scope
    rtn.con(**kwargs)
  File "/home/alkafa/chipwhisperer/software/chipwhisperer/capture/scopes/OpenADC.py", line 625, in con
    self.scopetype.con(sn, idProduct, bitstream, force, prog_speed, **kwargs)
  File "/home/alkafa/chipwhisperer/software/chipwhisperer/capture/scopes/openadc_interface/naeusbchip.py", line 64, in con
    found_id = self.ser.con(idProduct=nae_products, serial_number=sn, **kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/alkafa/chipwhisperer/software/chipwhisperer/hardware/naeusb/naeusb.py", line 696, in con
    self.usbtx.open(idProduct=idProduct, serial_number=serial_number, connect_to_first=True, hw_location=hw_location)
  File "/home/alkafa/chipwhisperer/software/chipwhisperer/hardware/naeusb/naeusb.py", line 391, in open
    self.handle.releaseInterface(0)
  File "/home/alkafa/.pyenv/versions/cw/lib/python3.11/site-packages/usb1/__init__.py", line 1155, in releaseInterface
    mayRaiseUSBError(
  File "/home/alkafa/.pyenv/versions/cw/lib/python3.11/site-packages/usb1/__init__.py", line 127, in mayRaiseUSBError
    __raiseUSBError(value)
  File "/home/alkafa/.pyenv/versions/cw/lib/python3.11/site-packages/usb1/__init__.py", line 119, in raiseUSBError
    raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value)
usb1.USBErrorNotFound: LIBUSB_ERROR_NOT_FOUND [-5]

Disabling MPSSE mode... Done

And I’m still lost :sweat_smile:

3

Hi,

Have you tried removing the releaseInterface code? Also, have you tried connecting to your ChipWhisperer outside of this script?

Alex

4

Hi Alex,

Yes, with releaseInterface I get error not found [-5] , without it I get error busy [-6].

I’ll try using the CW outside of the script now.

Thanks

UPDATE :

I tried what you suggested, it didn’t work. btw, my problem isn’t really connecting to CW but rather programming it, I do connect fine with CW and I use the scope functions (that are usable before programming) and they work.

5

UPDATE 2 :

Just to be sure, I tried doing the same thing with a CWLite (cw1173), it didn’t work.

I used the following command :

%%bash
/home/alkafa/chipwhisperer/openocd/run_openocd.sh -p /home/alkafa/chipwhisperer/hardware/victims/firmware/simpleserial-glitch/simpleserial-glitch-CWLITEARM.elf lite swd -- -f 'target/stm32f3x.cfg'

I got the following error :

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/chipwhisperer/__init__.py", line 387, in scope
    rtn.con(**kwargs)
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/chipwhisperer/capture/scopes/OpenADC.py", line 625, in con
    self.scopetype.con(sn, idProduct, bitstream, force, prog_speed, **kwargs)
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/chipwhisperer/capture/scopes/openadc_interface/naeusbchip.py", line 64, in con
    found_id = self.ser.con(idProduct=nae_products, serial_number=sn, **kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/chipwhisperer/hardware/naeusb/naeusb.py", line 695, in con
    self.usbtx.open(idProduct=idProduct, serial_number=serial_number, connect_to_first=True, hw_location=hw_location)
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/chipwhisperer/hardware/naeusb/naeusb.py", line 391, in open
    self.handle.claimInterface(0)
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/usb1/__init__.py", line 1146, in claimInterface
    mayRaiseUSBError(
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/usb1/__init__.py", line 127, in mayRaiseUSBError
    __raiseUSBError(value)
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/usb1/__init__.py", line 119, in raiseUSBError
    raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value)
usb1.USBErrorBusy: LIBUSB_ERROR_BUSY [-6]

Setting up MPSSE mode... Done
running /usr/local/bin/openocd -s /home/alkafa/chipwhisperer/openocd -f cw_openocd.cfg -c 'ftdi vid_pid 0x2b3e 0xace2' -c 'transport select swd' -f target/stm32f3x.cfg -c 'init; targets; halt; program /home/alkafa/chipwhisperer/hardware/victims/firmware/simpleserial-glitch/simpleserial-glitch-CWLITEARM.elf verify reset exit'

Open On-Chip Debugger 0.12.0+dev-01183-g329b10754 (2023-05-09-16:57)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
none separate
Info : FTDI SWD mode enabled
swd
Error: failed to reset FTDI device: LIBUSB_ERROR_PIPE
Error: unable to open ftdi device with description '*', serial '*' at bus location '*'

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/chipwhisperer/__init__.py", line 387, in scope
    rtn.con(**kwargs)
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/chipwhisperer/capture/scopes/OpenADC.py", line 625, in con
    self.scopetype.con(sn, idProduct, bitstream, force, prog_speed, **kwargs)
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/chipwhisperer/capture/scopes/openadc_interface/naeusbchip.py", line 64, in con
    found_id = self.ser.con(idProduct=nae_products, serial_number=sn, **kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/chipwhisperer/hardware/naeusb/naeusb.py", line 695, in con
    self.usbtx.open(idProduct=idProduct, serial_number=serial_number, connect_to_first=True, hw_location=hw_location)
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/chipwhisperer/hardware/naeusb/naeusb.py", line 391, in open
    self.handle.claimInterface(0)
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/usb1/__init__.py", line 1146, in claimInterface
    mayRaiseUSBError(
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/usb1/__init__.py", line 127, in mayRaiseUSBError
    __raiseUSBError(value)
  File "/home/alkafa/.pyenv/versions/3.11.3/lib/python3.11/site-packages/usb1/__init__.py", line 119, in raiseUSBError
    raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value)
usb1.USBErrorBusy: LIBUSB_ERROR_BUSY [-6]

Disabling MPSSE mode... Done

It’s the same error.

Any ideas ? I’ll be available to provide ant more info.

EDIT :

I just thought that I should put the script of the .cfg file in case the problem comes from there , I didn’t edit that file so maybe that’s the problem :

set _CHIPNAME riscv
jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x20000913

set _TARGETNAME $_CHIPNAME.cpu

target create $_TARGETNAME.0 riscv -chain-position $_TARGETNAME
$_TARGETNAME.0 configure -work-area-phys 0x80000000 -work-area-size 10000 -work-area-backup 1

flash bank spi0 fespi 0x20000000 0 0 0 $_TARGETNAME.0 0x10014000
init
halt
6

Are you still connected to the ChipWhisperer in another process when you try to program like this? You can’t have multiple processes connected to the same USB device.

Alex

7

Final UPADTE :

I guess I figured what causes a part of the error, it’s the execution of enable_MPSSE in the run_openocd.sh file. to solve that I just executed the command on jupyter, however it still doesn’t work (but the error is different so progress I guess) :sweat_smile:

Capture d’écran du 2023-05-10 17-30-42
Capture d’écran du 2023-05-10 17-30-421130×288 45.7 KB

8

Yeah,I figured that out

What happens is that in the ipynp file where I’m working I execute the usual code :

import chipwhisperer as cw
scope = cw.scope()

I also do :

scope.enable_MPSSE()

And then in the run_openoce.sh file we have :

enable_MPSSE() {
    python -c "import chipwhisperer as cw; scope = cw.scope(); scope.enable_MPSSE()"
    sleep 1
}

This function is later called and causes the infamous LIBUSB_ERROR_BUSY [-6]

This is solved, thanks for your time. Now I have the following :

Capture d’écran du 2023-05-10 17-39-05
Capture d’écran du 2023-05-10 17-39-051128×280 38 KB

P.S : this one is different from the last because I add a command (option -c) that should program the CWLite with a firmware

I’m using the following command :

%%sh
openocd -s /home/alkafa/chipwhisperer/openocd -f cw_openocd.cfg -c 'ftdi vid_pid 0x2b3e 0xace2' -c 'transport select swd' -f /home/alkafa/openocd/tcl/target/stm32f3x.cfg -c 'init; targets; halt; program /home/alkafa/chipwhisperer/hardware/victims/firmware/simpleserial-glitch/simpleserial-glitch-CWLITEARM.elf verify reset exit'

Even though my initial problem is on the CW308T-FE310, I figured that I should first learn how to use openOCD on the CWLite because I thought it would be easier, bur unfortunatly for me it wasn’t :sweat_smile:

When I test on the CW308T-FE310 the error is (when executing the command directly from jupyter not from run_openocd.sh) :

Open On-Chip Debugger 0.12.0+dev-01183-g329b10754 (2023-05-09-16:57)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
none separate
jtag
Info : clock speed 500 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: riscv.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: dtmcontrol is 0. Check JTAG connectivity/board power.
Warn : target riscv.cpu.0 examination failed
Info : starting gdb server for riscv.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
Error: Target not examined yet

So, if you could, what is the solution for above errors ?

Thanks in advance (I’ll still try to figure it out but any help will be really appreciated)

9

I was looking online for a solution and I find this: raspberry pi - OpenOCD throws "JTAG scan chain interrogation failed: all zeroes" error - Electrical Engineering Stack Exchange

It has nothing to do with what I’m doing but his error is really similar to ,mine since he also got :
Error: JTAG scan chain interrogation failed: all zeroes

Since it’s the first error that I get, it might be the cause of the others.
The solution that worked for him (apparently) was to modify the .cfg file of the adapter, in our case it’s the cw_openocd.cfg file if I’m not mistaken.

Could this be the cause of my problem? If yes what can I add to the file to fix the error ?

Thanks in advance.

10

Final Update :

Silly me who’s not really a pro with programming with JTAG realized that he needs a JTAG programmer.

In the documentation:

it’s stated as a compatible example that we can the Segger J-link, however this thing costs about 500 dollars :sweat_smile: . Isn’t there any other good working jtag programmers that aren’t as expensive ? can ST-link be used for example ? Also can someone confirm this is the right thing to ?

Thanks again.

11

The CW should be able to program the FE310, but it’s a more complicated target than many other microcontrollers we’ve tested in that you need to program external flash through the MCU using JTAG. I’ll see if I’m able to get that working, but if not, this JTAG programmer should work: Tigard | Crowd Supply

Alex

12

Ok, Thanks for the info.

I looked online and apparently any board with the FTDI FT232H chip should do :

If by that you mean using a code such :

import chipwhisperer as cw
fw_path = "{}/hardware/victims/firmware/simpleserial-glitch/simpleserial-glitch-{}.hex".format(CW_PATH, PLATFORM)
cw.program_target(scope, prog, fw_path)
scope.io.nrst = False
time.sleep(0.05)
scope.io.nrst = "high_z"
time.sleep(0.05)
target.flush()

I don’t think it would work since the prog is Nonetype in the case of CW308T-FE310 since in the setup_generic.py file we have :

if "STM" in PLATFORM or PLATFORM == "CWLITEARM" or PLATFORM == "CWNANO":
    prog = cw.programmers.STM32FProgrammer
elif PLATFORM == "CW303" or PLATFORM == "CWLITEXMEGA":
    prog = cw.programmers.XMEGAProgrammer
elif "neorv32" in PLATFORM.lower():
    prog = cw.programmers.NEORV32Programmer
elif PLATFORM == "CW308_SAM4S":
    prog = cw.programmers.SAM4SProgrammer
else:
    prog = None

So unfortunatly for me there isn’t any programer for the target that I want to attack. The need for a JTAG seems logical to me, I believe not having any programmer connected is the reason why I got this error :
Error: JTAG scan chain interrogation failed: all zeroes

as well as :
dtmcontrol is 0. Check JTAG connectivity/board power.

Nevertheless, thanks for your support and time. If you get it working without a JTAG (I hope you do) please let me know.

13

No I mean using the ChipWhisperer as a JTAG programmer: Debugging with ChipWhisperer — ChipWhisperer 5.7.0 documentation as you were trying to do before. Did you make the necessary connections between the ChipWhisperer and the target board?

The ChipWhisperer mimics an FTDI chip by implementing the MPSSE protocol and bitbanging JTAG/SWD.

Alex

14

Of course, me being silly and not reading the entire tutorial and also being bad with JTAG, I didn’t do any connections. I just assumed that the connections were already done within the UFO board.

Anyway, just to sure, here’s a schematic of CW308 UFO on which the target is FE310 is mounted and to which the CWLite is connected :

Capture d’écran du 2023-05-12 10-41-22
Capture d’écran du 2023-05-12 10-41-221036×891 126 KB

If I understood the tutorial correctly, the pins circled in red should be connected to those circled in green, and GND won’t have to be connected since the CWLite and the CW308 UFO are connected to the same GND. I really want to sure of this so I won’t do any false connections that could ruin the boards.

Thanks again Alex for your help and time.

EDIT
I just found this tutorial : chipwhisperer-jupyter/demos/Debugging the CW308_STM32F3 Using ChipWhisperer.ipynb at master · newaetech/chipwhisperer-jupyter · GitHub

Even though it’s for an STM32F3, I thick it should be the same for FE310, so I’ll do the connections and update you on the result.

15

Ok. programming the FE310 seems to be working fine (but takes a huge amount of time that made me thought I was doing something wrong)

I got the following message after programming :

Capture d’écran du 2023-05-12 18-19-09
Capture d’écran du 2023-05-12 18-19-091004×542 123 KB

Despite having one error, I think the programming was ok since I got no errors between “Programming Started” and “Resetting target” . If you think that it’s wrong and I should be getting something else please tell me.

Also, I’m having a problem now communicating with the target through the CW. The program that I flashed into the FE310 is the simpleserial-glitch in which there’s a command ‘p’ that executes the password function. However, communicating with the target doesn’t seem to work since executing the following code :

pw = "aeiou".encode('ascii')
target.simpleserial_write('p', pw)
val = target.simpleserial_read_witherrors('r', 1, glitch_timeout=10)

print(val)

Prints :

{'valid': False, 'payload': None, 'full_response': '', 'rv': None}

Instead of :

{'valid': True, 'payload': bytearray(b'\x00'), 'full_response': 'r00\n', 'rv': 0}

Which makes me wonder if the flashing worked correctly or not, or whether the compilation of simpleserial-glitch was not right. It’s worth noting that I got the following warnings when compiling :

.././hal/fe310/freedom-metal-201908/src/shutdown.c:15:9: note: #pragma message: There is no defined shutdown mechanism, metal_shutdown() will spin.
 #pragma message("There is no defined shutdown mechanism, metal_shutdown() will spin.")

.././hal/fe310/freedom-metal-201908/src/time.c: In function 'metal_gettimeofday':
.././hal/fe310/freedom-metal-201908/src/time.c:11:9: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
     if (rv = metal_timer_get_cyclecount(0, &mcc)) {
         ^~
.././hal/fe310/freedom-metal-201908/src/time.c:14:9: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
     if (rv = metal_timer_get_timebase_frequency(0, &timebase)) {
         ^~

But I don’t think they are problematic.

Any help will be appreciated, and thanks again for the help.

16

You could try setting one of the GPIO pins high to make sure that the code is starting up. Also keep in mind that you’ll need a valid clock before the FE310 will run.

Alex

17

I just flashed a program that put a voltage on some pins of the FE310 target, those pins are connected to pins on the the CW308 UFO, when I check them I get nothing, even though the CWLite is providing a clock of around 7.37MHz (I got exactly 7.383MHz), Yet no voltage to be found on the pins that configured

Here is the schematic of the target from : CW308T-FE310 - NewAE Hardware Product Documentation

Capture d’écran du 2023-05-15 11-54-36
Capture d’écran du 2023-05-15 11-54-361289×502 155 KB

As you can see gpio_0 to gpio_4 can be used since they are connected to pin H1 H2 and LED 1 to 3 on the CW308 UFO.

To use those pins to test the program, I used the following code :

     /**************** TEST ************/ 
    static struct metal_gpio *gpio_test2; 
   // static to see if it works since in the fe310.c the struct is also static 
    
    struct metal_gpio *gpio_test4;

    
    gpio_test2 = metal_gpio_get_device(0);
    
    gpio_test4 = metal_gpio_get_device(0);

    
    metal_gpio_enable_output(gpio_test2, 1) ;
    
    metal_gpio_enable_output(gpio_test4, 3) ;
     
	// Not sure whether 0 or 1 sets the pin on volatge 
    metal_gpio_set_pin(gpio_test2, 1, 0); 
        
    metal_gpio_set_pin(gpio_test4, 3, 1);
     /**************** TEST ************/

And just to sure I added the following code in the fe310.c file in which the trigger_high() and trigger_low() function are defined :

#include "fe310_hal.h"

static struct metal_gpio *gpio_device;

/**************** TEST ************/
static struct metal_gpio *gpio_test1;
static struct metal_gpio *gpio_test3; 
/**************** TEST ************/

void platform_init(void)
{
    gpio_device = metal_gpio_get_device(0);
    
    /**************** TEST ************/
    gpio_test1 = metal_gpio_get_device(0);
    gpio_test3 = metal_gpio_get_device(0);
    
    metal_gpio_enable_output(gpio_test1, 0) ;
    metal_gpio_enable_output(gpio_test3, 2) ;
    
    metal_gpio_set_pin(gpio_test1, 0, 0); 
    metal_gpio_set_pin(gpio_test3, 2, 1);
    /**************** TEST ************/ 
}

Here is what I did :
1- Without connection to the CW, I ran the run_openocd.sh file that allow to program the target, this file does everything from connecting to the CW, enabling MPSSE, programming and disabling MPSSE
2- I closed the jupyter on which I ran the command and re-opened it
3- I connected to CW using the setup_generic file
4- I used the function scope.default_setup() to generate a clock and checked the CLKIN pin to if there’s a clock and indeed there is (CLKIN is connected to HS2/OUT on my board)
5- I checked the voltage on the pins, nothing

What could be the problem ?

EDIT:

To communicate with the target FE310, what bus or communication protocol is used ? UART? if so shouldn’t the UART be configured in the init_uart() function that is defined in the fe310_hal.c, this is the case for example if the target is a stm32f3 in stm32f3_hal.c :

void init_uart(void)
{
  GPIO_InitTypeDef GpioInit;
  GpioInit.Pin       = GPIO_PIN_9 | GPIO_PIN_10;
  GpioInit.Mode      = GPIO_MODE_AF_PP;
  GpioInit.Pull      = GPIO_PULLUP;
  GpioInit.Speed     = GPIO_SPEED_FREQ_HIGH;
  GpioInit.Alternate = GPIO_AF7_USART1;
  __GPIOA_CLK_ENABLE();
  HAL_GPIO_Init(GPIOA, &GpioInit);

  UartHandle.Instance        = USART1;
  #if SS_VER==SS_VER_2_1
  UartHandle.Init.BaudRate   = 230400;
  #else
  UartHandle.Init.BaudRate   = 38400;
  #endif
  UartHandle.Init.WordLength = UART_WORDLENGTH_8B;
  UartHandle.Init.StopBits   = UART_STOPBITS_1;
  UartHandle.Init.Parity     = UART_PARITY_NONE;
  UartHandle.Init.HwFlowCtl  = UART_HWCONTROL_NONE;
  UartHandle.Init.Mode       = UART_MODE_TX_RX;
  __USART1_CLK_ENABLE();
  HAL_UART_Init(&UartHandle);
}

But in the fe3310_hal.c :

void init_uart(void)
{
    ;
}

Is that ok ? Nevertheless, the pins configuration should do something, why am I not getting anything on the pins ?

18

UPDATE
I were able successfully to flash a program the only lights up a LED, to do so I had to clear the .c file flashed from every possible thing that could’ve cause an error.

Right now I have the following problems:

1- This problem is the most annoying one, basically, when I connect to the CW, the program doesn’t run, it only runs when I run the following function that I got from here
Programming the FE310 through OpenOCD
:

def reconnect():
   scope = cw.scope()
   scope.default_setup()
   target = cw.target(scope)

   scope.io.nrst = "low"
   time.sleep(0.7)
   scope.io.nrst = "high_z"

   return scope, target

The problem is that it causes the CW to disconnect, I can’t connect again because I get the LIBUSB busy error -6, and disconnecting and reconnecting the CW from thr PC is the only way yo reconnect again but it closes the program run by the target so no more LEDs

2- Assuming I succeed in falshing a program and keeping it running while the CW is also running, I still have no idea on how I’ll be able to communicate with the target since the UART is no initialized in the fe310_hal.c file in the hal folder. Isn’t necessary to inizilize it before using it in the getch and putch functions that are used in the communication with the target ? I would like to know so if the answer is yes I’ll try to code the initialization myself

3- Despite the fact that flashing a programmed worked, it still take a lot of time (almost an hour just for lighting up an LED), any idea on how to increase the speed of programming in openOCD? Will the usage of a programmer (like ST-link) work and be faster ?

EDIT

4- Using the scope.enable_MPSSE() causes the LED1 (the green one) on the CW308 to light up (even though it isn’t even configured in the code to do so) and gdb debugger can not debug the target since it can’t talk with openOCD on the localhost 3333, this happens when LED1 is on because of enable_MPSSE() , any ideas ?

Thanks in advance for any help or advice.

19

Yeah, you need a valid clock when the device boots. If you’re getting a LIBUSB Busy error, something is still connected to the ChipWhisperer. I don’t know where you’re running this function from, but that scope object you return is probably still connected.

The UART is initialized in hardware/victims/firmware/hal/fe310/freedom-metal-201908/. The build system for the FE310 is a bit of a pain and most stuff gets done in hidden functions that get called on startup.

I don’t think there’s anything we can do to improve this. The CW is just bitbanging stuff across and there seems to be some sensitive timing stuff that makes the FE310 kind of flaky with programming. I don’t think an STLink will work (though it might through OpenOCD), but the Tigard I linked earlier will definitely work.

Alex

20

Thanks Alex for the reply, it helped a lot.

Anyway the objective has been met, I was able to flash a program. I’ll just try to make it work better.

I have acces to an ST link, I’ll try to use it, if it does work that will be great, if not I’ll consider using the trigard.

I forget to say that I was able to flash a program using the gdb with the load command and it works super fast even though the interface is always the same (the CW) however the process isn’t esay to be repeated.

EDIT
I just programmed the the HiFive revb1 board with OpenOCD, this board has jlink and the programming didn’t even take 10secs, this leads me to believe that using a jtag programmer other than the CW should speed things up, I hope that st link works, otherwise I’m gonna have to get the Trigard (beging in Europe means it’ll take some time to arrive) also I’ll need time to figure it out and how to use it.

P.S : I know I’m writing a lot and posting, I just like to document what I’m doing in case it helps someone who is in the same issu

21

Ok, this is the final comment from me

FINAL UPDATE

First of all, either FE310 is just really complicated or I’m not that good in the domain of embedded systems.

My objective was to program the FE310 and I figured that out, empirically, that to do so is (at least for me this what worked) :

1 - Plug the CW to the PC (duh)

2 - Connect the CW using the following code (this code should be executed as is and not by putting in a function, that didn’t work for me) :

scope = cw.scope()
scope.default_setup()
target = cw.target(scope)
target.flush()

scope.io.nrst = "low"
time.sleep(0.7)
scope.io.nrst = "high_z"

   return scope, target

3- Execute the function scope.enable_MPSSE() to enable MPSSE

4- Program the chipwhisperer :

  • In a terminal execute the following command :
    path/to/openocd -f /path/to/interface_cfg.cfg -c 'ftdi vid_pid 0x2b3e 0xace2' -c 'transport select jtag' -f /home/alkafa/chipwhisperer/openocd/fe310.cfg

  • In another terminal :
    `gdb-multiarch path/to/prog.elf

  • Then on the gdb command line :
    target extended-remote localhost:3333
    monitor reset halt
    load

5- After programming has been correctly, connecte again to the CW with the code above and execute scope.enable_MPSSE(0) to disable MPSSE

6- scope.dis()

7- ubplug cw from pc

I did this, it worked, I don’t know why, but it did

If gdb doesn’t talk with ocd because of timeout, it’s because ocd hasn’t ‘found’ the chip to be flashed on the target, sometimes it finds it quicly, sometimes no, we can only wait

Also, openocd sometimes might not be able to listen on 3333 simply because it’s used, for that :
sudo kill -9 sudo lsof -t -i:3333`

It should be noted the using run_openocd.sh to program the FE310 also worked, the problem is that this way takes sooooo much time

Here’s the code that I was able to flash, because I’m not sure anything can be flashed, this code has the password and glitch-loop functions to do the password bypassing exercise:

#include "hal.h"
#include <stdint.h>
#include <stdlib.h>

#include "simpleserial.h"

uint8_t password(uint8_t* pw, uint8_t len)

{
    char passwd[] = "touch";
    char passok = 1;
    int cnt;

    trigger_high();

    //Simple test - doesn't check for too-long password!
    for(cnt = 0; cnt < 5; cnt++){
        if (pw[cnt] != passwd[cnt]){
            passok = 0;
        }
    }

    trigger_low();

    simpleserial_put('r', 1, (uint8_t*)&passok);
    return 0x00;
}

uint8_t glitch_loop(uint8_t* in, uint8_t len)

{
    volatile uint16_t i, j;
    volatile uint32_t cnt;
    cnt = 0;
    trigger_high();
    for(i=0; i<50; i++){
        for(j=0; j<50; j++){
            cnt++;
        }
    }
    trigger_low();
    simpleserial_put('r', 4, (uint8_t*)&cnt);


    return (cnt != 2500);

}


int main(void)
{
    
    platform_init();   
    trigger_setup(); 
    simpleserial_init();  
    simpleserial_addcmd('p', 5, password);
    simpleserial_addcmd('g', 0, glitch_loop);

  

    while(1){
    simpleserial_get();
        }
}

I hope it helps someone.

Big Thanks to @Alex_Dewar :v: :v: :v: for all the help provided