Global time overflow about nrf51-ble-bcast-mesh HOT 10 CLOSED

I changed a few lines in radio_signal_callback from

    /* sample RTC timer for trickle timing */
    time_now = NRF_RTC0->COUNTER - g_start_time_ref;

    /* scale to become us */
    time_now = ((time_now << 15) / 1000);

    transport_control_timeslot_begin(time_now);

to

    /* sample RTC timer for trickle timing */
    uint32_t rtc_time = NRF_RTC0->COUNTER;

    /*First time the offset should be added*/
    if(last_rtc_value==0)
        last_rtc_value=g_start_time_ref;

    /* Calculate delta rtc time */
    uint32_t delta_rtc_time;
    if(last_rtc_value>rtc_time)
        delta_rtc_time=0xFFFFFF-last_rtc_value+rtc_time;
    else
        delta_rtc_time=rtc_time-last_rtc_value;
    /* Store last rtc time */
    last_rtc_value=rtc_time;


    /* scale to become us */
    time_now += ((delta_rtc_time << 15) / 1000);

    transport_control_timeslot_begin(time_now);

and made time_now static and added

static uint32_t last_rtc_value=0;

as a local variable in radio_signal_callback

With these modifications the code nolinger stopps transmitting data after 9.1 minutes.

from nrf51-ble-bcast-mesh.

In many places the global time is stored as u32bit, this will wrap after 71minutes.
So I still get crash efter 71minutes. Have the developers of this stack tested it for more than 9 minutes or 71minutes?

from nrf51-ble-bcast-mesh.

Hi, sorry for the delay.
The mesh has been proved stable and responsive for tests running over the course of several weeks without a reset. Have you verified that the mesh stops functioning after this time?

This is most likely a bug that has gone undiscovered because the introduction of a new version of a value into the mesh after this overflow occurs will reset the trickle module, and put the next timeout at time_now + ADV_INT_MIN, which will be within in the range of the RTC 99.9% of the time, and we have not considered this last corner case. This means that whenever the mesh gets an update it goes back to transmitting like it's supposed to do, no matter the amount of overflow that have occurred.

Your solution seems reasonable, and an additional fix directly in the trickle module would solve the overflow issue at 71min. The trickle->i_relative value will never be more than g_i_min * g_i_max, and we can do a check for this when we check whether the trickle timer has expired in trickle_step(), and then correct the value if it's out of bounds.

from nrf51-ble-bcast-mesh.

I'll second @victorpasse's observation, I've also experienced this issue after 9.1 minutes, and his fix does indeed extend transmission time to 71 minutes, where overflow occurs again.

from nrf51-ble-bcast-mesh.

To "solve" the 71minutes crash i changed all time keeping variabled to uint64_t, it will still overflow but we all will be dead by then. It seemed as a simple bodge.

from nrf51-ble-bcast-mesh.

@victorpasse Hah 😄, I'll use that as a patch until we get an official fix 👍

from nrf51-ble-bcast-mesh.

interesting thread, could you please post your test scenario? As I could not reproduce the overflow.

from nrf51-ble-bcast-mesh.

I'd be interested in this as well. Is this a timebomb in the system or just a very rare case of certain options?

from nrf51-ble-bcast-mesh.

I have modified the mesh a bit and can not post any code due to confidentiality.
I have not investegated thoroughly what the results of the problem is but after the 9.1 minutes and 71 minutes no more packages are sent through the mesh, after changeing the code as i commented everything worked.

from nrf51-ble-bcast-mesh.

I have implemented @victorpasse's solution in the new v0.6.3, making the 9.1minute overflow silky smooth. I've also moved it over to 64bit timestamp, so the 71min overflow is eradicated as well. It has been tested and confirmed stable for the example projects. I'll close this issue, but feel free to reopen it if the problem persists in any one of your implementations.

from nrf51-ble-bcast-mesh.