CC2652R: Wrong address conflict

Hi Antonio,

Can you clarify which of Ryan's suggestions you have tried ?

1. "force route discovery using NLME_RouteDiscoveryRequest from your application upon detection of a failed route or message delivery"

2. "Many-to-One routing"

What are the contents of the Route Request ? (Can you share the sniffer log ?)

Regards,
Toby

Hi,
thank you for the reply.

I've applied the 2. "Many-to-One routing" and the known issues and fixes.

Here you can analyze a portion of the trace. Let me know if you need other messages.

addr_conflict.zip

Thanks,
Antonio

Thanks for confirming that you use MTO routing.

How easily reproducible is this issue ?

Looking through the logs, I'm not sure why 0xA5A9 is reporting directly to 0x0000 (pkt 46) since it does not have a route to 0x0000 (its Link Status in pkt 1 has entry for 0x0000 with outgoing cost 0).

Besides this, it seems like the Network Status (pkt 47) is due to 0x0000 receiving a packet from a device to which it does not have a route.
If MTO is used, I believe 0x0000 should actually send an MTO route request instead (zgConcentratorEnable == true).

Can you share which changes you've made to enable MTO ?

Hi Toby,
it is difficult to say how easily is reproducible since there is no direct effect on the communication. I've seen this message (address conflict) 2-3 times in 10 days, but I have not analyzed all 10 days traces.

We use the Code Composer Studio 10.1.1 and in attachment you can retrieve the git commit changes I've made.

MTO_routing.zip

Thanks,
Antonio

Ok, thanks for sharing, these match up with what is specified in the swra650b.pdf . I don't see any issues with these values.

Can you try enabling with source route cache (CONCENTRATOR_ROUTE_CACHE == true)? This would make sure that concentrator makes use of source routing table.

Can you share the larger capture ?
This could help give clues on what else could be going on in the network.
For example, was this address (00:01:E8:39:20:01:3A:00) sent over the network by that device at any other point in time (even though it is not actually the IEEE address of any device) ?

Hi Toby,
thanks for the confimation.

In attachment you can retrieve the full trace (autosave every hour). I've seen the same behavior 2 times today.

address_conflict_full.zip

Thanks a lot for the support.

Antonio

I see two PANID in the logs:

• 0xA9DC    (which contains the "No Route Available" command)
  • This is the one with device 0xA5A9 and "Address Conflict"
  • This PANID does not have any MTO Route Req -- I had been assuming that MTO routing with concentrator was enabled for that network ?
    • Did you make sure to erase all flash before flashing the new MTO-enabled image ?
      If not, the zgConcentratorEnable would be loaded from NV instead.

• 0xD06A
  • This network has MTO enabled (I see periodic "ManyToOne" route requests).
  • Addresses seem stable -- no "Address Conflict"

I'd recommend the following:

Apply MTO patch to a network which is typical of your application (e.g. number of nodes, types of applications).
Consider enabling Route Cache (i.e CONCENTRATOR_ROUTE_CACHE = true).

Hi Toby,
yes, on this channel we have 2 installations. The 0xD06A PANID has a CC2530 as coordinator; we are testing the CC2652 coordinator with the 0xA9DC network to increase the number of devices.

I've flashed the CC2652 with the Code Composer Debug button: it's not enough?

And what are the pros/contros of enabling the CONCENTRATOR_ROUTE_CACHE flag?

Thanks,
Antonio

Antonio Portaluri said:

I've flashed the CC2652 with the Code Composer Debug button: it's not enough?

By default, CCS will flash only the executable image (the NV area is retained).
This is useful for cases where you need to update the application logic, but want to retain the network information (e.g. to rejoin the network after flashing).

There are a few ways you can erase all flash on the device, one of them is shown in Task 0 of this SLA.

You can also change the default behavior of the Debug button, so that it first erases all flash on the device before loading the image:
right-click the project --> Debug As --> Debug Configurations --> Target --> Flash Settings --> All Unprotected Sectors

Pro of source route cache is that it lowers overall traffic. This is because the devices know that concentrator is caching the source route to each device.

Con of source route cache is that it uses more RAM, since it is saving source routes to each device.

(see )