FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  


Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support

New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Topics - krispy86

Pages: [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- and libft4222-linux-
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- : Address 0x20744
libft4222-linux- : 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.

Pages: [1]