The following log shows that the ZEEVO module may send
data before the corresponding connection complete event
arrives. Note: read from bottom to the top (second
column is the local timestamp)
380 1333430 C02, INF: EVT (0x03): 01:46. state: 4,
ahdl: 18, mhdl: 1 Type: 1 err: 0x 0
379 1333424 C02, INF: EVT (0x03): no entry for
01:46. mhdl: 1 Type: 1 err: 0x 0
378 1333420 C05, ERR: con handle 4095 not in stack
anymore!!
377 1333415 C02, DBG: acl pkt! mhdl: 1, ahdl: -1,
pb: 2, bc: 0
376 1330606 C05, INF: Nut: Heap Available = 26027
bytes.
375 1330603 C05, INF: cm: inq done. found: 10
devs, candidates: 1
374 1328097 C05, INF: cm: inq started!
373 1327225 C02, DBG: acl pkt! mhdl: 2, ahdl: 4,
pb: 2, bc: 0
372 1321134 C05, INF: DISCONNECTION (hdl 17)
371 1320915 C05, INF: new con: neg. pkt sent. type
1 handle 17 psm 4099
370 1320904 C05, INF: CONNECTION: 01:77, hdl: 17,
detail: 0
369 1320899 C05, INF: cm: inq sleep 7558
368 1320895 C05, INF: Nut: Heap Available = 26027
bytes.
367 1320890 C05, INF: cm: con created: 01:77,
retval: 17
366 1320881 C02, INF: EVT (0x03): 01:77. state: 3,
ahdl: 17, mhdl: 1 Type: 1 err: 0x 0
Logged In: YES
user_id=687107
Originator: NO
does this happen on the node which opens the connection or on the other?
where are the log events genereated by the HCI thread or higher?
if it is done by other layers then the Zeevo might be fine, just the thread scheduling
got screwed up.
how did you deal with this? just using some delay after opening a connection before sending?
keeping the acl packet for later probably doesn't sound very reasonable, or?