Possibility to block SWD access on reset and enable it via software.

[asoman]

Hello,

I am currently using STM32L010 MCU in my application where we have UART and SWD lines exposed to be accessed only by service personnel (under a cover but still accessible without dismantling the device). Since we want to have a possibility to perform software update in the field, we want those SWD pins physically accessible.

We currently map those pins to GPIO in the start-up so that they cannot be used to debug the program while application is running, but still can be used to reprogram the chip by applying reset via MCU_RESET pin.

We want to block this access and enable this access only if certain command is received via UART (i.e. only when SWD is actively enabled via a command) and not even upon reset to avoid unauthorized reprogramming of our product.

Alternatively, if there's a way to block reset via MCU_RESET (unless it is activated by a command), that would also do the trick.

Is it possible to block SWD access even upon chip reset and activate it via software whenever wanted? Or is it possible to map MCU_RESET to another function until it is remapped to MCU_RESET via software?

Thanks in advance.

Ash

[Uwe Bonnes]

RDP2 inhibits SWD access unconditional and irrevwesible. RDP1 restricts access and removing is again allows SWD access, at the cost of a full erase. Is that an option?

[asoman]

If I am not mistaken, RDP1 would restrict read access, but upon reset, one can still use SWD to reprogram the chip (with full erase). In this case an unauthorized access could still flash their own firmware and render the product useless.

This could be an option, and we have RDP1 in place already, but I was looking to block the SWD access at all unless one wants it activated via SW. Is that possible in any way?

[Uwe Bonnes]

Only RDP2 blocks SWD access, but irreversible. Reflash is possilble with a bootloder, see recent STLINKV3

[asoman]

Okay, thanks!

I think then it is better to devise some non-software solution to this! Thanks again 🙂

[James Murray]

Do your field personnel need to debug the device or just load firmware?

If they are only loading firmware, then using RDP2 and a bootloader to upload new firmware over UART is probably the way to go. This also means they don't need to carry debug hardware.

With a locked down chip your bootloader could be set to only accept signed firmwares to reduce the chance of rogue code being installed.

James

[asoman]

The field personnel only need to load firmware.

Thanks James for your reply. Yes, updating it over the UART is a possibility which could be safeguarded with RDP2.

Is it possible over build-in bootloader of the STM32 or would I need to redesign the software to use custom bootloader and write an update protocol in the bootloader to update the firmware via UART?

[Uwe Bonnes]

I think, system bootloader is also impossible in RDP2. You have to write yourself...

[asoman]

Hmmm.. Then maybe I need to re-evaluate efforts and risks in this case 🙂

[James Murray]

I wrote my own bootloader. I haven't yet tried out RDP2 though!

James