@A-Paul I know this is a big one, but do you mind to be assignee? If yes, feel free to reassign -as usual...

@yogo1212 what do you mean exactly by "no working code is using it"?
Do you mean that there is no code/example to test it?
But there seems to be an example?

@emmanuelsearch the example doesn't work :-D
well, the initialisation works but no beacon is being broadcasted :-(
that might happen in the next week or so, though; sometimes you insert a seemingly random printf and... puff - it works ;-)

@yogo1212 @emmanuelsearch I'm currently working on fully implementing the advertising functionality, however both the TI doc and the BLE sepcs are rather poorly written, so it's not as straightforward as it could be... I'm also writing a "guide" on BLE advertising with the CC2650, as I make my way trough the doc: I will make it available on the wiki of the board when things are in an acceptable state.

@yogo1212, I'm going to look deeper into your code tomorrow (hopefully).

As a first step I ask you to enclose the macro literals into braces. Also there are several decimal numbers mixed in sequences of hex numbers. Would be helpful to make this more consistent.

well, the initialisation works but no beacon is being broadcasted :-(
that might happen in the next week or so, though; sometimes you insert a seemingly random printf and... puff - it works ;-)

That is what I consider "Work in progress"?

@A-Paul thank you for your time :-)
i'm not happy about the mixed lower-/upper-case either but there is a point to it.
_mask and _pos are no values that should be written to a register.
i thought i had seen someone do it that way in RIOT - right now i can only find _Msk and _Pos (https://github.com/RIOT-OS/RIOT/blob/master/cpu/sam3/include/sam3x8e/component/component_rtc.h#L81)
that is also the reason for the dec/hex..

@A-Paul thank you for your time :-)

You're welcome.

Your example file is -not the only- one created by a HW vendor. Look at the file header. We use them and and leave them as they are. In RIOT code, please use uppercase letters for constants.

that is also the reason for the dec/hex.

In file cpu/cc26x0/include/cc26x0_rfc.h:
line 254 #define SYSGPOCTL_GPOCTL0_pos 0x0
line 384 #define R_OP_STARTTRIG_TRIG_NO_pos 5

Even that exception is not strict. Seems that I'm not convinced.

you are absolutely right on that.
shall i turn all the positions into hex or decimal?

@fvcoen found a fault in the fcfg headers

    printf("&FCFG->MISC_CONF_1 %p\n", (void *) &FCFG->MISC_CONF_1);
    printf("&FCFG->MAC_BLE_0 %p\n", (void *) &FCFG->MAC_BLE_0);
    printf("&FCFG->MAC_15_4_0 %p\n", (void *) &FCFG->MAC_15_4_0);

->

2016-06-20 23:23:23,540 - INFO # &FCFG->MISC_CONF_1 0x500010a0
2016-06-20 23:23:23,543 - INFO # &FCFG->MAC_BLE_0 0x500012e4 <--- datasheet says 12e8
2016-06-20 23:23:23,545 - INFO # &FCFG->MAC_15_4_0 0x500012ec

fixing that

@A-Paul Since you didn't reply (assuming you have just a few more PRs to merge), I turned the remaining *_POS macros into decimals.
It isn't important to be able to see which bit is where in a bit offset or a length; the value is - after all, most humans and many data sheets still use decimals to work with.
I, personally, would like meta information to stick out more between register values.

Regarding the braces: The RIOT coding guide doesn't seem to include that.
Why should straightforward integer constants be surrounded by braces?
I think it's pollution (for the eye and the environment).

Since we want to get this merged, you should just make ultimate decisions.
Do you want select macros to include braces or all of them?
I'm not able to deduce a pattern from the existing code base.

I, personally, would like meta information to stick out more between register values.

My intention was to get more consistent notation. If you want certain groups of defines to "stick out", there is also the option of reordering the blocks.

Do you want select macros to include braces or all of them?

I prefer to embrace all of them. :D
I's a best practice which is not bound to RIOT. And you're right, for now it's not consistent in existing codebase.
But, in general, having missed something in the past shouldn't prevent you from doing it better in the future. ;-)

@yogo1212 as I mentioned here all " PRIu32 " format should be changed to " PRIx32 " in order to correctly display the error codes... I've been trying to understand the famous 0x130 for days now... in vain since it's actually 0x82! 😞

@yogo1212 I solved the 0x82 mystery! We are actually missing something in the current radio setup. In the function void rfc_prepare(void), we should add the following lines after configuring the RFC power domain:

/* RFC MODE SELECTION */
    PRCM->RFCMODESEL = PRCM_RFCMODESEL_CURR_MODE5; /* CC2650 requires MODE5 - no doc available on RFCMODESEL*/

Did I mention that there is absolutely no documentation on teh RFCMODESEL register? I found out about it through this forum thread.
Based on the Contiki implementation, each MCU of the 26xx family required a specific value in RFCMODESEL: without it, it is impossible to use any of the non-general radio command (BLE, IEEE, proprietary related commands).

I thought it would make more sense if this config were included in this PR rather than a protocol-specific one.

@fvcoen impressive!
you don't cease to amaze me 👍
commits going in your name

Is anyone currently working on this?

In addition to setting RFCMODESEL, I found that additional steps (undocumented, of course) were required (to get hf_xosc running) in order to get ble advertisements working. If this PR is going to be merged, I can submit a followup PR. I looked briefly to see if anyone had an active branch where this is still being worked on but I didn't find one.

The additional steps are too verbose to quote. There are some required trim values to set (hf_xosc won't start otherwise), and a rom function to call to actually switch to hf_xosc.

@benemorius hi :-)
(broke my debug probe - gotta get a new one)
would you want to open a PR against this branch or rather wait for this to be merged first?
i don't know how long that will take.

what starts working after taking those steps you are talking about?

just realised, why...
@A-Paul i forgot to ping you. shame on me :-(
is there something that still needs fixing?

would you want to open a PR against this branch or rather wait for this to be merged first?

I'll open a PR against your cc26x0_rfc branch if that's ok.

what starts working after taking those steps you are talking about?

Those steps get the microcontroller switched over to hf_xosc, which is required for the radio. (Actually, I suspect the radio may be working already, but you can't tell because hf_rcosc isn't accurate enough.) Then you need only add the code to send ble advertisements and the advertisements will work.

Here are the changes, including test code which sends advertisements. I'll either clean this up and then open a PR, or open a PR and then clean it up. I'm actually changing my focus to get 15.4 working now so I don't know how much further I'll go on this.

yogo1212/RIOT@cc26x0_rfc...benemorius:cc26x0_rfc_works

@benemorius were there any additional steps you have taken to be able to receive beacons broadcasted by RIOT?
a lot of the stuff you added in your trim.h is already there elsewhere and there are places to add the stuff that isn't :-)

i've rearranged your changes in here: yogo1212#13.
if you object, please say so ;-)

What is the latest here?

@OlegHahm is there a way that one of you could test https://github.com/benemorius/RIOT/tree/cc26x0_rfc_works?
i've checked with multiple probes/sensortags and haven't been able to receive beacons on any devices (i have a slightly cleaner version of that code here yogo1212#13).

just a five minute check whether that code works ;-)

@yogo1212 maybe you can ask @haukepetersen now that he is more or less back ;)

@yogo1212 I have several TI sensortags available, and could help with testing - please elaborate what to test and how. The referenced repos/branches a kind of outdated compared to latest RIOT master. And whats the difference to the code in this PR?

@emmanuelsearch nice to know

@sming hi :-)
@haukepetersen

the code at https://github.com/benemorius/RIOT/tree/cc26x0_rfc_works is supposed to emit beacons but it isn't for me :-(
can someone confirm it's working?

@smlng ping?

@sming that's why I pinged @smlng ;-). And sorry for including you into this discussion :-/.

No progress > 1 year, closing as memo for now.

@smlng ack