[BitCloud] IAR Compilier vs GCC Compiler

[rfleming]

Hi team,

I have been using the BitCloud stack for a while now and have an IAR avr compiler license, I havn't done much with IAR and BitCloud yet since it will take some time to get it going with my custom app. I had a bit of a play with the IAR compilier, but fml the IDE makes me want to /wrist. Between this and a lot of the standard functions that I have grown rather fond of created from the Atmel team on top of the GCC compiler are not implemented on IAR.

Nonetheless, I have found after talking to some Atmel guys that they test a fair bit of their stuff with the IAR compiler instead of GCC, leaving (imo) GCC a little more buggy in BitCloud.

I found that a lot of functions don't actually work correctly with the GCC compiler that the Atmel team believe do with their ATSAM/IAR combination in comparison to my AVR/GCC combination.

Has anyone had any experience with the following using IAR or GCC:

• Unpair a paired device. Then pair it once more without a reboot of the coordinator. Note the same nodeID as previously. This stack doesn't appear to like this. No commands will work...
• Picking up a Leave Broadcasting from a node in the network
• I can get NWK_GetShortByExtAddress working, but: NWK_GetExtByShortAddress and NWK_RemoveFromAddressMap doesn't

I know alex is out there but I am not sure if anyone else has had that much experience with this!

Ryan.

[dannyf]

but fml the IDE makes me want to /wrist. Between this and a lot of the standard functions that I have grown rather fond of created from the Atmel team on top of the GCC compiler are not implemented on IAR.

the IAR IDE is my favorite for its highly utilitarian look-and-feel.

Porting between the two compilers is quite easy. My code can compile under both, the differences can be resolved via a set of macros + conditional compilation.

[ataradov]

It is true that all tests are run on IAR.

Nonetheless, I have found after talking to some Atmel guys that they test a fair bit of their stuff with the IAR compiler instead of GCC, leaving (imo) GCC a little more buggy in BitCloud.

Do you have any examples? The only thing that is annoying about GCC examples is lack of native projects for Atmel Studio.

I found that a lot of functions don't actually work correctly with the GCC compiler that the Atmel team believe do with their ATSAM/IAR combination in comparison to my AVR/GCC combination.

A lot? One or two, for instance?

Unpair a paired device. Then pair it once more without a reboot of the coordinator. Note the same nodeID as previously. This stack doesn't appear to like this.

You can request device to leave, but you can't force stack to give it the same address on rejoin.

]No commands will work...

What have you tried? You are describing a very complicated process, there is not a single command to do that.

Picking up a Leave Broadcasting from a node in the network

  You can only do this for children.

I can get NWK_GetShortByExtAddress working, but: NWK_GetExtByShortAddress and NWK_RemoveFromAddressMap doesn't

What exactly does not work? Keep in mind that those functions operate on local tables, so if entry is not there, it is not going to be found. There are different (ZDO) commands to perform such conversions over the air.

[rfleming]

but fml the IDE makes me want to /wrist. Between this and a lot of the standard functions that I have grown rather fond of created from the Atmel team on top of the GCC compiler are not implemented on IAR.

the IAR IDE is my favorite for its highly utilitarian look-and-feel.

Porting between the two compilers is quite easy. My code can compile under both, the differences can be resolved via a set of macros + conditional compilation.

I have started making various macro's or shared functions with this very intention though I just haven't had time to finish it off. I am surprised that you do like the mid-2000s feel for an IDE, I think it lacks a lot of the functionality that exists in the modern ones (comparing to Visual Studio namely). Just simple things like the lack of highlighting on macros, creating new c files is like a 3 step process, its been a while there were a few other things as well...didn't mean to rant...

Do you have any examples? The only thing that is annoying about GCC examples is lack of native projects for Atmel Studio.

The dev boards I have on hand are the rcb256rfr2-xpro (http://www.atmel.com/tools/ATRCB256RFR2-XPRO.aspx). The atmel rep that was assisting me in tech support told me many times this board should be fine to use with the latest BitCloud stack. He was right, it did work, but a few things didn't work correctly by default. The one that comes to mind is reading the MAC using BSP_ReadUid, it wouldn't return ack with the correct UID, but with the IAR compilier to my supirse it did.
I also required to the use the supporting bootloader for the stack. (Despite being a seperate project) this did not work with the gcc compilier at all. Even once I compilied it with the IAR compilier after purchasing it the main app (BitCloud) had to be compilied with IAR to work with it. Nonetheless, I spoke to Atmel and they did a quick release of a couple of the source files for the compilier so I could compile it with IAR and it would work with the main BitCloud app compiled in GCC. I was happy with the outcome though, it worked

You can request device to leave, but you can't force stack to give it the same address on rejoin.

In my current testing environment, we have paired and unpaired our routers many times. This is required for testing our web interface, app and a few other components in between. In this situation we allow a node to join by association. It joins, the coordinator by default randomly generates a node id and gives it to the node. In an "Association Response" frame. When I request the node from my coordinator, the device leaves successfully. Then the router goes into a network search mode. I Permit joining on my coordinator searching for a new device to join, the router joins. The Coordinator sends an "Association Response" frame with the same node ID as it previously did. I am fine with this, but if I send any requests or commands to the router, given the same old address, the device replies, but nothing is processed by the coordinator. Thus I keep receveing errors.

Picking up a Leave Broadcasting from a node in the network

  You can only do this for children.

So if a router was to leave on its own, restore to factory settings situation, it broadcasts a "Leave" frame to the network. Is this processed in anyway? If I hold a list of node ID's on my coordinator, is there any way to know that this node has left?

I can get NWK_GetShortByExtAddress working, but: NWK_GetExtByShortAddress and NWK_RemoveFromAddressMap doesn't

What exactly does not work? Keep in mind that those functions operate on local tables, so if entry is not there, it is not going to be found. There are different (ZDO) commands to perform such conversions over the air.

In my testing situation I parsed an Extended address to NWK_GetShortByExtAddress and got the short address. The next line I parsed the short address I got with that cmd to NWK_GetExtByShortAddress and it responded back with 0ULL. I then parsed the original extended address to NWK_RemoveFromAddressMap and tried to read the short address from the address table again with the extended address and it worked fine. I can only think from this that the entry in the table wasn't removed

[ataradov]

The one that comes to mind is reading the MAC using BSP_ReadUid, it wouldn't return ack with the correct UID, but with the IAR compilier to my supirse it did.

This is very surprising, but in general board-specific stuff support is poor.
I personally disregard anything in BSP and roll my own.

I also required to the use the supporting bootloader for the stack. (Despite being a seperate project) this did not work with the gcc compilier at all.

That's because default bootloader is a bloated nightmare. I strongly advice against using it in real projects.

And BL and application must be compiled with the same compiler because application makes calls into the bootloader and calling conventions are different between GCC and IAR.

but nothing is processed by the coordinator. Thus I keep receveing errors.

If this is a secure network, then it is highly likely that security counters were reset on rejoin. This should not happen in real life.

I would need to see some sniffer logs and a step-by-step description of a specific scenario to give advice on how to resolve this situation.

So if a router was to leave on its own, restore to factory settings situation, it broadcasts a "Leave" frame to the network. Is this processed in anyway?

Yes, router is removed from the list of neighbors or children on the local device.

If I hold a list of node ID's on my coordinator, is there any way to know that this node has left?

There is no reliable way. Node may just physically die and never send any leave request. Periodic polling of all nodes is one way of solving this problem. There are others as well, but they all involve indirect observation, there is no direct way of detecting disappearing nodes.

In my testing situation I parsed an Extended address to NWK_GetShortByExtAddress and got the short address. The next line I parsed the short address I got with that cmd to NWK_GetExtByShortAddress and it responded back with 0ULL. I then parsed the original extended address to NWK_RemoveFromAddressMap and tried to read the short address from the address table again with the extended address and it worked fine. I can only think from this that the entry in the table wasn't removed

NWK_GetShortByExtAddress() and NWK_GetExtByShortAddress() are exact mirrors of each other, they look in the same tables. I would need to have a reproducible example to tell what may be wrong.

[dannyf]

I am surprised that you do like the mid-2000s feel for an IDE,

Beauty is in the eyes of its beholder. What kind of editors suits you is highly subjective. What worked for me may not work for you, and vice versa.

I like IAR's editor primarily because of its lack of such functionalities - it is utilitarian, and good for entering code. For that, I don't need much more than the ability to trace through my project.

If I need context-sensitive highlighting and code analysis, I go to ST, or SI or UE, or NPP. But for the most part, ST is my go-to editor for code analysis. Probably better than any editor you can find from a programmer's perspective.

[rfleming]

That's because default bootloader is a bloated nightmare. I strongly advice against using it in real projects.

And BL and application must be compiled with the same compiler because application makes calls into the bootloader and calling conventions are different between GCC and IAR.

I do have the bootloader working at this stage and I reworked the higher level stuff to my coding style so I could use it as a SPI slave. Do you have any suggestions on how I could do this better than to use their "bloated" solution? Or would that take a fair bit of reworking, redoing trampoline functions etc?

If this is a secure network, then it is highly likely that security counters were reset on rejoin. This should not happen in real life.

I would need to see some sniffer logs and a step-by-step description of a specific scenario to give advice on how to resolve this situation.

Please see sniffer logs attached. Rename the "Wireshark.txt" to "Wireshark.cap" .cap is an illegal forum attachment I hope the .cap file works with your wireshark, not 100% on how I should parse on these logs. Start looking from item 8050.

In this situation I used the following upair function:

Code: [Select]

ZDO_ZdpReq_t * zdo = &Global.CmdBuffers[freeIndex].zdo;

ZDO_MgmtLeaveReq_t * mgmt = &zdo->req.reqPayload.mgmtLeaveReq;
mgmt->removeChildren = 0;
mgmt->rejoin = 0;
mgmt->deviceAddr = 0ULL;
zdo->dstAddress.shortAddress = shrtAddr;
zdo->ZDO_ZdpResp = Unpair_Callback;
zdo->reqCluster  = MGMT_LEAVE_CLID;
zdo->dstAddrMode = APS_SHORT_ADDRESS;

ZDO_ZdpReq(zdo);I am using short address since it appeared to still allow devices to unpair. I have also tried ext address assigned to "devAddr" and "dstAddress.extAddress" or just one of them. They all appeared to have the same result.

NWK_GetShortByExtAddress() and NWK_GetExtByShortAddress() are exact mirrors of each other, they look in the same tables. I would need to have a reproducible example to tell what may be wrong.

REPHRASE: Turns out I can get the short and ext functions to work, but I can't get the remove device from table working. In the following example Short 1, short 2 and ext all return the address associated with my node. But I was hoping that the short 2 would return 0x0000 or something similiar to show that it was no longer in the table.

Code: [Select]

//globally defined for easier debugging
const ExtAddr_t GlobExt = 0x00606efffea6ccd4;
const ExtAddr_t * GlobExtPtr;
//inside func
volatile ShortAddr_t * shortAddr = (ShortAddr_t *)NWK_GetShortByExtAddress(&GlobExt);
itoa(*shortAddr, Global.TmpBuffer, 16);
sendDebugMessages("Short", Global.TmpBuffer);

GlobExtPtr = (ExtAddr_t *)NWK_GetExtByShortAddress(*shortAddr);

char tmp2[9];

uint8_t * num = (uint8_t *)(GlobExtPtr);
num += 7;   //start from the last byte. lowest in the 64bit number

//method 1. Includes padded 0's
//Output Extended ID/MAC
Global.TmpBuffer[0] = 0;
for (uint8_t i = 0; i < 8; i++)
{
if (*num < 0x10)
{
strcat(Global.TmpBuffer,"0");
}

itoa(*num--, tmp2, 16);
strcat(Global.TmpBuffer, tmp2);
}
sendDebugMessages("Ext", Global.TmpBuffer);

NWK_RemoveFromAddressMap(&GlobExt);

volatile ShortAddr_t * shortAddr2 = (ShortAddr_t *)NWK_GetShortByExtAddress(&GlobExt);
itoa(*shortAddr2, Global.TmpBuffer, 16);
sendDebugMessages("Short", Global.TmpBuffer);

[ataradov]

Do you have any suggestions on how I could do this better than to use their "bloated" solution?

Roll your own. But if it works, for you, then just leave it as is. I just want to warn you that if you want to use OTA upgrade, then default implementation is very flaky.

Start looking from item 8050.

So what seems to be the problem? Device leaves and immediately rejoins. Nothing wrong with that.

REPHRASE: Turns out I can get the short and ext functions to work, but I can't get the remove device from table working. In the following example Short 1, short 2 and ext all return the address associated with my node. But I was hoping that the short 2 would return 0x0000 or something similiar to show that it was no longer in the table.

NWK_GetShortByExtAddress() also looks at neighbor table. Stack will remove things automatically as long as this mapping is not true. In this instance it is still true. You removing it from the local table will do absolutely nothing, since this record will be added again the first time stack sees extended and short address of the device in the same message. And this will basically happen for very encrypted message.

[rfleming]

Roll your own. But if it works, for you, then just leave it as is. I just want to warn you that if you want to use OTA upgrade, then default implementation is very flaky.

No stress. I am not going to use ZigBee OTA's for updating remote devices, only for updating my coordinator over SPI with an adjacent micro.

So what seems to be the problem? Device leaves and immediately rejoins. Nothing wrong with that.

The process is as follows:

• Permit Join
• Device joins by association
• Permit duration broadcasts 0
• No more devices can join network
• Send various switching commands to device
• request device to leave
• device leaves
• permit join
• device joins by association with same short address as it previously had
• send switching command to device
• device receives commands correctly, though no responses are handled correctly from the device. Every response is an error of some kind
• try to kick device out
• devices leaves network, but stack doesn't know if it actually has or not. Response returns an error

This is where my issue arises, the coordinator cannot handle any responses my the remote devices if it joins by association once again. I have a work around that restarts the coordinator every time a device gets kicked out, but I don't really like this implementation.

NWK_GetShortByExtAddress() also looks at neighbor table. Stack will remove things automatically as long as this mapping is not true. In this instance it is still true. You removing it from the local table will do absolutely nothing, since this record will be added again the first time stack sees extended and short address of the device in the same message. And this will basically happen for very encrypted message.

You might be correct in saying that it will be readded regardless. But that still takes away from the idea that the function does not actually do anything. If device was to go off line permanently and no more messages were sent by it, I would assume that this function should work as intended, but the address table still responds back with the short address despite being "removed".

[ataradov]

This is where my issue arises, the coordinator cannot handle any responses my the remote devices if it joins by association once again. I have a work around that restarts the coordinator every time a device gets kicked out, but I don't really like this implementation.

This happens because device is misbehaving and resetting its counters on leave. This is a moderate security issue, but ZigBee is full of holes (standard and implementation) like that, so I guess no big deal.

Coordinator ignores those messages because it is a standard to ignore them. You will need to remove neighbor table entry corresponding to that device. It contains incoming security counters, so coordinator will forget the latest value and will accept frames with new counters.

function does not actually do anything.

Function does exactly what it should do.

But NWK_GetExtByShortAddress() and the reverse one look into other places as well, not only address table.

One of the places they look is already mentioned neighbor table.

[rfleming]

This happens because device is misbehaving and resetting its counters on leave. This is a moderate security issue, but ZigBee is full of holes (standard and implementation) like that, so I guess no big deal.

Coordinator ignores those messages because it is a standard to ignore them. You will need to remove neighbor table entry corresponding to that device. It contains incoming security counters, so coordinator will forget the latest value and will accept frames with new counters.

Well, there ya go! You sir, shall be added to my Christmas card list!
It still adds with the same old short address, but I don't have any errors anymore, so no worries

The following worked well:

Code: [Select]

NwkNeighbor_t * neighbor = NWK_FindNeighborByShortAddr(shortAddr);
NWK_RemoveNeighbor(neighbor, true);

But NWK_GetExtByShortAddress() and the reverse one look into other places as well, not only address table.

That explains that issue then. I don't need to try and use this anymore because the above has solved my issue