New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIZwiki-W7500 timing issues #1524

Closed
ghost opened this Issue Feb 3, 2016 · 16 comments

Comments

Projects
None yet
6 participants
@ghost

ghost commented Feb 3, 2016

Hello!

I'm having issues performing correct timing for 1-Wire operations (such as reading a DS18B20 temperature sensor) on WIZwiki-W7500 platform. Other bitbanged protocols like the one in use for DHT11/22 sensors also seem to fail.

Take this code as example, since it explicits microseconds time delays: https://developer.mbed.org/forum/mbed/topic/101/?page=1#comment-829

On STM32 NUCLEO-F446RE and F303K8 it works just fine and the temperature is read correctly. Timing is also spot on, see this logic analyzer trace:

screenshot from 2016-02-03 17 36 31

On WIZwiki-W7500 I can't really say the same:
screenshot from 2016-02-03 17 38 52

Could this be related to the choice of SystemCoreClock and internal Xtal in #1237, which has not been fixed?

Thank you for your help.

@VladimirAkopyan

This comment has been minimized.

Show comment
Hide comment
@VladimirAkopyan

VladimirAkopyan Feb 15, 2016

I have this problem too, OneWire protocol is unusable

VladimirAkopyan commented Feb 15, 2016

I have this problem too, OneWire protocol is unusable

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 16, 2016

Glad to know it's not just my problem. cc @hjjeon0608 ?

ghost commented Feb 16, 2016

Glad to know it's not just my problem. cc @hjjeon0608 ?

@hjjeon0608

This comment has been minimized.

Show comment
Hide comment
@hjjeon0608

hjjeon0608 Feb 16, 2016

Contributor

Add the below code into top of main, and test one more plz.
I think also because of clock speed.
*(volatile uint32_t *)(0x41001014) = 0x0060100; //clock setting 48MH
wait_ms(100);

Contributor

hjjeon0608 commented Feb 16, 2016

Add the below code into top of main, and test one more plz.
I think also because of clock speed.
*(volatile uint32_t *)(0x41001014) = 0x0060100; //clock setting 48MH
wait_ms(100);

@Willem23

This comment has been minimized.

Show comment
Hide comment
@Willem23

Willem23 Feb 17, 2016

Contributor

Adding the above code to main will change the SystemCoreClock to the desired value. Note however that any objects that depend on this clock and that were declared as global before main() will now have incorrect timing settings. You need for example to explicitly call serial.baud(9600) to get the correct baudrate again, same for I2C, SPI bitrates etc. This wont be necessary when the systemclock is set to 48MHz as part of the regular system init which is automatically called before anything else.

Contributor

Willem23 commented Feb 17, 2016

Adding the above code to main will change the SystemCoreClock to the desired value. Note however that any objects that depend on this clock and that were declared as global before main() will now have incorrect timing settings. You need for example to explicitly call serial.baud(9600) to get the correct baudrate again, same for I2C, SPI bitrates etc. This wont be necessary when the systemclock is set to 48MHz as part of the regular system init which is automatically called before anything else.

@hjjeon0608

This comment has been minimized.

Show comment
Hide comment
@hjjeon0608

hjjeon0608 Feb 18, 2016

Contributor

Serial clock is always hold, so you don't care of serial baud rate. I2C is used by GPIO, so I2C bit rates is dependent on operation clock not I2C setting clock. SPI bitrate is changed by setting function so don't care of operating clock.

Contributor

hjjeon0608 commented Feb 18, 2016

Serial clock is always hold, so you don't care of serial baud rate. I2C is used by GPIO, so I2C bit rates is dependent on operation clock not I2C setting clock. SPI bitrate is changed by setting function so don't care of operating clock.

@hjjeon0608

This comment has been minimized.

Show comment
Hide comment
@hjjeon0608

hjjeon0608 Feb 18, 2016

Contributor

And I will change global clock as maximum clock ASAP.

Contributor

hjjeon0608 commented Feb 18, 2016

And I will change global clock as maximum clock ASAP.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 18, 2016

Hello,
I've run this simple code and I've taken a few more measurements:

#include "mbed.h"
DigitalOut out(D8);
int main(void) {
    while(1) {
        out = !out;
        wait_us(5);
    }
}

At 20 MHz SystemCoreClock a wait_us(5) is actually ~21uS:
screenshot from 2016-02-18 11 10 11

At 48 MHz SystemCoreClock a wait_us(5) is ~10uS:
screenshot from 2016-02-18 11 11 59

On a different platform, such as STM32F446RE, wait_us(5) is ~5uS:
screenshot from 2016-02-18 11 14 52

I haven't digged through the code implementation of that delay (yet) but in my opinion it either means that:

  • setting the timer interrupt which fires on delay expiry is done without caring about the current clock setting and/or
  • there's a massive code overhead around toggling a simple pin

In any case, bitbanged protocols (1-Wire, DHT sensors...) still fail.

Let me know if you need more tests.

ghost commented Feb 18, 2016

Hello,
I've run this simple code and I've taken a few more measurements:

#include "mbed.h"
DigitalOut out(D8);
int main(void) {
    while(1) {
        out = !out;
        wait_us(5);
    }
}

At 20 MHz SystemCoreClock a wait_us(5) is actually ~21uS:
screenshot from 2016-02-18 11 10 11

At 48 MHz SystemCoreClock a wait_us(5) is ~10uS:
screenshot from 2016-02-18 11 11 59

On a different platform, such as STM32F446RE, wait_us(5) is ~5uS:
screenshot from 2016-02-18 11 14 52

I haven't digged through the code implementation of that delay (yet) but in my opinion it either means that:

  • setting the timer interrupt which fires on delay expiry is done without caring about the current clock setting and/or
  • there's a massive code overhead around toggling a simple pin

In any case, bitbanged protocols (1-Wire, DHT sensors...) still fail.

Let me know if you need more tests.

@VladimirAkopyan

This comment has been minimized.

Show comment
Hide comment
@VladimirAkopyan

VladimirAkopyan Feb 19, 2016

Thanks for runnign tests lcafaro, I don't have a logic analyser, so all I can tell is that it doesn't work, but I don't have any way of knowing why.
Could you sample different delays to know how the board reacts? In your original screenshot the board takes extra 71µs to react, but here it's 15 and 5, or a factor of 4 and 2.
So it seems to be neither a constant offset, nor a liner overhead. What the hell?

VladimirAkopyan commented Feb 19, 2016

Thanks for runnign tests lcafaro, I don't have a logic analyser, so all I can tell is that it doesn't work, but I don't have any way of knowing why.
Could you sample different delays to know how the board reacts? In your original screenshot the board takes extra 71µs to react, but here it's 15 and 5, or a factor of 4 and 2.
So it seems to be neither a constant offset, nor a liner overhead. What the hell?

@hjjeon0608

This comment has been minimized.

Show comment
Hide comment
@hjjeon0608

hjjeon0608 Feb 22, 2016

Contributor

I had tested.
First, I explain about wait function.

void wait_us(int us) {
    uint32_t start = us_ticker_read();
    while ((us_ticker_read() - start) < (uint32_t)us);
}

and us_ticker_read() is

uint32_t us_ticker_read() {
    if (!us_ticker_inited) us_ticker_init();
    return (TIMER_1->TCR);
}

TIMER_1-> TCR is timer register and equal to PWM_CH1->TCR.

And I made and tested absolute delay about function.
Below function is equal(more fast) to the wait_us() function.

void wiz_wait_us(uint32_t us) {
    int start = PWM_CH1->TCR;
    while( (PWM_CH1->TCR - start) < us );
}

And I use value of us as 0. So the while is performed 1 time.
main code is

int main() {
    *(volatile uint32_t *)(0x41001014) = 0x0060100; //clock setting 48MH
    while(1) {
        out = !out;
        wiz_wait_us(0);
    }
}

The result is 4.45us
2016-02-22 09 42 09

I think 4.45us is absolute delay. If use wait_us(100), the wait time is 105us. If use wait_us(50), the wait time is 55us.
I think It is because gpio toggling time or performed time of instruction or access register. W7500 has M0 but STM32F446RE has M4. M4 performs faster than M0. So STM32F446RE can implemented more detailed.

Contributor

hjjeon0608 commented Feb 22, 2016

I had tested.
First, I explain about wait function.

void wait_us(int us) {
    uint32_t start = us_ticker_read();
    while ((us_ticker_read() - start) < (uint32_t)us);
}

and us_ticker_read() is

uint32_t us_ticker_read() {
    if (!us_ticker_inited) us_ticker_init();
    return (TIMER_1->TCR);
}

TIMER_1-> TCR is timer register and equal to PWM_CH1->TCR.

And I made and tested absolute delay about function.
Below function is equal(more fast) to the wait_us() function.

void wiz_wait_us(uint32_t us) {
    int start = PWM_CH1->TCR;
    while( (PWM_CH1->TCR - start) < us );
}

And I use value of us as 0. So the while is performed 1 time.
main code is

int main() {
    *(volatile uint32_t *)(0x41001014) = 0x0060100; //clock setting 48MH
    while(1) {
        out = !out;
        wiz_wait_us(0);
    }
}

The result is 4.45us
2016-02-22 09 42 09

I think 4.45us is absolute delay. If use wait_us(100), the wait time is 105us. If use wait_us(50), the wait time is 55us.
I think It is because gpio toggling time or performed time of instruction or access register. W7500 has M0 but STM32F446RE has M4. M4 performs faster than M0. So STM32F446RE can implemented more detailed.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 22, 2016

@hjjeon0608 thanks for clarifying that.

In fact, I've done some more testing and I've found out that as you say the main issue is not the timer itself, but the GPIO toggling time, and the change in direction register.

1-Wire data is written by "tri-stating" the output so that the external resistor can pull up the line and make a logic high state, like this:

int main() {
  while(true) {
      *(volatile uint32_t *)(0x41001014) = 0x0060100;
      DigitalOut pin_out(D8);
      pin_out = 0;
      DigitalIn pin_in(D8);
    }
}

What's really slow is the re-declaration of DigitalOut and DigitalIn, which takes ~30uS. Using a single DigitalInOut is even slower (~48uS):

int main() {
  while(true) {
      *(volatile uint32_t *)(0x41001014) = 0x0060100;
      DigitalInOut pin(D8);
      pin.output();
      pin = 0;
      pin.input();
    }
}

Since the W7500 even at 48 MHz can't keep up with that, I guess our best option for faster GPIO toggling is to perform the operations directly via the gpio_mode(), gpio_dir() and gpio_set() primitives.

So either we re-write the code or find a simpler way out, such as hardware offloading the communication by the use of some peripheral that the W7500 has, such as SPI or I2C (I've tested the latter and it works just fine). This would mean replacing DS18B20/DHTxx sensors with something different and possibly more expensive though.

ghost commented Feb 22, 2016

@hjjeon0608 thanks for clarifying that.

In fact, I've done some more testing and I've found out that as you say the main issue is not the timer itself, but the GPIO toggling time, and the change in direction register.

1-Wire data is written by "tri-stating" the output so that the external resistor can pull up the line and make a logic high state, like this:

int main() {
  while(true) {
      *(volatile uint32_t *)(0x41001014) = 0x0060100;
      DigitalOut pin_out(D8);
      pin_out = 0;
      DigitalIn pin_in(D8);
    }
}

What's really slow is the re-declaration of DigitalOut and DigitalIn, which takes ~30uS. Using a single DigitalInOut is even slower (~48uS):

int main() {
  while(true) {
      *(volatile uint32_t *)(0x41001014) = 0x0060100;
      DigitalInOut pin(D8);
      pin.output();
      pin = 0;
      pin.input();
    }
}

Since the W7500 even at 48 MHz can't keep up with that, I guess our best option for faster GPIO toggling is to perform the operations directly via the gpio_mode(), gpio_dir() and gpio_set() primitives.

So either we re-write the code or find a simpler way out, such as hardware offloading the communication by the use of some peripheral that the W7500 has, such as SPI or I2C (I've tested the latter and it works just fine). This would mean replacing DS18B20/DHTxx sensors with something different and possibly more expensive though.

@hjjeon0608

This comment has been minimized.

Show comment
Hide comment
@hjjeon0608

hjjeon0608 Feb 22, 2016

Contributor

pin.output() and pin.input() call the function of gpio_dir(). So both function is equal.

void output() {
    gpio_dir(&gpio, PIN_OUTPUT);
}
void input() {
    gpio_dir(&gpio, PIN_INPUT);
}

And DigitalOut is

DigitalOut(PinName pin) : gpio() {
    gpio_init_out(&gpio, pin);
}

And gpio_init_out(); is

static inline void _gpio_init_out(gpio_t* gpio, PinName pin, PinMode mode, int value)
{
    gpio_init(gpio, pin);
    if (pin != NC) {
        gpio_write(gpio, value);
        gpio_dir(gpio, PIN_OUTPUT);
        gpio_mode(gpio, mode);
    }
}

So

int main() {
  while(true) {
      *(volatile uint32_t *)(0x41001014) = 0x0060100;
      DigitalInOut pin(D8);
      pin.output();
      pin = 0;
      pin.input();
    }
}

it should be faster than

int main() {
  while(true) {
      *(volatile uint32_t *)(0x41001014) = 0x0060100;
      DigitalOut pin_out(D8);
      pin_out = 0;
      DigitalIn pin_in(D8);
    }
}
Contributor

hjjeon0608 commented Feb 22, 2016

pin.output() and pin.input() call the function of gpio_dir(). So both function is equal.

void output() {
    gpio_dir(&gpio, PIN_OUTPUT);
}
void input() {
    gpio_dir(&gpio, PIN_INPUT);
}

And DigitalOut is

DigitalOut(PinName pin) : gpio() {
    gpio_init_out(&gpio, pin);
}

And gpio_init_out(); is

static inline void _gpio_init_out(gpio_t* gpio, PinName pin, PinMode mode, int value)
{
    gpio_init(gpio, pin);
    if (pin != NC) {
        gpio_write(gpio, value);
        gpio_dir(gpio, PIN_OUTPUT);
        gpio_mode(gpio, mode);
    }
}

So

int main() {
  while(true) {
      *(volatile uint32_t *)(0x41001014) = 0x0060100;
      DigitalInOut pin(D8);
      pin.output();
      pin = 0;
      pin.input();
    }
}

it should be faster than

int main() {
  while(true) {
      *(volatile uint32_t *)(0x41001014) = 0x0060100;
      DigitalOut pin_out(D8);
      pin_out = 0;
      DigitalIn pin_in(D8);
    }
}
@hjjeon0608

This comment has been minimized.

Show comment
Hide comment
@hjjeon0608

hjjeon0608 Feb 22, 2016

Contributor

If you want to up the speed, use W7500 driver not mbed library.
#include "W7500x_gpio.h"
To set output :
void GPIO_OutEnSet(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)
To set input :
void GPIO_OutEnClr(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)

Example
GPIO_OutEnSet(PAD_PA, GPIO_Pin_4);
GPIO_OutEnClr(PAD_PC, GPIO_Pin_12);
PAD group is A,B,C and D. But at mbed, D is not used.
Pin number is 0 ~ 15.

Contributor

hjjeon0608 commented Feb 22, 2016

If you want to up the speed, use W7500 driver not mbed library.
#include "W7500x_gpio.h"
To set output :
void GPIO_OutEnSet(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)
To set input :
void GPIO_OutEnClr(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)

Example
GPIO_OutEnSet(PAD_PA, GPIO_Pin_4);
GPIO_OutEnClr(PAD_PC, GPIO_Pin_12);
PAD group is A,B,C and D. But at mbed, D is not used.
Pin number is 0 ~ 15.

@VladimirAkopyan

This comment has been minimized.

Show comment
Hide comment
@VladimirAkopyan

VladimirAkopyan Feb 22, 2016

Ok, thanks. And how fast is that?

VladimirAkopyan commented Feb 22, 2016

Ok, thanks. And how fast is that?

@hjjeon0608

This comment has been minimized.

Show comment
Hide comment
@hjjeon0608

hjjeon0608 Feb 22, 2016

Contributor

I don't check exact time but gpio_dir() function is

void gpio_dir(gpio_t *obj, PinDirection direction)
{
    MBED_ASSERT(obj->pin != (PinName)NC);
    obj->direction = direction;

    pin_function(obj->pin, WIZ_PIN_DATA(obj->direction, obj->mode, 1));
}

And pin_function() is

void pin_function(PinName pin, int data) {
    MBED_ASSERT(pin != (PinName)NC);
    // Get the pin informations
    uint32_t mode  = WIZ_PIN_MODE(data);
    uint32_t pupd  = WIZ_PIN_PUPD(data);
    uint32_t afnum = WIZ_PIN_AFNUM(data);

    uint32_t port_num = WIZ_PORT(pin);
    uint32_t pin_index  = WIZ_PIN_INDEX(pin);

    GPIO_TypeDef *gpio;

    // Configure Alternate Function
    // Warning: Must be done before the GPIO is initialized
    switch (afnum) {
        case 0:
            HAL_PAD_AFConfig((PAD_Type)port_num, (uint16_t)pin_index, (PAD_AF_TypeDef)Px_AFSR_AF0);
            break;
        case 1:
            HAL_PAD_AFConfig((PAD_Type)port_num, (uint16_t)pin_index, (PAD_AF_TypeDef)Px_AFSR_AF1);
            break;
        case 2:
            HAL_PAD_AFConfig((PAD_Type)port_num, (uint16_t)pin_index, (PAD_AF_TypeDef)Px_AFSR_AF2);
            break;
        case 3:
            HAL_PAD_AFConfig((PAD_Type)port_num, (uint16_t)pin_index, (PAD_AF_TypeDef)Px_AFSR_AF3);
            break;
        default:
            break;
    }

    if(mode == WIZ_MODE_AF)
        return;

    // Configure GPIO
    gpio = (GPIO_TypeDef *)Get_GPIO_BaseAddress(port_num);

    GPIO_InitTypeDef GPIO_InitStructure;
    GPIO_InitStructure.GPIO_Pin       = pin_index;
    GPIO_InitStructure.GPIO_Mode      = (GPIOMode_TypeDef)mode;
    GPIO_InitStructure.GPIO_Pad       = (GPIOPad_TypeDef)pupd;
    HAL_GPIO_Init(gpio, &GPIO_InitStructure);
}

So I guess just one register access time is faster. Maybe the time is a little fast.

Contributor

hjjeon0608 commented Feb 22, 2016

I don't check exact time but gpio_dir() function is

void gpio_dir(gpio_t *obj, PinDirection direction)
{
    MBED_ASSERT(obj->pin != (PinName)NC);
    obj->direction = direction;

    pin_function(obj->pin, WIZ_PIN_DATA(obj->direction, obj->mode, 1));
}

And pin_function() is

void pin_function(PinName pin, int data) {
    MBED_ASSERT(pin != (PinName)NC);
    // Get the pin informations
    uint32_t mode  = WIZ_PIN_MODE(data);
    uint32_t pupd  = WIZ_PIN_PUPD(data);
    uint32_t afnum = WIZ_PIN_AFNUM(data);

    uint32_t port_num = WIZ_PORT(pin);
    uint32_t pin_index  = WIZ_PIN_INDEX(pin);

    GPIO_TypeDef *gpio;

    // Configure Alternate Function
    // Warning: Must be done before the GPIO is initialized
    switch (afnum) {
        case 0:
            HAL_PAD_AFConfig((PAD_Type)port_num, (uint16_t)pin_index, (PAD_AF_TypeDef)Px_AFSR_AF0);
            break;
        case 1:
            HAL_PAD_AFConfig((PAD_Type)port_num, (uint16_t)pin_index, (PAD_AF_TypeDef)Px_AFSR_AF1);
            break;
        case 2:
            HAL_PAD_AFConfig((PAD_Type)port_num, (uint16_t)pin_index, (PAD_AF_TypeDef)Px_AFSR_AF2);
            break;
        case 3:
            HAL_PAD_AFConfig((PAD_Type)port_num, (uint16_t)pin_index, (PAD_AF_TypeDef)Px_AFSR_AF3);
            break;
        default:
            break;
    }

    if(mode == WIZ_MODE_AF)
        return;

    // Configure GPIO
    gpio = (GPIO_TypeDef *)Get_GPIO_BaseAddress(port_num);

    GPIO_InitTypeDef GPIO_InitStructure;
    GPIO_InitStructure.GPIO_Pin       = pin_index;
    GPIO_InitStructure.GPIO_Mode      = (GPIOMode_TypeDef)mode;
    GPIO_InitStructure.GPIO_Pad       = (GPIOPad_TypeDef)pupd;
    HAL_GPIO_Init(gpio, &GPIO_InitStructure);
}

So I guess just one register access time is faster. Maybe the time is a little fast.

@VladimirAkopyan

This comment has been minimized.

Show comment
Hide comment
@VladimirAkopyan

VladimirAkopyan Mar 6, 2016

So, has anybody tested if directly editing the register is an improvement?
@hjjeon0608 , aren't interested to find out where it's getting delayed for unusually long amount of time?

VladimirAkopyan commented Mar 6, 2016

So, has anybody tested if directly editing the register is an improvement?
@hjjeon0608 , aren't interested to find out where it's getting delayed for unusually long amount of time?

@ciarmcom

This comment has been minimized.

Show comment
Hide comment
@ciarmcom

ciarmcom Aug 1, 2016

Member

ARM Internal Ref: IOTMORF-220

Member

ciarmcom commented Aug 1, 2016

ARM Internal Ref: IOTMORF-220

@ciarmcom ciarmcom added the mirrored label Aug 1, 2016

@sg- sg- removed the mirrored label Aug 12, 2016

@sg- sg- added the devices: wiznet label Jan 16, 2017

deepakvenugopal added a commit to deepakvenugopal/mbed-os that referenced this issue Feb 9, 2018

Squashed 'features/nanostack/FEATURE_NANOSTACK/sal-stack-nanostack/' …
…changes from c9bf20f..43c7ec2

43c7ec2 Merge branch 'release_internal' into release_external
ed76459 Merge pull request ARMmbed#1558 from ARMmbed/IOTTHD-2195
8d3bcb7 Add new function to unit tests
56f66a4 Review correction
8b7d018 Move indirect queue size public API to net_interface
d877c9e Review corrections
c25e476 Remove Eclipse project files for external release
d51f442 Merge branch 'release_internal' into release_external
135c48d Increase Thread SED buffer size for big packets
70931a7 Fix indirect queue packet ordering
10e51a4 API for changing Thread SED parent buffer size
6122d24 dereference null value issue fixed. (ARMmbed#1557)
d1378dc Clear IPv6 neighbor cache in partition change (ARMmbed#1554)
7610e91 Child neighbor entry updates (ARMmbed#1550)
c727295 cleared neighbours with child address that are not ours (ARMmbed#1549)
80b4d72 Thread partition merge mode TLV change (ARMmbed#1546)
edd7599 RLOC was updated before clearing child info (ARMmbed#1547)
a666056 router short address set to 0xfffe for non routers (ARMmbed#1543)
759ab05 delete route set and link set entries for a router ID (ARMmbed#1540)
23a1265 REED advertisement handling (Thread spec 5.16.3): (ARMmbed#1535)
0a32cb4 added active and pending timestamps to child update response (ARMmbed#1533)
d0eec80 Fix error case memory leak (ARMmbed#1537)
da9860f Pending set after link sync (ARMmbed#1526)
ffa1569 Thread router network data update after link sync (ARMmbed#1530)
3b46d8d Fix defects found by coverity (ARMmbed#1529)
3a57101 Fix compiler warnings and update traces (ARMmbed#1523)
c288227 Add extension check for partition weight drop in parent selection (ARMmbed#1521)
d8dea28 network data cleared after router forms new partition (ARMmbed#1525)
44a85e5 removed router flagging for thread_management_server file (ARMmbed#1524)
1cbced9 Merge pull request ARMmbed#1520 from ARMmbed/IOTTHD-2105_2
3d07365 Review corrections to network data clearing
22a0375 Clear network data from lost children
ffd8517 added a new thread management function (ARMmbed#1519)
80af9cb Thread BR network data clearing (ARMmbed#1518)
5a6f6b5 thread nvm valgrind uninitialized data fix (ARMmbed#1517)
d5e2198 Add API for partition weighting set (ARMmbed#1513)
8811d6f multicast forwarding scope changed and address registration updated. (ARMmbed#1516)
c277384 printf to tr_info (ARMmbed#1515)
bb21264 Thread combined nvm test (ARMmbed#1507)
76f7725 Primary BBR fixes from interop (ARMmbed#1512)
12ed5ab FHSS unit test: fixed fhss mac interface test (cherry picked from commit 805eb42e4416b00cc018dc32dceb353d0b6c8bb6)
dd21ea9 Remvoed unnecessary trace print's.
cb6e78b FHSS unit test: fixed fhss beacon tasklet test (cherry picked from commit abe6d671b058f4f069741eab24d51e4d62d550b0)
237b3d4 Fhss info print (ARMmbed#1486)
0f39a47 FHSS: Do not update synch monitor right after superframe change (cherry picked from commit 99d50ad9d7f8dad80f10c2a4303f4e75ab31a3c2)
c9a098f Fixed Timeoout force which actually never generate timeout.
957c7fb Pana server and client update:
ae230e5 FHSS: Update Beacon synch info in critical state
84bd8a4 FHSS: Synchronization must be done in critical state
fb1b163 Pan coordinator blacklist update
39fe6ba Added missing HAVE_RPL compiler flag
16a1bc5 MLE bootsrap and message timeout update
eeb2d39 enable BBR to support multicast registration in non   commercial networks (ARMmbed#1509)
4ea2bf8 uri modified. (ARMmbed#1510)
f443853 timeout corrected for neighbour entry (ARMmbed#1508)
ea93c1f Thread dev conf taken use (ARMmbed#1503)
5d5b239 bug fix in bbr start (ARMmbed#1505)
8dbd521 commented a trace. (ARMmbed#1504)
145dbdf device conf copy fix (ARMmbed#1502)
f60268f eid&random mac moved to device conf struct (ARMmbed#1497)
df18635 Let MAC choose address when mesh forwarding
42f916b fixed BBR stop to remove network data and routing information (ARMmbed#1500)
e058c2a pbbr changes (ARMmbed#1499)
1ece307 Merge pull request ARMmbed#1485 from ARMmbed/merge_release_back
dda8164 thread address handling updated. (ARMmbed#1496)
1dc21a1 thread extension fixes. (ARMmbed#1495)
543fe98 Merge branch 'release_internal'
bade70e Dua req changes (ARMmbed#1494)
1979df8 added status to MLR response and implemeted BMLR.ntf multicast. (ARMmbed#1492)
1807c01 mle class initialisation (ARMmbed#1488)
d809831 Merge pull request ARMmbed#1479 from ARMmbed/merge_release_to_master
bce812d Update license to Thread test file (ARMmbed#1483)
aaa4b1f Revert eclipse file removal

git-subtree-dir: features/nanostack/FEATURE_NANOSTACK/sal-stack-nanostack
git-subtree-split: 43c7ec255fd25e21e272c7373d011791327f8724
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment