Hi Mark WB,

You are right. The network steering process needs to access the tokens(read/compare) multiple times and these should be done in critical sections which might postpone your timer interrupt.

Can I know what is the cache size you allocate in NVM3 Library plugin? It should be larger than the object size(number of basic tokens + number of elements of indexed tokens). You can try larger cache size to see whether it shorten the critical sections in network steering plugin.

Hi HYL,

Thank you for the confirmation. 

It is currently set to the default 200.

I will try increasing it. How do I determine the number of basic tokens and number of elements of indexed tokens? 

Mark

Hi HYL,

Thank you for the confirmation. 

It is currently set to the default 200.

I will try increasing it. 

Mark

Stack is EmberNet 6.6.3.0

I have an app that uses NVM3 and network steering plugins and I have a timer to generate a hard time event. I have found that during network steering, the timer interrupt pauses for about 200 to 400 ms. and it appears to coincide with the following CLI output

Start Joining...NWK Steering State: Scan Primary Channels and use Install Code
Error: NWK Steering could not setup security: 0xB5
NWK Steering State: Scan Secondary Channels and use Install Code
Error: NWK Steering could not setup security: 0xB5
NWK Steering State: Scan Primary Channels and Use Centralized Key

and 

NWK Steering State: Scan Primary Channels and Use Distributed Key

and

NWK Steering State: Scan Secondary Channels and Use Distributed Key

My guess is that network steering is retrieving keys from token storage and the NVM3 is turning off interrupts for extended periods of time. Is this expected behaviour? 

I am currently working around it by using SimEEPROM 1, but is there a solution for NVM3?

The root cause was the erasing the flash was taking longer than the watchdog time out period

I have found the solution by looking at the way the CLI command plugin slot-manager erase-slot. This uses the slot manager plugin command

uint8_t emberAfPluginSlotManagerEraseSlot(uint32_t slotId)

Looking at the implementation, it feeds the watchdog while erasing  the slot one page at a time.

The route cause was the erasing the flash was taking longer than the watchdog time out period

I have found the solution by looking at the way the CLI command plugin slot-manager erase-slot. This uses the slot manager plugin command

uint8_t emberAfPluginSlotManagerEraseSlot(uint32_t slotId)

Looking at the implementation, it feeds the watchdog while erasing  the slot one page at a time.

I have found the answer by looking at the way the CLI command plugin slot-manager erase-slot. This uses the slot manager plugin command

uint8_t emberAfPluginSlotManagerEraseSlot(uint32_t slotId)

Looking at the implementation, it feeds the watchdog while erasing  the slot one page at a time.

I have found the answer by looking at the way the CLI command plugin slot-manager erase-slot. This uses the slot manager plugin command

uint8_t emberAfPluginSlotManagerEraseSlot(uint32_t slotId)

Looking at the implementation, it feeds the watchdog while erasing  the slot one page at a time.

I am attempting to add BLE OTA to a zigbee project using gecko sdk suite 2.6 . I have created a Dynamic Multiprotocol application. I have it connecting and I can write to the OTA control and data attributes. However, when I call bootloader_eraseStorageSlot() from emberAfPluginBleEventCallback(), i get a watchdog reset. 

Can anyone help to fix this?