Forum : ST7/STM8
Post Information | Post |
---|---|
June 8, 2009 - 10:41am
|
Hello everyone, I have problem with disabling SWIM interface on STM8S207K6 pin PD.1. In reference manual (RM0016.pdf, page 53) there is written: SWIM modes After a power-on reset, the SWIM is reset and enters OFF mode. 1. OFF: Default state after power-on reset. The SWIM pin cannot be used by the 2. I/O: This state is entered by software writing to the SWD bit in the Global configuration 3. SWIM: This state is entered when a specific sequence is performed on the SWIM pin. At beggining of my application I try to disable SWIM this way: Then I download my application to MCU by RLINK and STVD. 1) First surprise is, that debugging is working even if I have disabled the SWIM in my application. 2) If I disconnect my board with MCU from RLINK - so there can't be any influence from RLink to MCU and after reset, 3) Same behavior is in Release mode or if I use STVP (ST Visual Programmer) to program the MCU. In another manual UM0470.pdf (STM8 SWIM communication protocol and debug module, page 6) there is written: Operating modes 1. OFF: In this mode the SWIM pin must not be used as an I/O by the application. It is But I can't find in any manual or datasheet (and even in the internet) any description where the MCR register or IOM bit is!!! And another strange behavior: One time I have success with disabling SWIM (LED connected to PD1 was toggling) but I don't know how has this happen... Please, do you have same troubles with using PD1 as standard GPIO and SWIM together? Thanks for any replies Milan. |
Hi
Please find below some answers according from ST Microelectronics.
1. MCR[IOM]=CFG_GCR[SWD]. This is an issue with the documentation (old register naming).
2. This bit is for security purpose in "standalone" mode (no tool connected). The documentation
is not clear enough (to me): "The SWIM pin cannot be used by the application as an I/O" should
be understood "The SWIM pin must not be used by the application as an I/O". Because otherwise
the application may inadvertently activate the SWIM. So when the application expects to use this
pin as an I/O, the SWIM must be disabled.
But as the standard init sequence of a Swim tool is done under reset of the CPU, it's not possible
for an application to absolutely forbid Swim entry from externally (of course !).
Moreover, once the SWIM has been activated (by an external tool), "fortunately" the application
can no more de-activate the Swim pin (otherwise a bug in the application may crash the debugger !)
3. Once activated, the SWIM can be disabled:
- either by a successful "stop debug" command from STVD (please update to version 4.1.2 available
now; 4.1.1 was already OK but some previous versions may have some bugs on this point).
- or by a power on reset ("simple" reset is not enough)
4. Be careful that wrong "stop debug" (for instance unplugging the SWIM cable during application run,
started from the debugger) may result in flash corruption (software breakpoints remaining). In this
case the application will fail even after power on reset, in the case she reaches a software break.
Regards,
Matloub
Thanks for reply.
My program has at the beginning (first line in main() )this line: CFG->GCR |= 0x01; // disable SWIM interface
So I understand that It is not possible to disable SWIM while it has been once activated (by certain signal sequence on pin PD1) during application startup after reset -> this is why the debugger is working when I try to disable SWIM at the beginning of my application.
But I expect, after downloading program to MCU and disconnecting board from RLink and after power-on reset, that SWIM would be disabled. But in my case is not. The pin is kept dead (like in debug mode when SWIM is activated).
I'm sure, the SWIM disabling is possible and either in the datasheet or manual is this written. Moreover, once I had succeed - the PD1 pin was freed but I have no idea how it happen :o/
Does anyone have experiences with this issue?
What is proper procedure to disable SWIM and use PD1 as standard GPIO?
Many thanks...
Milan.
The problem seems to be solved. There was most likely hardware bug on the PCB.