In some cases this test case results a buffer overrun
(on hci_layer) on the btnode.
General:
- one side is not a btnode (different speed,
bluetooth-stack)
- no ack communication architecture (I used a
request/reply for kind of flow control)
Java:
- no waiting time between connect, send, receive (COSE,
RESE, SERE)
C:
- turn on all debug messages (bt_hci.c, bt_hci_event.c)
- no sleeptime in sendmsg() (located in Thread STREAMER)
Logged In: YES
user_id=687107
this is very likely related to long critical section. see
bug 1063795 for more details. A blind guess, after proping
nut/os earlier, is that using timeouts leads to this
problem. a better approach for timeout handling (just don't
do it in the IRQ context, but during the next thread switch
should be ok for most cases, where an application is waiting
for something.
TestCase (java/c sources/hexfile/classes)