Help us improve the Power & Sensing Selection Guide. Share feedback

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob

MyCase# 00461781, Customer is asking of below:

1) I have selected and begun development with the NRF52832 chipset using Zephyr OS which has a certified mesh stack.   I am however looking to use the PSoC 6 for a different product, and would like to know if it might be possible to share data from a PSoC 6 as a GATT Server to a mesh node with the proxy service enabled.  Where should I go to receive help on this particular topic?

2) I am also still interested to know roadmap for BLE Mesh on PSoC 6, as it would make this even easier.

1 Solution

There are no plans currently to support BLE Mesh on PSoC 6 BLE or the associated 416045-02 certified module. Your local Cypress Sales/FAE/Distribution team can keep you posted on any changes to these plans.


View solution in original post

13 Replies
250 sign-ins 25 comments on blog 10 comments on blog

BLE Mesh is not currently supported on PSoC 6.

The CYW20719 competes favorably with the NRF52832.


While mesh is not supported, it should still be possible to communicate with a mesh node, correct? The point of the Mesh Proxy node is to bridge BT LE devices to a supported Mesh network.

Proxy nodes (supported by NRF5 and ZephyrOS) should implement a GATT service called the Mesh Proxy Service, and act as a GATT server. Mesh Applications (which should be able to run on any BT LE product) implement the client side of the GATT service. GATT writes (without response) are used to for writing data from the LE device to the Proxy, and GATT notifications are used for the reverse action.

The only features that should be needed are:

GAP Central (discovery of nodes by scanning)

GATT Client (Write Without Response and Characteristic Value Notification)

ATT (L2CAP) MTU of 33 octets (not mandatory but preferred)

So long as PSoC 6 supports those things (I believe it does, but please correct me if I am wrong), then it should be capable of communication with a mesh network (just not as an actual node).

The question then becomes, how would one implement rudimentary communications like this on the PSoC 6.


There should be no problem from the GATT point of view.  Meanwhile to implement that, the P6 device will need to become a real mesh node.  It will need to support all layers of the mesh stack.  To send a message, the app needs to prepare a fully formatted mesh message (fragmented, encrypted,...) and then send it over the GATT connection.  Similarly GATT Proxy will pass all messages as received from the mesh over the GATT to P5 devices, where the message will need to be decrypted, authenticated, reassembled,...  Cypress currently provide binaries that can be used on Android, iOS, Windows but not on PSoC6 devices.

Thanks for the informative answer on that. I am curious if it is feasible to get rudimentary communications between mesh nodes and a PSoC 6. I have a product that uses BT Mesh, but I want to use PSoC 6 for another one because it fits the rest of my requirements perfectly. I only need to send a single on/off value from the PSoC 6 and do not need to read anything from the mesh node.

Is there a roadmap for official mesh support in PSoC 6? Previous discussions mentioned that progress would be shown on that beginning of this year.


Unfortunately it is not possible (at this time).  A PSoC device needs to be provisioned into the network to receive all the security credentials and the address and to become a mesh node.  Then it needs to have mesh stack to be able to format and send a mesh message. Note that each message has a sequence number, so you cannot prepare an on/off message and then send it as needed.


Thanks for the advice. Is there a roadmap for getting this feature into PSoC 6? It is currently the only thing missing for me, and I will still keep it on my list if there will be options in the coming months.


There are no plans currently to support BLE Mesh on PSoC 6 BLE or the associated 416045-02 certified module. Your local Cypress Sales/FAE/Distribution team can keep you posted on any changes to these plans.




I just wanted to follow up. I have implemented the mesh proxy protocol on a PSoC 6 and am thus able to properly format messages to send through the mesh, with the security credentials provided from a provisioner. I have verified the accuracy of the generated mesh proxy PDUs via the CySmart tool, manually connecting to my proxy node, and sending the generated PDU as a Gatt Write Without Response to the correct handle.

Now that I have done what I imagine is the hard part, I am ready to begin the actual bearer layer of the protocol. I have looked through some examples, but am curious if you have any examples, or some hints on how to:

1. Perform a network discovery

2. Check the "Complete list of 16-bit Service Class UUIDs" and filter for a particular UUID (for the mesh proxy service, 0x1828). I would then check the data and make sure it matches my network id based on the provisioner data.

3. Connect to that device

4. Discover all attributes

5. Select a handle and perform a GATT Write Value Without Response on that handle

I can do all of this easily through CySmart, and in doing so I can set an LED on my mesh node using my generated mesh proxy pdu. I just now need to begin looking into how to do this on PSoC 6. Once I can do those five steps, then I will have a complete mesh proxy implementation (including seq number as mentioned, etc -- although I still need to add some features like writing seq to flash periodically so that the replay attack prevention feature of ble mesh doesnt ignore my messages after a power cycle).

Thanks for any info,



As a follow up to my previous comment,

I have played around a bit and am able to scan for mesh nodes, filtering by the mesh proxy service, and selecting a node based on network id. I can successfully connect to that node.

I ran into an issue trying to write the pdu data though. When I call Cy_BLE_GATTC_WriteWithoutResponse(&param) I am receiving INVALID_PARAMETER.

The pdu size is 23 bytes, so I think it should be safe to do. The attribute handle is the same as the handle that I used in the CySmart tool successfully. The connHandle I am using is from the CY_BLE_EVT_GATT_CONNECT_IND event.

Is there something I am missing here?




The format of writing characteristic from the client is;

Opcode (1 byte)

Handle (2 byte)

Attribute Value (0 to ATT_MTU-3)

With a negotiated MTU size of 23 bytes, the maximum size of payload is (effective GATT MTU Size - 3) = 20 bytes. Please try following two methods and let me know if it helps.

  • Ensure 'param->handleValPair.value.len' value is lesser than (Effective GATT MTU-3) to remove the INVALID_PARAMETER error. ie., 'param->handleValPair.value.len' lesser than 20 bytes in your case.
  • To write a packet data length of 23 bytes, increase the default MTU size to 26 or above. The MTU needs to be exchanged between the devices to increase default GATT MTU size of 23 bytes. Please call "Cy_BLE_GATTC_ExchangeMtuReq" API from the GATT Client application to send Exchange MTU Request PDU. Call this API after connection is completed (or Authentication complete, if applicable) from the client device.

For more details on maximum packet size, please refer to Maximum Packet Size According to MTU – KBA203312

Ah, yes I hadn't considered this.


                .connHandle = *(cy_stc_ble_conn_handle_t *)eventParam,

                .mtu = 33


After handling of CY_BLE_EVT_GATT_CONNECT_IND worked perfectly.

I now am sending mesh messages that are being handled by mesh nodes perfectly.

Wasn't the easiest, but it is done. I would still love to see an official mesh implementation. The only part missing I think is the CCM mode of operation for AES from the crypto engine on PSoC. CMAC worked perfectly for getting network credentials, but actual formation of the proxy PDU requires CCM mode. It was easy enough to just include an implementation of AES CCM though (tinycrypt).

Thanks again for the help!


I have another question in regards to finishing this up. The last thing I have to do is (automatically) find the connected nodes "Mesh Proxy Data In" Characteristic (0x2ADD), and grab the associated handle (not always the same). I have been successful in finding the Mesh Proxy Service (0x1828) by using Cy_BLE_GATTC_StartDiscovery(connHandle), and then filtering by uuid in cy_ble_serverInfo in the CY_BLE_EVT_GATTC_DISCOVERY_COMPLETE event. This required that I add a custom service (0x1828) to my GATT client configuration, but I believe this is all correct. I am getting the correct handle ranges in the response here.

The last step is to search through those handle ranges, and find the handle which has a characteristic 0x2ADD, this is the handle I need to send Mesh Proxy PDUs to. I am currently just hardcoding the handles for testing.

I tried calling

cy_stc_ble_gattc_read_by_type_req_t param = {

                            .range = cy_ble_serverInfo[discIdx].range,

                            .uuid = cy_ble_serverInfo[discIdx].uuid,

                            .uuidFormat = CY_BLE_GATT_16_BIT_UUID_FORMAT,

                            .connHandle = appConnHandle


cy_en_ble_api_result_t api_result = Cy_BLE_GATTC_DiscoverCharacteristicByUuid(&param);

and I get no error in api_result.

But, the next event I receive is  CY_BLE_EVT_GATTC_ERROR_RSP with an error code of CY_BLE_GATT_ERR_ATTRIBUTE_NOT_FOUND.

I am not sure what I am missing here, but I think I am close. Any hints on how to best find the handle associated with characteristic 0x2ADD?



To follow up on this, I believe I may have been being dumb. I was searching for the wrong UUID, I was using the Service UUID in the Discover Characteristics By UUID function. When I searched for the correct UUID (0x2ADD) I was getting a single response which is correct. I am not entirely clear on the data I got back but I assume (by the looks of it), it is something like:

attribute handle: bits 0:3

properties? : bits 4:5

characteristic handle: bits 6:9

characteristic data 10:end

I am not completely sure, but it looks like that. If that is correct, then I think I've got it.