Flashpro and OpenOCD

Important

This documentation is not recommended for new RISC-V projects. New RISC-V projects should reference the newest version of the documentation. Users targeting Arm devices can still use this documentation as their reference.

The newest version of the documentation can be found here: https://mi-v-ecosystem.github.io/SoftConsole-Documentation/

Windows firewall

On Windows if there is a firewall in use then the first time that a debug session is run the firewall may prompt that it is blocking OpenOCD, fpServer.exe and/or renode.exe. Allow the firewall to unblock these and save this as the default setting if necessary.

Multiple debug sessions

For a particular SoftConsole application instance, only one debug session should be active at any one time. If a deliberate or inadvertent attempt is made to run more than one debug session, then SoftConsole may not work properly and it may be necessary to exit and restart SoftConsole for further debugging to work properly.

FlashPro JTAG debugging is unreliable on virtual machines

FlashPro JTAG debugging is unreliable on virtual machines so it is recommended that only physical machines and not virtual machines be used for SoftConsole debugging

Debug session fails to run as expected

If the debug session fails to run as expected, then check the following:

• On Linux, was the udev rules file installed and activated in order to grant non-root access to users in the relevant group (usually plugdev)?

• Is a FlashPro device connected (FlashPro 5 on Linux, FlashPro3/4/5 on Windows)?

• Is there more than one FlashPro device connected? If so SoftConsole may not be using the correct one. If you want to use a specific one of several FlashPro devices connected, then you can add --command "microsemi_flashpro port <fp-port-name>" to the OpenOCD command line options.

• On Windows did a previous FlashPro3/4 debug session fail leaving OpenOCD (openocd.exe or fpserver.exe) running because abiactel.dll did not exit cleanly thus blocking access to the FlashPro device? Check Task Manager/ProcessExplorer for openocd.exe and if it’s still running then unplug the FlashPro USB cable and then reattach it and OpenOCD should terminate.

• If the debug session starts but the program does not run/behave as expected, then check that the project was updated to match the target hardware by having the Libero SoC generated firmware and drivers_config copied in before rebuilding.

• Ensure that the relevant CMSIS/HAL firmware core is used.

Connecting to remote OpenOCD

The binding behavior of the OpenOCD changed from the SoftConsole 5.2. Now by default, it’s binding itself to the 127.0.0.1 instead of the 0.0.0.0 which means that the remote OpenOCD will listen only to its loopback address instead on all interfaces and it will not be reachable remotely. This default behavior is considered to be safer and when needed can be overridden by adding the -c "bindto 0.0.0.0" argument to the OpenOCD command.

openocd.exe -c "bindto 0.0.0.0" <rest-of-your-arguments>

Check that FlashPro can be used without root privileges

Connect a FlashPro5/6 JTAG programmer to a native Linux host machine (this might not work on a VM) and check that it is visible to the operating system:

lsusb
Bus 001 Device 004: ID 1514:2008 Actel
Bus 001 Device 004: ID 1514:2009 Actel
Bus 002 Device 002: ID 1514:200b Actel

If the FlashPro5 (VID=1514 PID=2008) or FlashPro6 (VID=1514 PID=2009) or embedded FlashPro6 Rev B (VID=1514 PID=200b) does not appear then double check that the previous steps were carried out correctly.

Warning

If you will see VID=1514 PID=200a then that is embedded FlashPro6 Rev A and to use it with SoftConsole or Libero, it needs to be upgraded to Rev B.

• To the JTAG end of the FlashPro connect a suitable board containing a Cortex-M1, SmartFusion or SmartFusion2 Cortex-M3, or RISC-V CPU based SoC design.

  • Make sure you are connecting to the right JTAG connector (in case of Icicle board it’s J23 and not J10, the J10 is used only to reprogram the embedded JTAG)

• Power the board on.

• Make sure that the board is configured for FlashPro JTAG debugging of the target CPU (depending on the board and CPU/SoC in use some board switches/jumpers configuration may be required).

• Make sure that it has correct and matching Libero design (if you are going to connect to Mi-V RV-32 then you need working Mi-V design on the device)

• Run OpenOCD from the command line to ensure that the debug connection can be established to the target CPU/SoC:

First go to the correct directory (replace <SoftConsole-install-dir> with your installation path):

cd <SoftConsole-install-dir>/openocd/bin

And then execute the following:

PolarFire SoC

Mi-V RISCV

Cortex-M1

Cortex-M3

./openocd -c "set DEVICE MPFS" -f board/microsemi-riscv.cfg

./openocd -f board/microsemi-riscv.cfg

./openocd -f board/microsemi-cortex-m1.cfg

./openocd -c "set DEVICE M2S090" -f board/microsemi-cortex-m3.cfg

Note

A M2S090 target is needed in the example above.

For example: When using Trenz SMF2000 board, it needs to be changed to M2S010.

The command set DEVICE M2S090 needs to be changed to match the target.

The output should be similar to the following:

Mi-V RISC-V

Cortex-M1

Cortex-M3

Open On-Chip Debugger
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 6000 kHz
microsemi_flashpro tunnel_jtag_via_ujtag off
trst_only separate trst_push_pull
do_board_reset_init
Info : FlashPro ports available: S201Z7LB20, E200X3ID7
Info : FlashPro port used: S201Z7LB20
Info : clock speed 6000 kHz
Info : JTAG tap: FPGA.tap tap/device found: 0x1f8071cf (mfg: 0x0e7
(GateField), part: 0xf807, ver: 0x1)
microsemi_flashpro tunnel_jtag_via_ujtag on
Info : JTAG tap: FPGA.tap disabled
Info : JTAG tap: FPGA.dap enabled
Info : RISC-V IDCODE = 0x10e31913
Info : Examined RISCV core; XLEN=32, misa=0x40902223
halted at 0x80000b60 due to debug interrupt

Note

Notice from the log above, the following was recognized correctly

• The FlashPro ports

• The ID code of the JTAG tap

• And the RISC-V IDCODE

Open On-Chip Debugger
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 6000 kHz
microsemi_flashpro tunnel_jtag_via_ujtag off
cortex_m reset_config sysresetreq
trst_only separate trst_push_pull
do_board_reset_init
Info : FlashPro ports available: usb50266
Info : FlashPro port used: usb50266
Info : clock speed 6000 kHz
Info : JTAG tap: FPGA.tap tap/device found: 0x2353a1cf (mfg: 0x0e7
(GateField), part: 0x353a, ver: 0x2)
microsemi_flashpro tunnel_jtag_via_ujtag on
Info : JTAG tap: FPGA.tap disabled
Info : JTAG tap: FPGA.dap enabled
Info : Cortex-M1 IDCODE = 0x4ba00477
Info : FPGA.cpu: hardware has 2 breakpoints, 1 watchpoints
cortex_m auto_bp_type off

Note

Notice from the log above, the following was recognized correctly

• The FlashPro ports

• The ID code of the JTAG tap

• And the Cortex-M1 IDCODE

Open On-Chip Debugger
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
M2S090
Info : only one transport option; autoselect 'jtag'
adapter speed: 6000 kHz
cortex_m reset_config sysresetreq
trst_only separate trst_push_pull
do_board_reset_init
Info : FlashPro ports available: S201Z7LB20, E200X3ID7
Info : FlashPro port used: S201Z7LB20
Info : clock speed 6000 kHz
Info : JTAG tap: M2S090.tap tap/device found: 0x1f8071cf (mfg: 0x0e7
(GateField), part: 0xf807, ver: 0x1)
Info : JTAG tap: M2S090.tap disabled
Info : JTAG tap: M2S090.dap enabled
Info : Cortex-M3 IDCODE = 0x4ba00477
Info : M2S090.cpu: hardware has 6 breakpoints, 4 watchpoints

Note

Notice from the log above, the following was recognized correctly

• The FlashPro ports

• The ID code of the JTAG tap

• And the Cortex-M3 IDCODE

Warning

If seeing output similar to the snippet below (or any other errors excluding documented issues) then that indicates a problem. In that case double check that all the post installation steps have been carried out correctly and that the target hardware/board is correctly configured for debugging of the target CPU/SoC.

Info: FlashPro ports available: none
Info: FlashPro port used: usb
Error: InitializeProgrammer(usb) failed: Can not connect to the programmer

FlashPro programmers cannot be shared by applications

Due to limitations of the FlashPro driver/library software support used by FlashPro client applications (e.g. SoftConsole OpenOCD, SmartDebug, Identify etc.) FlashPro programmers cannot be shared and used at the same time by multiple applications and only one application can use a specific FlashPro programmer at any one time.

FTDI detected as ttyUSB on Linux

In some instances, all the FTDI channels might get taken by the serial driver and turned into the ttyUSB devices. If this happens then OpenOCD may list one or more FlashPro programmers but fail to connect to one:

Info : FlashPro ports available: S201Z7LB20
Info : FlashPro port used: S201Z7LB20
Error: InitializeProgrammer(S201Z7LB20) failed : Can not connect to the programmer
Running dmesg can show that the ftdi_sio driver is registered to the device.
[ 1400.220327] usb 2-1.4: Product: FlashPro5
[ 1400.220329] usb 2-1.4: Manufacturer: Microsemi
[ 1400.220331] usb 2-1.4: SerialNumber: 01Z7LB20
[ 1400.280943] usbcore: registered new interface driver ftdi_sio
[ 1400.280972] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 1400.281176] ftdi_sio 2-1.4:1.2: FTDI USB Serial Device converter detected
[ 1400.281264] usb 2-1.4: Detected FT4232H
[ 1400.281726] usb 2-1.4: FTDI USB Serial Device converter now attached to ttyUSB0

A script can be used as a temporary workaround which will then disable all serial drivers with the FTDI. This script will unload the ftdi_sio module:

#!/bin/sh
# $DEVNAME environment variable is most likely set to /dev/ttyUSB0
# get the ttyUSB0 without the path
NAME=$(basename $DEVNAME)
# Find FTDI child USB device with then $DEVNAME parent device
for DEVICE in /sys/bus/usb/drivers/ftdi_sio/*/
do
    if [ -e $DEVICE/$NAME ]
    then
        # Match found, unbind it from the FTDI driver
        echo -n "$(basename $DEVICE)" > /sys/bus/usb/drivers/ftdi_sio/unbind
        break
    fi
done

Save this script as /usr/local/bin/unbind_ftdi.sh and give it correct privileges:

sudo chmod a+x /usr/local/bin/unbind_ftdi.sh
sudo chown root:staff /usr/local/bin/unbind_ftdi.sh

Now find where the OpenOCD udev script was installed (most likely /etc/udev/rules.d/60-openocd.rules) and modify the existing “Microsemi (Actel) FlashPro5” entry as follows:

# Microsemi (Actel) FlashPro5
ATTRS{idVendor}=="1514", ATTRS{idProduct}=="2008", MODE="666",
RUN+="/usr/local/bin/unbind_ftdi.sh"

Depending on the distribution I might be necessary to reload the udev rules or reboot for the changes to take effect:

sudo udevadm trigger

Now reconnecting the FlashPro device and watching dmesg messages should state that the ftdi_sio module was unloaded and OpenOCD should be able to connect to and use the connected FlashPro programmer(s).

[10626.270300] usb 2-1.4: new high-speed USB device number 54 using ehci-pci
[10626.382547] usb 2-1.4: New USB device found, idVendor=1514, idProduct=2008
[10626.382554] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[10626.382556] usb 2-1.4: Product: FlashPro5
[10626.382560] usb 2-1.4: Manufacturer: Microsemi
[10626.382562] usb 2-1.4: SerialNumber: 01Z7LB20
[10626.387020] ftdi_sio 2-1.4:1.2: FTDI USB Serial Device converter detected
[10626.387085] usb 2-1.4: Detected FT4232H
[10626.387615] usb 2-1.4: FTDI USB Serial Device converter now attached to ttyUSB0
[10626.432272] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[10626.432296] ftdi_sio 2-1.4:1.2: device disconnected

Embedded FlashPro6 rev A

Refer to the Libero SoC v12.5 SP1 or Program Debug Tools v12.5 SP1 (or later) release notes for details of how to upgrade the Embedded FlashPro6 from Rev A to Rev B.

Only a few early production boards were shipped with Rev A, while most of the users have already board with Rev B.

OpenOCD crashes when attempting to debug RISC-V

In some cases, OpenOCD may crash when attempting to debug a RISC-V target. This happens when the debug session would fail anyway due to everything not being order for it to work – for example, the target board is not connected or powered up or the wrong target board is connected. In some cases, such a crash may necessitate closing SoftConsole and restarting it in order for a subsequent debug session to work.

Windows occasionally crashes when plugging FlashPro in/out

It has been observed in some cases that plugging a FlashPro JTAG programmer in/out of a Windows machine can sporadically/occasionally cause it to “Blue Screen” (“Blue Screen of Death” or “BSOD”). When this happens, the error is often a PAGE_FAULT_IN_NONPAGED_AREA in ftdibus.sys but in some cases a different cause may be displayed.

Reducing the amount of unplugging and re-plugging of the FlashPro 5 and making sure to not ‘wiggle’ the connector while doing so should lower the risks of getting BSOD. Switching to embedded FlashPro6 should improve the user experience as well.