FTDI Community
General Category => Discussion - Software => Topic started by: krispy86 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.
-
Hello,
Would it be possible for you to email your question with an example of your code to support1@ftdichip.com?
Could you also include which revision of the IC you are currently using.
Best Regards,
FTDI Community