[BitCloud] Joining failure

[danergo]

Hello,

I didn't find any previous topic for connection issues with BitCloud.
My chip is an ATMEGA256RFR2.

I'm using a firmware which proved to worked before on another chip (at least the connection part worked).
This is an ED, and it can't connect to the coordinator:

Code: [Select]


          DDRB |= (1<<PB3); //for test
          PORTB &= ~(1<<PB3);         

  NWK_JoinControl_t joinControl = {
    .method = NWK_JOIN_BY_DEFAULT,
    .secured = true,
    .discoverNetworks = true,
    .annce = true
  };
  CS_WriteParameter(CS_JOIN_CONTROL_ID, &joinControl);

  //Starting network (results in joining to or forming a ZigBee network)
  zdoStartReq.ZDO_StartNetworkConf = appZdoStartNetworkConf; //Setting the callback function
  ZDO_StartNetworkReq(&zdoStartReq); //Sending a request to the stack


static void appZdoStartNetworkConf(ZDO_StartNetworkConf_t *startInfo) {
  PORTB |= (1<<PB3); //TEST, but PB3 stays low.
  //Check if the node has successfully started the network
  if (ZDO_SUCCESS_STATUS == startInfo->status) {
    appState = APP_IN_NETWORK_STATE;

    if (deviceInterface.appDeviceTaskReset)
      deviceInterface.appDeviceTaskReset();
  }
  else
    appPostGlobalTask();
}

If I use ZDO_StartNetworkReq, the conf handler should be called, right? How else could I check what's going on? In my example, PB3 stays low.

A few more things:
1.)
After ZDO_StartNetworkReq, the whole stack seems freezed. Interrupts might arrive, but the stack is not responding for the posttasks that's initiated from the ISR's.
2.)
There was a hw error before, the balun's unbalanced pin was shorted to GND. This balun is now replaced, but the above situation is not changed at all.
3.)
Sometimes if I reset the board after this stackfreeze, the appZdoStartNetworkConf is called. (PDS is enabled, so I assume that on the first connection request it goes until some point, and freeze, but after reset, the stack thinks it was already connected before.)



Thanks!

[ataradov]

First of all, try to not modify Join Control parameters. It all should work by default and you only need it in a few obscure case.

appZdoStartNetworkConf() should always be called in response to ZDO_StartNetworkReq() and I don't really know a reason why it is not called. This is not normal.

What happens if you run completely unmodified WSNDemo ED on this hardware?

[danergo]

Thanks,

I didn't try WSNDemo on this HW yet, because I'm not sure what happens if WSNDemo tries do blink a LED on PB1 (for example), but on PB1 I have an input with an external pullup resistor.
Does it break the mega? Otherwise, if not, I'll try it later.

JoinControl was needed to be modified since I want a secured network, but if I'm not wrong, it's copied directly from WSNDemo. Anyway, I'll comment that out also for test.

I might do another test, with this firmware on the XplainedPro,it has at least a serial console.

[ataradov]

Does it break the mega?

Nah, it won't do anything bad.

I might do another test, with this firmware on the XplainedPro,it has at least a serial console.

And an actual real debugger. So debugging may be in order.

[danergo]

And an actual real debugger.

Exactly.
I don't want to go much deep in theoretical discussion now, but if it will work on the Xplained, what would be the ideal next step on my board?
Resolder the mega? Everything else is working fine (INTs of both level and edge types, PWM, I2C, Clocks at least the 16MHz one).

[ataradov]

what would be the ideal next step on my board?

Double check the hardware. I have never seen something working on Xpro and not working on the other board unless there are hardware issues.

I would do passive debugging first before any hardware modifications. Setup a WDT and dump the call stack to see where your code is stuck. You can parse the stack manually, or more or less automatically as described in my article here http://www.embedded.com/design/debug-and-optimization/4431982/How-to-debug-elusive-software-code-problems-without-a-debugger

[danergo]

Thank you!

I've done only one test, and was succeed. Uploading my firmware onto Xplained worked, joined fine.
So I tried to do some more soldering around the 32kHz XTAL, which was the only possible reason, and now it seems fine on my board as well.

Indeed it was a HW issue, and I learned the lessons.
Also, that's a really nice tutorial, worth reading.

[ataradov]

So I tried to do some more soldering around the 32kHz XTAL, which was the only possible reason, and now it seems fine on my board as well.

In that case debugging would have been very easy, when crystal is not working, it always gets stuck on reading a bit from ASSR. This is pretty obvious under the debugger.

Also, that's a really nice tutorial, worth reading.

This is actually an extension of a system used during development of BitCloud. There is a jump to NULL handler that checks if it was due to external reset. And if it was not, it dumps the stack over UART in a loop and blinks LEDs. Keep network running overnight and in the morning, you connect to blinking nodes and get UART dump and you instantly know what function caused jump to NULL (most common reason is uninitialized callback handler).

[danergo]

Hello!

Sometimes I start getting NWK_NOT_PERMITTED_STATUS for the joining request on the ED, and the only solution I found for this is to reset the Coordinator. (The ED does not need to be resetted.)

Do you have any idea, what could happen in this case? I've searched through the forums, but didn't find anything useful yet.

Thanks!

[ataradov]

I would need to see sniffer logs.