STM32WB55 sometimes returns unknown error value when trying to update a characteristic

[RWeil.2]

Hi,

I am using an STM32WB55RCV6 with the full BLE stack.

During operation, I am updating some characteristics. Some at the push of a button, some scheduled with a timer.

Sometimes, unregularly, and only when the device is connected (to a smartphone), the following happens:

When I use the following function from custom_stm.c quite often

Custom_STM_App_Update_Char(...)

(this functionthen calls aci_gatt_update_char_value(...)),

the Characteristic is NOT updated and I get the return value "12".

The function usually works, but only once in a while, when I am updating a lot of values, I get this error code. It also only happens when the microcontroller is connected to another device (here: a smartphone). When this error occures, usually the next few times when I call Custom_STM_App_Update_Char(...), these functions also fail (same return code), but after a while, it works again and updates the characteristics properly.

The smartphone, that is connected, has "indicate" enable for the respective characteristics. I do not know if that might have anything to do with the return value.

Nowhere I found an explanation what this error code means. There are actually a lot of error codes defined in the ST libraries and I read the application notes for BLE (where they explain the function aci_gatt_update_char_value), but nowhere the error code 12 is explained.

Before I go into too much detail how my program is structured, I would just like to know what the error code 12 means. I mean, if there is an error code, it should have a meaning, right? I already spent quite some hours on this issue and I think knowing what the error code means would help me a lot.

Kind regards

René

[RWeil.2]

/* Status codes */

/* Returned when the command has completed with success

 */

#define BLE_STATUS_SUCCESS                             0x00U

/* The remote device in in the Blacklist and the pairing operation it requested

 * cannot be performed.

 */

#define BLE_STATUS_DEV_IN_BLACKLIST                    0x59U

/* CSRK not found during validation of an incoming signed packet

 */

#define BLE_STATUS_CSRK_NOT_FOUND                      0x5AU

/* IRK not found (Currently not used)

 */

#define BLE_STATUS_IRK_NOT_FOUND                       0x5BU

/* A search for a specific remote device was unsuccessful because no entry

 * exists either into NVM Database or in volatile database.

 */

#define BLE_STATUS_DEV_NOT_FOUND                       0x5CU

/* The security database is full and no more records can be added.

 */

#define BLE_STATUS_SEC_DB_FULL                         0x5DU

/* The remote device is not bonded, and no operations related to bonded devices

 * may be performed (e.g. writing Gatt Client data).

 */

#define BLE_STATUS_DEV_NOT_BONDED                      0x5EU

/* The encryption key size used for encrypting the link is insufficient\n

 */

#define BLE_STATUS_INSUFFICIENT_ENC_KEYSIZE            0x5FU

/* The attribute handle is invalid.

 */

#define BLE_STATUS_INVALID_HANDLE                      0x60U

/* There aren't sufficient Attributes handles available for allocation during

 * creation of Services, Characteristics or Descriptors.

 */

#define BLE_STATUS_OUT_OF_HANDLE                       0x61U

/* The requested GATT operation is not allowed in this context/status or using

 * the provided parameters.

 * This is a specific GATT error, different from generic Not Allowed error,

 * because it refers to specific GATT specifications/rules.

 */

#define BLE_STATUS_INVALID_OPERATION                   0x62U

/* The characteristic has already been added to the database.

 */

#define BLE_STATUS_CHARAC_ALREADY_EXISTS               0x63U

/* The requested operation failed for a temporary lack of resources

 * (e.g. packet pool or timers), but it may be retried later when resources may

 * become available (packets or timers may have been released by other

 * consumers).

 */

#define BLE_STATUS_INSUFFICIENT_RESOURCES              0x64U

/* Notification/Indication can't be sent to the requested remote device because

 * it doesn't satisfy the needed security permission.

 */

#define BLE_STATUS_SEC_PERMISSION_ERROR                0x65U

/* The address of the device could not be resolved using the IRK stored\n

 */

#define BLE_STATUS_ADDRESS_NOT_RESOLVED                0x70U

/* Returned when no valid slots are available

 * (e.g. when there are no available state machines).

 */

#define BLE_STATUS_NO_VALID_SLOT                       0x82U

/* The only slot available is not long enough to satisfy scan window request.

 */

#define BLE_STATUS_SCAN_WINDOW_SHORT                   0x83U

/* Returned when the maximum requested interval to be allocated is shorter

 * then the current anchor period and there is no submultiple for the

 * current anchor period that is between the minimum and the maximum requested

 * intervals.

 */

#define BLE_STATUS_NEW_INTERVAL_FAILED                 0x84U

/* Returned when the maximum requested interval to be allocated is greater

 * than the current anchor period and there is no multiple of the anchor

 * period that is between the minimum and the maximum requested intervals.

 */

#define BLE_STATUS_INTERVAL_TOO_LARGE                  0x85U

/* Returned when the current anchor period or a new one can be found that

 * is compatible to the interval range requested by the new slot but the

 * maximum available length that can be allocated is less than the minimum

 * requested slot length.

 */

#define BLE_STATUS_LENGTH_FAILED                       0x86U

/* The Host failed while performing the requested operation.

 */

#define BLE_STATUS_FAILED                              0x91U

/* Invalid parameters in Host commands

 */

#define BLE_STATUS_INVALID_PARAMS                      0x92U

/* The Host is already processing another request received in advance.

 */

#define BLE_STATUS_BUSY                                0x93U

/* The operation requested cannot be completed immediately by the Host

 * (usually because of lack of resources).

 * The operation is generally put on hold by the caller and it's usually

 * retried on later time.

 */

#define BLE_STATUS_PENDING                             0x95U

/* The requested operation violates the logic of the called layer/function or

 * the format of the data to be processed during the operation.

 */

#define BLE_STATUS_ERROR                               0x97U

/* The requested operation failed because of lack of memory.

 * Out of memory shall be returned for situations where memory will never

 * become available again (e.g. ATT database)

 */

#define BLE_STATUS_OUT_OF_MEMORY                       0x98U

/* Returned when a timeout occurs at BLE application interface

 */

#define BLE_STATUS_TIMEOUT                             0xFFU

None of these error codes matches the code "12"

[RWeil.2]

Ok, after a lot of further testing I have come to the following conclusion:

The error code 12 means, that the device (client), that has activated indications for the specific charakteristic from the microcontroller (server), did not receive the update of said charakteristic. Error code 12 is not returned, when a) I only call update_char without a BLE client connected or b) when I deactivate "indicate" and activate "notify" (the difference between indicate and notify is, that with indicate the mikrocontroller gets a message from CPU2, if the characteristic was received correctly).

It would be cool if someone from ST could confirm that.

[Remy ISSALYS]

Hello,

The error code "12" (e.g 0x0C) means command disallowed, the error codes list is available in AN5270 "Status error codes" part. In your case, when you are using indication, you should wait to receive the acknowledgment from client before sending a new indication. If you send the new indication before the acknowledgment, the aci_gatt_update_char_value command returns the error code "12".

Best Regards

[RWeil.2]

Hello,

thank you very very much for your response. This helps me a lot! I have actually still been struggling with some bugs. Now I know where to look.

I will do some reading on how to receive the acknowledgment but now I´m on track again.

Kind regards

René

[RWeil.2]

I implemented void aci_gatt_server_confirmation_event( uint16_t Connection_Handle ){ ... } but it never gets called...

[Remy ISSALYS]

Hello,

In custon_stm.c file, in Custom_STM_Event_Handler function, add the following lines:

case ACI_GATT_SERVER_CONFIRMATION_VSEVT_CODE:
 APP_DBG_MSG("ACI_GATT_SERVER_CONFIRMATION_VSEVT_CODE\n");
 break; 

You should have this event when the client has sent the confirmation to a previously sent indication.

Best Regards

[RWeil.2]

Hi,

thank you, this works like a charm.

So let me summarize:

If I have a BLE device (client) connected to the uC (server) and if the server indicates a char update, I have to wait for the acknowledge event, which the client will send to the server, if it received the char update.

I can check this event using the case ACI_GATT_SERVER_CONFIRMATION_VSEVT_CODE.

It seems, that sometimes an update char is just getting lost; I update the char but I never receive the confirmation and no more indications can be send, because the server did not receive the acknowledge of the previous char update.

Is there a way I can reset this? Is there a command that says "discard the last update char and don´t give me the error 12 when I do the next char update"? Or is CPU2 constantly trying to update the char and waiting till it gets the acknowledge and there is just something wrong with the connection?

[Ebin34]

ST and @Remy ISSALYS , I am Interested in the question as well,

What shall be the error handling in case a confirmation for Indication was not received?

[Remy ISSALYS]

Hello, 

Normally, this kind of situation should not happen during normal operating conditions. The client should send the confirmation. If it's not the case, the server can't send anymore indication and will receive ACI_GATT_PROC_TIMEOUT_EVENT event after the GATT timeout (30s). This is a critical event that should not happen during normal operating conditions. It is an indication of either a major disruption in the communication link or a mistake in the application which does not provide a reply to GATT procedures. After this event, the GATT channel is closed and no more GATT communication can be performed. The application is expected to issue an  ACI_GAP_TERMINATE to disconnect from the peer device.

Best Regards