Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[KTrenholm]

Hello, 

I'm evaluating the FT900 series with a MM900EV1B module connected to a UMFTPD2A for programming/debugging.  I am using the FT9xx Toolchain v2.5.0.
I'm having an issue where I am able to program the FT900 with no problems, but I am unable to launch the debugger.

When I begin debugging, the part is flashed properly, but then it bombs trying to begin debugging.
The message I receive is:

    'Launching FT9XX DEBUG' has encountered a problem.
    Error in final launch sequence
        Failed to execute MI command:
        -target-select remote localhost:9998
    Error message from debugger back end:
    localhost:9998: No connection could be made because the target machine actively refused it.
    localhost:9998: No connection could be made because the target machine actively refused it.

The console log shows:

    11:39:17 Running GDB started...
    Launching Debug Server (GDB Bridge)...
    python.exe "C:/Program Files (x86)/Bridgetek/FT9xx Toolchain/Toolchain/utilities/gdb_bridge.py" live flash
    Launching Debug Client (ft32-elf-gdb)...
    C:/Program Files (x86)/Bridgetek/FT9xx Toolchain/Toolchain/tools/bin/ft32-elf-gdb.exe

It looks like the gdb_bridge.py is starting, I can see a command prompt window open then quickly close when it attempting to launch the debugger.  Might there be a way to hold the window open or does it maybe catch some log information to get a better idea of what's going on?

When I run GDB Bridge.bat from the command prompt manually, it looks to start up OK:

    GDB Bridge Application
    Is Python v3 running? no

    D2XX library loaded OK
    D2XX devices detected: 4
    Device[0]: UMFTPD2A A
    Device[1]: UMFTPD2A B
    Device[2]: UMFTPD2A C
    Device[3]: UMFTPD2A D
    D2XX device opened: UMFTPD2A A

    Waiting for GDB connection request


So the python script seems to be running OK when run manually, at least to start.  Not sure where I should look from here.

Thanks in advance for the help!  Let me know if there's any additional information I can provide that might be of use!

[BRT Community]

Hello,

For some general background information, the bootloader presents an interface for both programming the FT900 and for the GDB bridge to query the hardware during debugging. In simplified terms, some of the functionality for debugging is on the GDB bridge debugger and the rest is in the bootloader. The bootloader is 4kB but it is not in a protected area unless the linker script is modified (the v2.6.0 default linker script protects the bootloader).

Here are some possible reasons that could be causing the debugger issue.

• There is an issue with the bootloader (this doesn’t appear to be the issue here).
  • The first part of the sequence is to program the Flash. This succeeds since this is a hardware function as the one-wire interface has direct access to the Flash interface and can program the device without any trouble under most circumstances. The hardware will respond correctly to requests such as hardware register reads as well.
  • There is code in the bootloader which then performs additional work when the one-wire connects from the debugger bridge. This code is responsible for responding to a set of commands required by the GDB bridge program. The GDB bridge will ALSO verify the connection by performing some hardware register reads as well so it will make some ‘progress’ when compared to when there is no actual device connected.
  • So, if the bootloader is corrupted then the programmer works and the GDB bridge starts but ultimately times out waiting for a response from the bootloader code on the FT900. The GDB bridge console can be shown by Eclipse by changing a setting.
  • A remedy for this is to reprogram the bootloader with the FT9xx Programmer Utility. Then ensure that it is not being overwritten by the code by checking the size of the code programmed. The ft32-elf-size command run at the end of the build will tell you the size. It is a raw code size so it is possible that there are rarely used linker commands (or linker script options) which can move code around. If the code is small enough then it should run properly after restoring the bootloader.
• There is an issue with Java or Python installation; permissions to create or access to sockets on the debugging machine; or virus scanners analysing program behaviour.
  • Any of the above could be breaking this. The fact that it works from the command line makes me think it could be one of these reasons. So, Eclipse spawns a process to run the GDB Bridge code which is in Python. Then when debugging starts, Eclipse remote debugging will connect to the GDB Bridge code through sockets.
  • The permissions, or memory available to, or the behaviour of spawned processes from the Java runtime (which runs Eclipse) may not allow the connection.
  • The process that runs Python (see above) might not be allowed to connect or be sandboxed by the virus scanner.
  • The GDB_bridge python code not being able to create a socket for Eclipse to connect.
  • Eclipse may not be allowed to connect to the sockets.
  • You can test the connection to the sockets on the command line with ‘ft32-elf-gdb <file>.elf’ command line. Then “target remote localhost:9998”.
• A program can start running on the FT900 and disable interrupts and do something that locks out the debugger. It shouldn’t but sometimes pressing the reset button and connecting to the debugger works, whereas leaving it a few seconds after resetting doesn’t work.
• Check the debugger cable is seated correctly.

Best regards, BRT Community