Maybe bugged branch?

Question

Maybe bugged branch?

Closed this issue 2 years ago · 11 comments

Hi all!
I'm full time working to update my code with the new branch (count_revamp).
I download the branch, flashed my boards and press the button to start the syncronization.
After some seconds, this is the situation:

So I reset the boards and I repeat the procedure.
After some seconds, this is the situation:

Are you sure this is a completely tested branch? It seems to be veeeery bugged (at least respect to master branch).

Moreover, if you just download the branch and build it with SES, it fails. I needed to make these changes to build the project:

SDK_CONFIG: #define PPI_ENABLED 1 (it was 0)
INSERTING: nrfx_ppi.c file inside the project

Is it supposed to be normal?

I think I will need a lot of support in the following weeks.
Thanks for the help

Answer 1 · 2021-12-23T02:05:19.000Z

Hi, David I happened to use this demo a few months ago. The demo works well, thanks to the authors for this excellent feature. Maybe some suggestions could help you to find the root cause. 1. Ensure the sender and receiver using the same RF address and channel. (If you can sync at start, I guess this tip is okay in your environment)2. Ensure there's only one sender using the same RF address and channel over the air, if you have more than one sender, reminder to update the address & channel. (This could be possible, I meet similar issue in my environment.)3. Using same module (both 52832 or both 52840 is verified in my test) and same compile environment for download the application for both sender&receiver.

…

-------------------------------- BR, skady

----- 原始邮件 ----- 发件人：David140 ***@***.***> 收件人：nordic-auko/nRF5-ble-timesync-demo ***@***.***> 抄送人：Subscribed ***@***.***> 主题：[nordic-auko/nRF5-ble-timesync-demo] Maybe bugged branch? (Issue #19) 日期：2021年12月23日 06点33分 Hi all! I'm full time working to update my code with the new branch (count_revamp). I download the branch, flashed my boards and press the button to start the syncronization. This is the situation after some seconds: Is it a bug? I think I will need a lot of support in the following weeks. Thanks for the help — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Answer 2 · 2021-12-23T17:44:12.000Z

Hi crazy, thanks for the answer!

Ensure the sender and receiver using the same RF address and channel.

I think this is ok, the two boards can sync at the beginning, just for like 30s.

Ensure there's only one sender using the same RF address and channel over the air, if you have more than one sender, reminder to update the address & channel.

I'm using at the moment just one sender (that is the BLE central) and one receiver (that is the BLE peripheral).

Using same module

I'm using a NRF52840DK as BLE central (and sync packets sender) and a Adafruit Feather NRF52840 as BLE peripheral (and sync packets receiver). The MCU is the same (NRF52840) so I don't think this could be a problem. Maybe I can try to use 2 NRF52840 dongles (to exploit 2 identical boards) but I would be surprised if something will change.

UPDATE
Also with 2 nrfr52840 dongles the problem is always the same...
So far I used the master branch and syncro went on all the night without problems. Now I need to start and stop the syncro every X seconds for my application and the master branch (after some switch-on / switch-off procedures) crashes. I thought to solve the problem updating to this new version, but it seems like here the syncro crashes after few seconds even without switch-on / switch-off procedures...

Moreover, if you just download the branch and build it with SES, it fails. I needed to make these changes to build the project:

SDK_CONFIG: #define PPI_ENABLED 1 (it was 0)

INSERTING: nrfx_ppi.c file inside the project

Is it supposed to be normal?

I think this is not how the branch is supposed to work, it seems weird that it comes not compiling...
I downloaded counter_revamp branch, is it the right branch (the updated one)?

Answer 3 · 2021-12-30T14:12:25.000Z

Hi, David I guess different board have no impact if use same module, not sure. But I guess crystal oscillator configurations (PPM and so on) in sdk_config.h could have some impact, not sure, you can set them same in both. :)May be you can send email to author ask for help directly. I can't remember no more details due to I have left the company which use this module. :) -------------------------------- BR, skady

…

----- 原始邮件 ----- 发件人：David140 ***@***.***> 收件人：nordic-auko/nRF5-ble-timesync-demo ***@***.***> 抄送人：Crazy Skady ***@***.***>, Comment ***@***.***> 主题：Re: [nordic-auko/nRF5-ble-timesync-demo] Maybe bugged branch? (Issue #19) 日期：2021年12月24日 01点44分 Hi crazy, thanks for the answer! Ensure the sender and receiver using the same RF address and channel. I think this is ok, the two boards can sync at the beginning, just for like 30s. Ensure there's only one sender using the same RF address and channel over the air, if you have more than one sender, reminder to update the address & channel. I'm using at the moment just one sender (that is the BLE central) and one receiver (that is the BLE peripheral). Using same module I'm using a NRF52840DK as BLE central (and sync packets sender) and a Adafruit Feather NRF52840 as BLE peripheral (and sync packets receiver). The MCU is the same (NRF52840) so I don't think this could be a problem. Maybe I can try to use 2 NRF52840 dongles (to exploit 2 identical boards) but I would be surprised if something will change. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.Message ID: ***@***.***>

Answer 4 · 2022-01-07T10:27:23.000Z

Hi David,

I tested the revamp branch again and see indeed the same issues as you.
Will need to spend more time on this to understand if the issue was always there, or if there was a local difference that did not make it into the commit.

Specifically it seems that the 2nd timer (in counter mode) is not handled properly, as the offset is always in time units of TIME_SYNC_TIMER_MAX_VAL / 16000000 seconds.

Answer 5 · 2022-01-07T15:02:54.000Z

Hi Audon,
thanks for your time.
I will check daily this topic to see if there are any updates from you.
Thanks again!

Answer 6 · 2022-01-31T16:35:35.000Z

Hello @nordic-auko
Any news about this branch?
Thanks!

Answer 7 · 2022-03-05T09:33:33.000Z

Hello.
Another month without an answer.
We are developing a new product and this branch is still bugged.
Could we have the correct commit in few days please?
Thanks.

Answer 8 · 2022-03-10T15:53:44.000Z

Hi, I'm also hoping a fix on this situation would occur as I'm getting similar issue.

Answer 9 · 2022-03-11T15:29:13.000Z

Hi @cperezmicrofactorycoop
Audun has just pushed an errata corrige commit on the counter_revamp branch.
I will keep this issue open until I have done the necessary tests to assure proper functioning.
Thanks again!

Answer 10 · 2022-03-22T13:24:38.000Z

Hi, sorry for the lack of response on this one. Please give the updated counter_revamp branch a try and see if it fixes the issue

Answer 11 · 2022-07-12T09:12:51.000Z

Closing after inactivity