RDM Firmware Uploads

[sblair]

PID's in the 0-0x7FFF range are reserved for PID's that are publicly defined in one of the standards which is a very long process. The range from 0x8000 up as you correctly identified is for manufacturer-specific implementations.

Controllers SHOULD query the device for what PID's are supported in the manufacturer-specific range first, but as you identified another controller could send this PID still which would erase your flash.

There are a few methods to protect against this. First off, the block transfer PID's can NACK unless they have received the PREPARE PID first that I had mentioned.

That just leaves you to protect the PREPARE PID which might be what triggers the Flash erase in your system. The first way to protect this is for the target device to ignore this PID unless the Source Address is your own Manufacturer ID. The other way is to include like a pre-defined 16 character string in the Parameter Data for that PID that acts as a key to unlock it. If the string does not exactly match what you are expecting then the PID gets NACK'd.

That is basically how most of us implement it ourselves to protect against accidental triggering.