p_hvx_params:: uint16_t *p_len

[Stayhungry]

The description of p_hvx_params :: uint16_t * p_len in ble_gatts.h is:

"Lnegth in bytes to be written, length in bytes written after successful return"

uint16_t len = 10;
uint32_t err_code;
uint8_t buffer [10];
    
func() 
{
        err_code = sd_ble_gatts_hvx (buffer, &len)
    
        if (err_code = NRF_SUCCESS) {
    
             len =?
    
            / * case 1: len = 10 * /
            / * case 2: len = 0 * /
           / * case 3: len = 8 * /
        }
}

My current test can get case1 every time, but case2 and case3 may appear? Because if not, I feel there is no need to pass a pointer when calling sd_ble_gatts_hvx

[Petter Myhre]

Yes, p_hvx_params is an input and an output. It is a bug in the documentation saying it is only an in, this will be fixed.

Length in can be more than length out if the length is larger than ATT MTU-3.

Also, if sd_ble_gatts_hvx() doesn't return NRF_SUCCESS the length out will be 0.

[Stayhungry]

According to your point of view, if I call sd_ble_gatts_hvx, just tx_queue not enough, this time my len will be changed to 0? If I understand it right, every time I call sd_ble_gatts_hvx, I need to define a temporary variable as "tmp len" = len instead of putting len in, to ensure that the correct length is sent instead of 0 until NRF_SUCCESS is returned.

[Petter Myhre]

Sorry. I checked with the developers again. Some errors will come with a len = 0. NRF_ERROR_RESOURCES and NRF_ERROR_BUSY will not, but NRF_ERROR_INVALID_PARAM will. The safest thing is to set the length every time, using a temp.

[Stayhungry]

I did the relevant tests and found NRF_ERROR_RESOURCES happen, my tmp_len sometimes not been modified, sometimes changed to 1 or 2, what does this mean?Then I ignore the value of tmp_len, if NRF_ERROR_RESOURCE happened to resend all the data before, and then found in the peer device still able to receive the complete data, as if NRF_ERROR_RESOURCE modified tmp_len, but did not buffer any data to sd

[Petter Myhre]

Can you share the test code that exhibits this behavior?

[Stayhungry]

I upload the project a bit difficult, no matter what, it seems no problem, it works fine, I no longer consider that tmp_len is correct, I just share my test results here. Now my nus rate is over 90kB / s