STM32 hw_get_unique_id() bug about sub-iot-stack HOT 4 CLOSED

OK, good to hear it is not really a problem.

I completely agree that we should use semver based releases for the stack. When talking about the network stack I think we can list the following as being part of the public (versioned) "API" to be guarded by semver:

• D7A frame structure (over the air) + D7A protocol (behavior)
• ALP protocol
• d7ap_stack.h and alp_layer.h
• serial modem interface
• D7A system files, OSS-7 specific files and their structure
• embedded LoRaWAN stack updates (MAC version, regional params, ...)

For each of these parts a change can be a patch or minor change (which are both backwards compatible) or a major change. For instance, using a RFU bit in D7A frame structure for a new feature, or adding an ALP operation type or extending a D7A system file with an extra field can all be considered minor changes since they are backwards compatible. To come back to the specific issue with the way the UID is generated: I don't think this is a breaking change; everything will keep on working as discussed above, the file structure remains the same, only the way the UID generation on STM32L is implemented is changed. So IMO this is only a patch release.

from sub-iot-stack.

Thanks for reporting! You are totally right, there is a bug there which results in the UID being wrong... Based on my testing it seems that the UID we generate currently is increased with 0x1100000000000000 compared to the correct one due to this, but it is indeed undefined so I'm not sure if this is always the case.

Fixing it is not difficult, the question is if this breaks anything for users. On our side we are not using the STM32 UID but assign an UID during production from a range we bought at IEEE, which means that we would not be impacted by this. What would happen on your side if this bug is fixed? The UID is stored in the FS and only overwritten (by the output of hw_get_unique_id()) when the UID is not set yet in the file. This means that if you would update devices in the field using a fixed implementation of hw_get_unique_id() they would still use the same UID.

As a side note: Even if this is fixed I'm not entirely sure that uniqueness can be guaranteed, since we are still reducing the 96 bits to 64 bits.

from sub-iot-stack.

We do use this implementation of the UID in production. But as you pointed out, since the UID is cached in the eeprom it shouldn't be a problem to fix it. New devices will just use a different format.

I think the uniqueness will be ok since we're using the uniqueIDbits at +0x14.

It is however a breaking change, so maybe it would be a good idea to introduce tags/releases and SemVer version numbers for this stack?

from sub-iot-stack.

btw the issue should now be fixed in 2666efc, so I'm closing this one. If you still have a remark feel free to re-open.

from sub-iot-stack.