About Device Information Area (DIA)

[Yasin]

Hi friends. I came across some information while reviewing the advanced PIC18 datasheet. Since my English was not good, I could not be sure if I understood it correctly. "DEVICE INFORMATION AREA" DIA section. It is said that the data here is unique for each MCU and cannot be changed. If so, I saw it as a useful feature.
For example; We did a project for a client. He will do the physical production himself. In accordance with the agreement, we delivered the HEX file. As per the agreement, we will receive payment for each mcu upload.
Question: Since the data in the DIA region is unique, can we use this for activation? E.g; Is it used to activate the software by entering a key (using a robust algorithm) via USB port or serial port or via the keypad?
Question; Can we have our designs produced as programmed without hesitation?

[okmn]

It caught my attention too (I never knew about this before your message).

but as far as I understand this region (dia store) is just a read only section.
I gathered all the related topics in one place.
I guess some of what you said/your ideas can be done if you give the pic mcu itself.

[Yasin]

Yes. That's exactly what I'm talking about. The MCU I reviewed is PIC18F47K27, similar to the one to be used on the Positron Board.

http://ww1.microchip.com/downloads/en/DeviceDoc/Microchip%208bit%20mcu%20%20PIC18%20L_F26_27_45_46_47_55_56_57K42%20low-power%20high-performance%20mcu%20with%20xlp%20tech%2040001919B.pdf

[JeniferHong]

One thing that's helped me with odd compiler issues is stripping the project down to the smallest example that still reproduces the problem. It makes it much easier to tell whether it's the code, an include file, or a compiler setting causing it. Also worth double-checking that the compiler version and device definition are the same if you're comparing with another setup. Hopefully that narrows it down.

[Stephen Moss]

One thing that's helped me with odd compiler issues is stripping the project down to the smallest example that still reproduces the problem. It makes it much easier to tell whether it's the code, an include file, or a compiler setting causing it. Also worth double-checking that the compiler version and device definition are the same if you're comparing with another setup. Hopefully that narrows it down.

Not really sure how that applies to the subject matter which appears to be concerning using the Device ID as some form of activation code.

For example; We did a project for a client. He will do the physical production himself. In accordance with the agreement, we delivered the HEX file. As per the agreement, we will receive payment for each firmware upload.

I am not in that type of business so perhaps that type of contract is common practice, but it does not seem to be a very good way of doing things to me as you are essentially relying on the honesty of the client to accurately report sales/programmed units and pay the applicable amount.
If it was to keep the initial cost to the client down, perhaps asking for a 60% initial payment and then 10% per year for the next 4 years would have been a better option than what appears to be some form of licencing agreement where you are effectively paid an amount per unit programmed/sold.

Question: Since the data in the DIA region is unique, can we use this for activation? E.g; Is it used to activate the software by entering a key (using a robust algorithm) via USB port or serial port or via the keypad?

To my knowledge that would depend in the device in question, some only have ID's that indicate the device name and revision so it would be less useful for those as thousands of devices will have the same device ID. However, where a devices DIA region contain a Microchip Unique Identify (MUI), the MUI should be unique to each device although I cannot see how it could be easily implemented to activate the device/product.

One way may be to enter a checksum based on the devices unique ID for the firmware to check against a checksum it creates internally but, how would you obtain that MUI value externally in order to externally generate the applicable checksum value? Would the programming software extract it? If the device is networked somehow would it send it to you?