Skip to main content
T
Ted Jackson
Visitor II
July 5, 2020
Solved

Is there a way for an STM8 MCU to determine programmatically if the SWIM interface is currently running?

  • July 5, 2020
  • 3 replies
  • 947 views

Hi. Is there a way for an STM8 MCU to determine programmatically if the SWIM interface / ICP / STVD debugger are being used? I've tried checking the SWD bit in CFG->GCR and SWIM->CSR. But neither byte seems to change from SWIM debugging to a power on restart. The reason I ask is because an area of data EEPROM memory is always being overwritten while debugging and evidently isn't while running without STVD.

    This topic has been closed for replies.
    Best answer by henry.dick

    the answer is very simple:

    1. can you design an algorithm that, when it is not running, determines if it is running?
    2. can you have a life that, when it is dead, tells you that it is alive?
    3. can you have "X" that, when it is not operational, tells that you that it is operational?
    4. ...

    3 replies

    H
    henry.dickAnswer
    Visitor II
    July 8, 2020

    the answer is very simple:

    1. can you design an algorithm that, when it is not running, determines if it is running?
    2. can you have a life that, when it is dead, tells you that it is alive?
    3. can you have "X" that, when it is not operational, tells that you that it is operational?
    4. ...
    T
    Ted JacksonAuthor
    Visitor II
    July 9, 2020

    Hmm. Why the idiotic and sarcastic reply to a legitimate question, d..k? Or perhaps you're expressing some impatience with my relative nuby-iety regarding these wonderful (but somewhat complex) chips, which require a great deal of reading to understand fully, even for a dedicated engineer.

    Anyway, I eventually discovered that the code was overwriting the reserved data EEPROM area without warning after a look at the MAP file. I'd just assumed (foolishly it seems) that STVD would warn me of that, since it was told specifically (via MCU Configuration) that I was using that area for data EEPROM. Yep, typical nuby mistake.

    But d..k, I'm just DYING to know the answer to the three important philosophical questions you pose. Fortunately, I LIKE idiotic and sarcastic replies to legitimate questions. All the best!

    F
    f d
    Visitor II
    September 4, 2020

    I was wondering about the blocked flash after bootloader update.

    Processor is started from powerup/reset: PUKR=0x00, IAPSR=0x40 (Flash will be open for writes after unlock)

    Processor is started up from stvd: PUKR=0xAE, IAPSR=0x4A (Flash is open for write)

    Processor is started up from bootloader go command: PUKR=0xAE, IAPSR=0x40 (flash is write blocked until reset)

    To get the same starting condition my application starts with a reset:

    if (FLASH->PUKR != 0) WWDG->CR = 0x80;

    Terms & ConditionsAccessibility statement