1
Discussion - Software / libft4222 error
« on: January 26, 2018, 02:58:44 pm »
OS - Linux 3.10.87+ using an armv7l processor and Debian based.
Compiler used for the OS and for applications is gcc 4.9.2-10
Specifically Using the FT4222_UnInitialize function.
I've tested with both libft4222-1.2.1.35 and libft4222-linux-1.3.1.120
Tested on the FT4232RQ and FT4232RQ
Edit 3: Actually FT4222HQ
I can run the example code and my own application fine up until it's time to use FT4222_UnInitialize.
If I use FT4222_UnInitialize then the program hangs and never finishes. I can solve this in a standalone application by only calling FT_Close and never UnInitialize so the program cleans up on exit fine; however, I have created a long running program which periodically needs to open a connection through FTDI, download files, and close the connection so I need to clean up resources rather than just simply close.
The remote end of the connection is constantly creating new files for me to download and if I download, say 400 files each time then after about 5-10 connections I start getting bad data through the connection and the connection starts slowing down immensely to a point where I no longer receive anything from the remote side anymore.
I've done some digging and found that the function hangs at a specific point each time. FT4222_Uninitialize+228
The actual memory address when running is at 0xB6F1D73C
From Objdump
libft4222-1.2.1.35 : Address 0x20744
libft4222-linux-1.3.1.120 : Address 0x1E74C
Edit2: this is a call to _ZN8RxThreadD0Ev7
...
+212 ldr r2, [r3]
+216 add r2, r2, #4
+220 ldr r2, [r2]
+224 mov r0, r3
+228 blx r2 -- hangs here
+232 sub r3, r11, #20
...
If I quit gdb while hanging then I see
[Thread 0xb40ff450 (LWP ####) exited]
__libc_do_syscall () at ../ports/sysdeps/unix/sysv/Linux/arm/libc-do-syscall.S:43
The assembly drops to
0xb6de6540 <__libc_do_syscall> push {r7, lr}
0xb6de6542 <__libc_do_syscall+2> mov r7, r12
0xb6de6544 <__libc_do_syscall+4> svc 0 --- application hangs here
0xb6de6546 <__libc_do_syscall+6> pop {r7, pc}4
0xb6de6548 nop.w
0xb6de654c nop.w
0xb6de6550 <__fork> b.w 0xb6ddce18
0xb6de6554 <__pthread_mutex_cond_lock> push {r4,r5,r6,lr}
0xb6de6556 <__pthread_mutex_cond_lock+2> movw r2, #383 ; 0x17f
... mutex function
I also followed the application through GDB using SI all the way through and this is exactly where the program hangs.
r7 is 0xF0. On my system this is defined as_NR_mq_open. Edit 4: After some more research I found this to be __NR_futex
Anyone have an idea on what can be done here?
Edit 1:
Note that I've tested message queueing using mq_open, mq_send, mq_receive, mq_close using a client server test setup and things work fine.
Compiler used for the OS and for applications is gcc 4.9.2-10
Specifically Using the FT4222_UnInitialize function.
I've tested with both libft4222-1.2.1.35 and libft4222-linux-1.3.1.120
Edit 3: Actually FT4222HQ
I can run the example code and my own application fine up until it's time to use FT4222_UnInitialize.
If I use FT4222_UnInitialize then the program hangs and never finishes. I can solve this in a standalone application by only calling FT_Close and never UnInitialize so the program cleans up on exit fine; however, I have created a long running program which periodically needs to open a connection through FTDI, download files, and close the connection so I need to clean up resources rather than just simply close.
The remote end of the connection is constantly creating new files for me to download and if I download, say 400 files each time then after about 5-10 connections I start getting bad data through the connection and the connection starts slowing down immensely to a point where I no longer receive anything from the remote side anymore.
I've done some digging and found that the function hangs at a specific point each time. FT4222_Uninitialize+228
The actual memory address when running is at 0xB6F1D73C
From Objdump
libft4222-1.2.1.35 : Address 0x20744
libft4222-linux-1.3.1.120 : Address 0x1E74C
Edit2: this is a call to _ZN8RxThreadD0Ev7
...
+212 ldr r2, [r3]
+216 add r2, r2, #4
+220 ldr r2, [r2]
+224 mov r0, r3
+228 blx r2 -- hangs here
+232 sub r3, r11, #20
...
If I quit gdb while hanging then I see
[Thread 0xb40ff450 (LWP ####) exited]
__libc_do_syscall () at ../ports/sysdeps/unix/sysv/Linux/arm/libc-do-syscall.S:43
The assembly drops to
0xb6de6540 <__libc_do_syscall> push {r7, lr}
0xb6de6542 <__libc_do_syscall+2> mov r7, r12
0xb6de6544 <__libc_do_syscall+4> svc 0 --- application hangs here
0xb6de6546 <__libc_do_syscall+6> pop {r7, pc}4
0xb6de6548 nop.w
0xb6de654c nop.w
0xb6de6550 <__fork> b.w 0xb6ddce18
0xb6de6554 <__pthread_mutex_cond_lock> push {r4,r5,r6,lr}
0xb6de6556 <__pthread_mutex_cond_lock+2> movw r2, #383 ; 0x17f
... mutex function
I also followed the application through GDB using SI all the way through and this is exactly where the program hangs.
r7 is 0xF0. On my system this is defined as
Anyone have an idea on what can be done here?
Edit 1:
Note that I've tested message queueing using mq_open, mq_send, mq_receive, mq_close using a client server test setup and things work fine.