All CRT linker symbols are weak and can be overridden by a user. This
has been true since mspgcc3, and allows an aware user to do whatever
is necessary, while allowing the common case to be handled by default
or controlled by a single driver switch.
It is not necessary to duplicate CRT object files/libraries across the
families because WDTCTL is at different addresses: all peripheral
addresses are now resolved at link time. It is necessary to have
different libraries if one enables and one disables watchdog during
CRT code; then some selection mechanism is required.
Peter
On Fri, Mar 18, 2011 at 4:13 AM, Peter Jansen <pwjan...@yahoo.com> wrote:
> The existing code, while it looks ugly and has some pit falls, it may have
> been
> done for good reasons. When you add that extra variable, pushing the init of
> bss/data over the WDT time-out period and start triggering resets is quite
> confusing for a while.
>
> If you expect the WDT to be enabled, then you should test it works at some
> time
> during the development. This gets over the problem of being surprised that the
> startup code has disabled it.
>
>> __attribute__((naked, section(".init3"))) void __low_level_init()
>
>> {
>> }
>> This is "easily prevent" solution. Is it simple enough?
>
> I like this solution also, can these be made weak so that the user can also
> over
> ride them?
>
>> But I vote for not enabling WDT because it leads to different crt libs for
>> different mcu families because WDT registers are located at diferent
>>addresses.
>> I propose opposite solution: empty .init3 section in crt but user can add
>> __attribute__((naked, section(".init3"))) void __low_level_init()
>> {
>> WDTCTL = WDTPW + WDTHOLD;
>> }
>> to his source code to disable WDT and get precisely the same code as in
>>current
>>
>> version after linking. Moreover, user can add some peripheral init code
>> here.
>>It
>>
>> solves problem with different WDT locations, simplifying the library.
>>
>> By the way you can use those two solutions with current mspgcc version too,
>> so
>>I
>>
>> think there is no need for additional gcc option such as -menable-watchdog.
>> Everything what is needed is to _properly_document_ this tricks.
>>
>> I think that keeping device-depended WDT disabling code in crt library "just
>> because of historical reasons" _can_ lead to more problems with future MSP
>>devices.
>
> There is the option of keeping the WDT disable code in crt, keep the symbol
> undefined until the linker script, which is unique to each device. I have seen
> one gcc port doing it this way.
>
>
>> > besides being less than not obvious, it also digs the gap between mspgcc
>> > and the 'official' MSP compilers even deeper.
>> IAR has call to __low_level_init function (library version contain just
>> single
>>
>> RET) in their cstartup code and they propose it for peripheral
>> initialization
>
>> _and_ disabling WDT if necessary. No gap. Same function name, same goal.
>> Difference is that in gcc we don't need to CALL this function because we can
>> inline it.
>
>
> Regards,
>
> Peter Jansen
>
>
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
