Bitcloud - SAMR21 Random Number Generator for Ext Addr - Page 1
Forum section: electronics / general

author: rfleming
author_rank: Regular Contributor
timestamp: July 18, 2016, 02:03:01 am
content: Hi Guys,First off, I wanted to ask if in ZigBee you're actually allowed to use any MAC I want, randomly generated, or do they have to be assigned at manufacturing and require the few upper bytes to denote the company that its associated too?E.g.I noticed that when sniffing many ZigBee products in Australia, I have found things like:[Extended Source: SilverSp_03:00:0b:1d:2f (00:13:50:03:00:0b:1d:2f)]Meaning the upper 3 bytes have been reserved for silver springs, a Smart Meter company.Do I have to follow the IEEE unique standard?EDIT: Can now get a randomly generated extended address by calling RF_RegReadReq(&regReq); 32 times (2 bits at a time) with the PHY_RSSI reg. Would be awesome if I could confirm the above though!Nonetheless, I have been trying to use the RNG feature on the SAMR21 and have been having a bit of trouble. I am unsure if I can actually access the register directly, or maybe I should be doing it through the stack somehow as the datasheet seems to lead me to believe that I should be using SPI to access the registers.I am trying to access the registers on the AT86RF233 RND_VALUE from the (register 0x06, PHY_RSSI) on the chip, but I am not 100% sure how to access this correctly.I have tried the following:uint8_t randNum = phyReadRegister(PHY_RSSI_REG);It seems to come back with random stuff sometimes, but that might just be general access to the main SAMR21 register that was changing at that time :|Any tips would be awesome

author: ataradov
author_rank: Super Contributor
timestamp: July 18, 2016, 05:15:23 am
content: Quote from: rfleming on July 18, 2016, 02:03:01 amThey have to be proper IEEE address. As usual, it is highly unlikely you will get conflicts, but if you do, you will have a problem.Quote from: rfleming on July 18, 2016, 02:03:01 amFor mass produced product - yes. Again, main factor here is not some punishment by authorities (they don't really exist here), but more of a company reputation thing.There is proper API for generating random numbers - RF_RandomReq().

author: rfleming
author_rank: Regular Contributor
timestamp: July 18, 2016, 06:55:53 am
content: Thanks for the advice once again Alex. Is this usually given by the ZigBee alliance when we get accreditation?I am trying to useCode:RF_RandomReq()now, however it seems to respond back with the same ID everytime, perhaps I need to allocate a buffer for it to store into?Code://globally definedRF_RandomReq_t regReq = {.numberOfBytes = 8,.RF_RandomConf = RF_Rand_Callback,};//callbackvoid RF_Rand_Callback(RF_RandomConf_t *conf){for (uint8_t i = 0; i < 8; i++){Global.AppNwkInfo.extAddr <<= 8;Global.AppNwkInfo.extAddr |= conf->buff;}}

author: ataradov
author_rank: Super Contributor
timestamp: July 18, 2016, 07:05:40 am
content: Quote from: rfleming on July 18, 2016, 06:55:53 amNo, it is IEEE thing. This looks like a good place to starthttp://standards.ieee.org/faqs/regauth.html#2Quote from: rfleming on July 18, 2016, 06:55:53 amYes, you need to allocate a static buffer and assign it to the "buff" field of the confirmation structure. Requests under 2 bytes will store the value in the field "value", so no additional allocation required.

author: ataradov
author_rank: Super Contributor
timestamp: July 18, 2016, 07:08:52 am
content: And this looks like the cheapest pricehttps://standards.ieee.org/develop/regauth/oui36/index.html($665)

author: rfleming
author_rank: Regular Contributor
timestamp: July 18, 2016, 11:45:13 pm
content: Quote from: ataradov on July 18, 2016, 07:08:52 amWe are going to look into this and get it done! boo yea!Quote from: ataradov on July 18, 2016, 07:05:40 amit appears that allocating a buffer doesn't quite work as well as id like. The "value" member of RF_RandomConf_t appears to keep getting randomly generated, but the buff member appears to be getting over ridden, or I haven't allocated it correctly.Code:uint8_t randomRegBuf; //allocated globallyregReq.confirm.buff = randomRegBufIf I got through the contents of buf to buff, they have some values in it, but are the same everytime, so probably isn't the correct random number. The buffer thta I allocated is all 0's.Is there supposed to be another way to assign the buffer? I thought I wasn't supposed to assign to "confirm" member as it was part of the callback parameters, not the request parameters.

author: ataradov
author_rank: Super Contributor
timestamp: July 18, 2016, 11:54:39 pm
content: Quote from: rfleming on July 18, 2016, 11:45:13 pmThey should be the same if the code you've shown is actually working. Check that the value (pointer) you assign to buff are the same before and after the call and that they are equal to your global buffer.Quote from: rfleming on July 18, 2016, 11:45:13 pmYeah, but stack never allocates the memory, so if confirmation requires variable length return, then it is requester's job to allocate that memory.Here is the snippet of the actual code:Code:for (j = 0; j < req->numberOfBytes; j++){do{for (i = 0; i < COUNT_OF_TWO_BITS_IN_BYTE; i++){RegPhyRssi_t reg;HAL_Delay(1);*((uint8_t *) &reg) = phyReadRegister(PHY_RSSI_REG);rnd = (rnd << 2) | ((uint8_t) reg.rndValue);}}while(!rnd);if (NULL != req->confirm.buff)req->confirm.buff = rnd;req->confirm.value = (uint16_t)(req->confirm.value << 8) | rnd;}As you can see confirm.value will be the same as the last two bytes of the buffer if buffer is not NULL.

author: rfleming
author_rank: Regular Contributor
timestamp: July 19, 2016, 01:15:34 am
content: In the code:Code:Global.regReq.confirm.buff = Global.randomRegBuf,RF_RandomReq(&Global.regReq);volatile int x = 5;x++;If I break on RF_RandomReq, the assignment has occured and I get the following in the debugger:Code:uint8_t *&Global.randomRegBuf0x20001528 <Global+4624> ""uint8_t *Global.regReq.confirm.buff0x20001528 <Global+4624> ""I step over the function onto the volatile definition and it pointer has changed location to null:Code:uint8_t *&Global.randomRegBuf0x20001528 <Global+4624> ""uint8_t *Global.regReq.confirm.buff0x0 <__vector_table>Perhaps I have defined my variables wrong or it is doing something funky?

author: ataradov
author_rank: Super Contributor
timestamp: July 19, 2016, 01:18:46 am
content: Quote from: rfleming on July 19, 2016, 01:15:34 amWhat you are doing looks correct. I'll have to check the full chain tomorrow then.Alternative solution would be to call it 4 times with 2 byte requests

author: rfleming
author_rank: Regular Contributor
timestamp: July 19, 2016, 01:28:50 am
content: Quote from: ataradov on July 19, 2016, 01:18:46 amThanks Alex!Haha yea, better than calling the read reg 32 times