Forums

Dear Pavel,

The issue seems to some sort of data corruption at transport layer as ST driver (stc) in kernel is throwing below errors messages.

<3>(stc): Data length is too large len 1128 room 1044 [The data length can’t be more than 1021 bytes – 3-DH5]
<3>(stc): chip/interface misbehavior dropping frame starting with 0x39
<3>(stc): chip/interface misbehavior dropping frame starting with 0x49

This can possibly be due to UART dropping bytes or corruption somewhere from the UART to the time it gets delivered to ST layer.

Please provide more details on followings?

1)      Which platform are you using – Standard Panda/Blaze or custom built?

2)      Which baseline TI release are you using and have you done any modification to UART serial driver or ST layer?

3)      As PAN is not supported in Android GingerBread – Have you implemented PAN profile or trying via command line?

4)      Do you see the same behavior with other data transfer applications over BT (file transfer via OPP profile or A2DP profile) or is it just PAN profile?

Regards,

Naveen

1) It's custom board

2) I can not say, what version of the Shared Transport driver i use, because it info not presented in driver (only copyright and author). But i can share driver on file storage if it can help.

3) I builded BNEP driver in kernel and managing PAN over command line.

4) No, i can't reproduce this errors on A2DP or OPP. May be because packages for OPP and A2DP less long, than for PAN.

The reason of this errors can be in high baud rate of UART?

Dear Pavel,

I am not sure if the reason of these errors can be high baud rate of UART as I assume that you are using the same baud-rate for A2DP & OPP as well.

You mentioned that "Over time, downloading freeze." Can you please let me know once you start PAN data transfer, after how much time the issue happens and is this consistent and occurs around the same time?

As A2DP and OPP holds the system wake lock to avoid Android go to suspend while data transfer is going on, I suspect the Android might be going into suspend while using PAN profile from command line causing the data errors.

Can you set the screen timeout to 30 minutes from Settings -> Display -> screen timeout while doing the test? Also hold a wake lock and let us know you observations?

before running the PAN test execute below from command line,

$ echo test > /sys/power/wake_lock

after running the PAN test execute below from command line,

$ echo test > /sys/power/wake_unlock

Thanks & Regards,

Naveen

Sometimes downloading freeze after 1 megabyte downloaded. Sometimes i can download 150 - 250 megabytes. I don't remember, what a sleep timeout for screen was set in this cases.

I tried setup a screen timeout to 30 minutes and start test. When the screen goes off, i turned it on via power button. And after that downloading was freezed with same error.

I tried test with a wake locks, but nothing has changed. This errors also was observed during the test.

I also tried starting OPP transfer parallel with PAN downloading, but it didn't help. OPP and PAN downloading stopped.

P.S. I attached source code of the Shared Transport  which i use

4075.st_core.c.txt

2148.st_kim.c.txt

3108.st_ll.c.txt

7206.ti_wilink_st.h.txt

Any suggestions? May be need do something else? F.e., use WakeLocks from JAVA (develop a simple program that calling WakeLock and starting PAN transfer)?

Dear Pavel,

It is bit strange as you mention that sometimes you can download up to 250 MB and sometimes it fails even after 1 MB. This suggests some sort of instability may be in UART driver. I would suggest trying with lower baud-rates.

You also mentioned that you tried setup a screen timeout to 30 minutes and start test. When the screen goes off, you turned it on via power button. And after that downloading was freezed with same error.

From your statment can I assume that the issue occurs only after the screen goes off (and always after screen times off). If it is the case, can you enable always awake option via setting->Applications->Development->Stay Awake option.

Finally if both the above (lower baud rate and screen off) does not help I would suggest to implement the wakelock mechanism as done in A2DP and OPP assuming that you do not see any issues during A2DP and OPP data transfer.

Thanks,

Naveen