Hello, May it be noted that your two 'objectives' appear somewhat in conflict? lock the firmware from reading not lock the firmware for programming and/or debug Do not those 'conflicting objectives lead to these questions? (which only you are able to answer) How will your MCU (know) that the programming/debug attempt is proper - and 'Not' that of an unauthorized source? As your design is 'Not' new - has it not (already) been 'in the field' thus, 'well exposed?' (i.e. 'Shutting the barn door ... (after) the animals have escaped!') It is not 'unusual' for MCU users to, 'Lock themselves Out' during such, 'Security Development!' As your MCU has (long) been, 'Out of Production' - what then? Might it prove wiser that you, 'Purchase & Experiment w/one of the vendor's newer MCUs (which ARE available) & only after, 'Meeting your security objectives' move that effort to your (older/irreplaceable) devices? You should know that, 'Even when defeating 'JTAG/SWD' access' - a properly 'skilled/motivated/equipped' group - can quickly & easily, 'Have your code!' Reality is not always comforting - yet, 'Now you know.'
↧