Why is the service channel for the Bluetooth SPP connection client function hardcoded to 0xff?

void bt_spp_client_start_w4conn(BTS2S_BD_ADDR *bd_addr, U8 *uuid, U8 uuid_len)
{
spp_clt_conn_req_ext(bd_addr,
0xff,
FALSE,
NULL,
uuid,
uuid_len);
USER_TRACE(“>> SPP init connect device: %04X:%02X:%06lX\n”,
bd_addr->nap,
bd_addr->uap,
bd_addr->lap);
}

The normal procedure should be to first use SDP to discover the service channel, and then pass the channel number into this function, right?

[210399] I/btapp_spps: >> SPP connect device address: 7400:49:FFFFFF

[210461] D/bt_common: [spp_debug] add new connect: 7400:49:FFFFFF
[210516] D/bt_common: svc_set srch_req_hdl 665
[210557] D/bt_cm: fsm: SDC st:0 evt:3
[210591] D/bt_cm: fsm: L2C_CH st:0 evt:0
[210626] D/bt_cm: fsm: L2C_CH st:1 evt:5
[210662] D/bt_cm: fsm: L2C_CID st:0 evt:0
[210699] D/bt_common: ACL connection request with BD: ffffff:49:7400

[210760] D/bt_common: hcicm_send_hci_conn_req

[210824] I/bt_cm: DM_ACL_CREATE_CONN_STATUS
[210862] D/NO_TAG: Unknown message class: 2

Also, in the log line “[210699] D/bt_common: ACL connection request with BD: ffffff:49:7400”, is the Bluetooth address incorrectly formatted with LAP and NAP reversed?

image You need to call this interface first to perform an SDP query, and then call the connection interface.

        else if (strcmp(argv[1], "send_data") == 0)
        {
            bd_addr_t mac;
            bt_addr_convert_from_string_to_general(argv[2], &mac);
            uint8_t srv_chl = atoi(argv[3]);
            char *test_str = "This is spp test!!!";
            U8 len = (U8)bstrlen(test_str);
            U8 *data = (U8 *)bmalloc(len);
            bmemcpy(data, test_str, len);

            bt_interface_spp_send_data_ext(data, len, (bt_notify_device_mac_t *)&mac, srv_chl);
        }

This is a code snippet from an SPP example. Here, memory is allocated for data, but I don’t see any explicit memory release. Is the memory freed inside the SPP API?

Yes, this memory will be released at the underlying level.