• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 368 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430-GCC-OPENSOURCE: Watchdog timeout during CRT .bss initialisation

Thilo Schulz
Prodigy 230 points
Part Number: MSP430-GCC-OPENSOURCE

The memset() implementation from newlib that is used during .bss initialisation is very inefficient.

Thus, when having a .bss of > ~3kBytes in RAM, .bss initialisation takes too long and the watchdog, that initially runs at SMCLK=MCLK speed, times out on my MSP430F5XXX series MCU. This jibes with the fact that memset() uses 9 CPU cycles (!!) for each byte in its core loop.

As a workaround, I have moved some variables to the .noinit section which works fine for my use case. But this is only a workaround.

As memset() really shouldn't mess with watchdog configuration (this is up to the application user), the CRT must implement this initial .bss clearing without memset() and periodically reset the watchdog timer if cleared memory section is too large.

Also, a proper memset() implementation for MSP430 would only take 3 cycles per byte.

  • 0
    Guru 88700 points

    With the CCS compiler/library, one would define a _system_pre_init() which stops the Watchdog (prior to C initialization). 

    I haven't used GCC for the MSP430, but based on this:

    https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/503358/1829576

    I think the name of that function for GCC is __low_level_init(). (That's also what IAR uses.)

    Failing that, there's also this, which is a bit older, but maybe still applies:

    https://e2e.ti.com/support/tools/ccs/f/81/t/472090

  • 0 in reply to Bruce McKenney47378
    Guru 18885 points

    There is a file included in the distribution which describes what to do: ../ti/gcc/examples/watchdog.txt

  • 0 in reply to David Schultz
    Prodigy 230 points

    Alright. Though I would never want to hold the watchdog timer. Just switch it over to ACLK instead of SMCLK, which will yield a timeout of ~2-3 seconds

  • 0
    Expert 2410 points

    Section 5.3 of the the MSP430-GCC User's Guide also goes into detail about the C Runtime Library startup behavior, also describing how to disable the watchdog before initialization of large .data or .bss sections.

    The implementation of performance-optimized memset and memcpy routines for the library are on the backlog of things to do.

    Regards,

  • 0 in reply to Jozef_Lawrynowicz
    Prodigy 230 points

    I apologize. This is a question where RTFM would definitely have helped, though I still believe the application writer should never need to worry about the watchdog before main() is entered. So I still believe the CRT should periodically reset the watchdog, i.e. like between every 30000 MCLK

  • 0 in reply to Thilo Schulz
    Expert 2410 points

    No problem.

    There's a bit of a technical limitation to putting code to disable the watchdog in the CRT library.

    The watchdog address can vary between devices, so the command cannot be hard-coded into the library, which is shared between all MSP430 devices. We wouldn't want to start including lots of different target-specific versions of the CRT library to work around this.

    We also can't use symbols that will be resolved by the linker, because the user may not use the MSP430-GCC linker scripts provided by TI.

    An inventive solution could probably work around these problems, but it's not high priority.

    It's unfortunate, because this has been a common issue, but this is why it's now explicitly documented it in the latest version of the User Guide.

    Regards,

  • 0 in reply to Jozef_Lawrynowicz
    Prodigy 230 points

    Jozef_Lawrynowicz said:
    We also can't use symbols that will be resolved by the linker, because the user may not use the MSP430-GCC linker scripts provided by TI.

    That is fair enough.

    Doesn't the CRT make assumptions about linker scripts already? For instance, user-defined linker scripts are required to define symbols like "__stack", etc. Personally, I try to see the linker scripts as provided by the tool chain as immutable, and when overriding those I do include them using the gnu linker script's "include" directive.

    Jozef_Lawrynowicz said:
    There's a bit of a technical limitation to putting code to disable the watchdog in the CRT library.

    I consider disabling the watchdog altogether, as has been frequently suggested here, would be harmful. It should continue to run, and only be reset periodically by start-up software. This way, if a glitch during CRT initialisation causes the MSP to be in an undefined state, the chances of recovery are better. As I said already, when the user is not able to modify memcpy() he can increase the watchdog timeout instead, but the device would still recover.

  • 0 in reply to Thilo Schulz
    Guru 18885 points

    RTFM wouldn't have helped a few months ago as this is the first revision of that manual to include this information. A long overdue addition.

**Attention** This is a public forum