Setting Static Random Address does not work

[Anonymous]

Hi there,

I am trying to set a static random address on a BCM20737S device using the API-call: blecm_set_static_random_bd_addr()

I´ve seen several threads which describe this procedure. I did it like this:

• Added APP_PATCHES_AND_LIBS += bd_addr_control.a to my project makefile
• Included #include "blecm_set_static_bd_addr.h" in my project
• Called blecm_set_static_random_bd_addr(new_bd_addr) at the end of my app_create()-function, with new_bd_addr as a UINT8 array of size 6
• Downloaded the binary with setting BD_ADDR to 0xFFFFFFFFFFFF

After starting advertising, the address 0xFFFFFFFFFFFF is always the same. Cycling power or resetting the device does not change anything.

I tried it my own application and also with the my_beacon sample application. Both not working.

What am I missing?

BR,

Alex

[BoonT_56 · Accepted solution]

I did the following on a tag3 with the hello_sensor application:

1) add the line "APP_PATCHES_AND_LIBS += bd_addr_control.a" into my makefile

2) add the line "blecm_set_static_random_bd_addr()" in "hello_sensor_create(void)"

3) compile the app with this target "hello_sensor-BCM920736TAG_Q32 BT_DEVICE_ADDRESS=ffffffffffff download"

I got the app up and running with a random address for the first boot, but this address is fixed in subsequent boot-ups.

Let me know if it helps.

[Anonymous]

As you see in my original thread, I did exactly the steps you just described. It is not working.

But I found out that this might be related to the BCM20737S hardware. Using this hardware with my example results in the hardware always using 0xFFFFFFFFFFFF as BD_ADDRR.

If I use the same piece of software on the 20737_LE_TAG4 board, it is working. The MAC changes after first power on.

So is this function confirmed to work on the BCM20737S module?

[BoonT_56]

I repeat the above on a WICED SENSE 1 which used the 20737S module. I was able to repeat the result of getting a random BD address on first boot and fixed subsequently.

[Anonymous]

Thanks for checking!

Still wondering why it is not working on my hardware but on the TAG board.

Are there different revisions of module in the market?

[BoonT_56]

Interestingly, I repeated your steps on my SENSE 1 and found that it works. I included the below into the (beginning instead of the end)

create function as you have posted:

UINT8 bd_addr[6];

blecm_set_static_random_bd_addr(bd_addr);

I am not aware of a new revision of the SiP module.

[Anonymous]

Hmmm, on my TAG-Boards it is also working without problems.

Same software on my custom PCB with 20737S does not work. Address stays 0xFFFFFFFFFFFF. The rest of the application is working without problems.

I also ran into another question: There is this header file blecm_set_static_bd_addr.h. If I include it, the function call blecm_set_static_random_bd_addr() expects an argument to store the new address in it. If I don´t include the header, it is possible to call the function without any argument. So what is difference and where is this stuff documented?

[BoonT_56]

blecm_set_static_random_bd_addr() should generate a compiler warning saying you are using an undeclared function. The default behavior at the calling site is to assume a function that takes a void parameter. But the called function assumes that there is a parameter, which is a pointer to an array of 6 bytes – so the result is undefined.

Perhaps you can try that route without the header file and with only the call function. Do also ensure that the ffffffffffff bd address is downloaded into the eeprom.

[Anonymous]

azurkan - did you resolve the problem with your custom board ?

I seem to have exactly the same problem here : after solving the include and linking issues downloading with 0xffffffffffff i have
my custom board always advertising with 0xffffffffffff - not showing the randomized adress even after POR.

[Anonymous]

Hello,

no, I couldn´t solve it and did not get it to work.

The workaround was that I have written a small Python-Script which modifies the generated HEX-File before every downloading/flashing-event and stores a random generated address in it.

BR,

Alex

[Anonymous]

Thx for the fast response Alex,

I've been setting BD_ADDR to fulfil the 48bits of a static random addres by using cgs modifications prior to hex generation for (pre)production.

Worked fine - but then recognized i still have the TxAdd flag in the advertsement is still showing public - not random.

Working - but i think not really in-line with btcore spec as it specifies the ADDR of 48-bits plus the TxRxbit.

Did not find a API way to control that flags directly, so i tried this way with the blecm_set_static_random_bd_addr() call

hoping it would do. But now TxAdd is still public and BD_ADDR is constantly 0xfffffffffff ....

Oh yes - from dbg uart traces i see that blecm_set_static_random_bd_addr() always returns 0 which means "FAIL" i guess from the .h (which it does as it does not update) .

/// Sets the bd_addr to a static random value and optionally commits to NV.

/// \param bd_addr OUT The static random bd_addr that was currently set. Buffer

/// must be long enough to hold the 6 byte BD_ADDR. Valid only

/// if commit succeeded. For the commit to succeed, device address

/// in NV must already be 0xFFFFFFFFFFFF.

/// \return TRUE on succes, FALSE on failure.

UINT8 blecm_set_static_random_bd_addr(UINT8* bd_addr);

Anyone an idea what am i missing ? the NVRAM should have 0xffffffffffff as entry as i see this as public BD ADDR in the BT Sniffer on the air ...

/holger