On Mon, Jul 27, 2020 at 11:21:00AM +0200, [email protected] wrote: > Rejecting non-ST MCU probably has also a deeper impact. The need to > read the MCUID! This has often problems when in sleep or even when in > reset. Even with stprog, STLINKV3 often does to to a board the > STLINK-V2(1) had no probblem.
I'm surprised I get no constructive feedback on this ticket. Now that it's trivial to try a firmware with patched-out IDCODE check why isn't anybody trying that? Probably in fact I'm wrong to bother at all and nobody just gives a damn and it's a non-issue? > > First, a word of warning: V3J6M2 firmware will enable permanent protection > > level 2, so you won't be able to debug ST-Link itself over SWD on this chip > > ever (reflashing via the bootloader would still be possible though). > > V3J2-V3J5 > > are known to not enable any additional protection. > > How to patch the firmware: > > There is also a patched bootloader available that does not protect the > F723. >From reading that github ticket thread I got an impression that the protection is performed by the main firmware. And it's probably checking some byte that's flashed with the bootloader, right, but nobody has tested it yet, and also nothing prevents ST from ignoring that byte in the new not-yet-released versions of the firmware, so I wouldn't count on it. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:[email protected] _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
