• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 79 subscribers
  • Views 3236 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCSv6 MSP430 GCC Watchdog disable pre main

Alexander Pitzer
Prodigy 50 points
Other Parts Discussed in Thread: MSP430F2617

Hallo everyone,

I use a MSP430F2617 and I have a progam that uses 

MSP430: Loading complete. There were 3916 (code) and 22 (data) bytes written to FLASH. The expected RAM usage is 456 (uninitialized data + stack) bytes.

The thing is, the Watchdog is reseting everything before I reach my main (the code never reachs 0x0059d4). How can I disable the Watchdog, I tried it with the pre_init.c but I believe the GCC Beta doesn't support this.

I can see that the reset happens during the memset call from the __crt0_init_bss():

How can I place my code infront of this function?

  • 0
    Guru 227245 points

    Copying 22 data bytes and initializing 456 byte (minus stack) to zero shouldn’t take so long that the watchdog triggers.

    Sure you can disable the watchdog by writing your own pre_init function where you disable it. But disabling the watchdog even once makes it useless.
    What if an ESD event crashed the MSP, the watchdog restarted it but the same ESD event crashes it again while the watchdog is of during data init? Had this happening, and learned this way that the MSPGCC3 init code disables the watchdog. I rewrote the init code to kick the watchdog instead.

    Still strange that initializing such a few bytes will be slow enough to trigger the watchdog.

  • 0 in reply to Jens-Michael Gross
    Prodigy 50 points

    " Copying 22 data bytes and initializing 456 byte (minus stack) to zero shouldn’t take so long that the watchdog triggers.

    Sure you can disable the watchdog by writing your own pre_init function where you disable it. But disabling the watchdog even once makes it useless."

    1. The question is, HOW can I wirte my OWN pre_init? because I use the ti-gcc and the way like everone writes, dont work.

    2. Yes 22 data bytes and 456 bytes triggers the watchdog! And I dont want to use the watchdog!

    I disabled the starup-code and use the reset vector to dissable my watchdog, but this brings some disadvantages, I dont want.

    Has anyone an idea to solve this?

  • 0 in reply to Alexander Pitzer
    Guru 227245 points

    The C startup code is toolchain-specific. The pre-init function, as described in so many posts, is something the startup code of the TI compiler provides. GCC uses its own startup code and provides (or not) different means.
    For MSPGCC 3.2.3, I had to rewrite the reset function completely, as there was no such hook as pre-init.

    (and, well, I didn't want to disbale the watchdog, but wanted it to be triggered during the initialization, as a disabled watchdog, even for a short time, can't do its job to revive a device in case of an ESD- or supply-induced crash)

    The only resource here is the compiler documentation - or an analysis of the startup code source or the linker script.

  • 0 in reply to Jens-Michael Gross
    Prodigy 50 points

    I could fix this problem, too.

    I defined a function like this

    // disables the watchdog between the __start() and the __crt_0init()
__attribute__ ((naked,section(".crt_0000init")))
void __alex_disable_watchdog() {
    WDTCTL = (WDTPW + WDTHOLD);
}

    and I found something very ... lets say it looks like another bug to me.

    at 0x3214 there is a mov #0x5a80 which is the needed code to disable the Watchdog but its moved into a ADC register. Coud it be, that the code calls the wrong register for the msp430f2617?

  • 0 in reply to Alexander Pitzer
    Guru 227245 points

    No, your code is the line below, which properly writes to WDTCTL. But it uses a MOVX instruction for this, which is strange, as a normal MOV.W would be okay. It seems to assume a long constant (see the 0x05a80

    Where the write to ADC12MEM14 comes from is unknown. And it makes no sense. Very strange.
    It doesn't hurt here, but if an artifact like this can sneak in here, without an apparent reason, then it could happen somewhere else, where it causes damage.

    Maybe you should ask this question in the compiler forum, As this is obviously a compiler problem.

**Attention** This is a public forum