STM8L001J3 SWIM startup delay needed if not initializing IO function on that pin?

[JVolk.2]

I am working with an STM8L001J3 and the application needs to go from power up to triggering a GPIO Port B Pin 3 as soon as possible. As this will be the only GPIO used, does anything further need to be done to ensure SWIM function remains accessible and not brick the MCU? This application is not conducive to a 5s startup delay as recommended in the application note, however, I dont need that pin for anything else.

[Peter BENSCH]

You are probably referring to RM0013, section 3.3:

• If the SWIM pin should be used with the I/O pin functionality, it is recommended to add a ~5 seconds delay in the firmware before changing the functionality on the pin with SWIM functions. This action allows the user to set the device into SWIM mode after the device power on and to be able to reprogram the device. If the pin with SWIM functionality is set to I/O mode immediately after the device reset, the device is unable to connect through the SWIM interface and it will be locked forever (if the NRST pin is not available on the package). This initial delay can be removed in the final (locked) code.

The 5 seconds are proposed with a very large safety margin so that the SWIM can be guaranteed to be accessed. Of course, this time can be shortened, see UM0470, section 3.2.

Workaround: if you have a GPIO spare pin, you could use it to trigger a delay extension if you activate it before the reset (some kind of SWIM enable when activated)?

Regards

/Peter

[JVolk.2]

UM0470 seemingly added some clarity.

So as long as I never put something in the code that sets the SWIM disable bit (i.e. initializing an IO), it should always be in "OFF" state, waiting for SWIM sequence. Would it perhaps also be wise to put a command just prior to entering the while loop to ensure  (CFG_GCR) Bit 0 is set to 0 and preventing a programing lock out.

[Peter BENSCH]

You can explicitly reset the SWD bit in CFG_GCR if you want. However, this is redundant because the reset value of CFG_GCR is already 0x00.

Regards

/Peter

[JVolk.2]

Thanks for the quick support. Yes, redundant for sure, but the idea is to prevent myself or future code maintainer from fat ********* a GPIO register and locking out the MCU.

[Peter BENSCH]

What should prevent the maintainer from setting the SWD bit in CFG_GCR to 1 later - if he/she has access to your source code? :smiling_face_with_smiling_eyes: