peter,
to clarify what i said earlier,
WDTCTL = WDTPW + WDTHOLD; // Stop WDT
was the fourth line in a setup fn called as the first line in main.
moving the register assignment itself to the first line of main did not
change the behavior. but 32 ms is a long time, so i wouldn't expect
moving it back in time < 1 us would make a difference.
as i mentioned earlier, the code and the build are dirt-simple. i will
file a bug report so someone can take a closer look.
thanks,
steve
On 09/29/2011 12:44 PM, Peter Bigot wrote:
> On Thu, Sep 29, 2011 at 11:38 AM, steve ayer<[email protected]> wrote:
>
>> hi peter,
>>
>> that was it!
>>
>> i assumed that stopping the watchdog in sw (fourth line of the app) was
>> enough. damn!
>>
>
> It should be, assuming the first three lines are comments or declarations.
> The C runtime code is expected to pet the watchdog while it's in control, so
> once main is entered you should have close to the full 32ms to chain it up
> if you don't want it barking.
>
> If you're getting a watchdog before your code in main() is executed, and
> you're not using __init functions or static C++ constructors or overriding
> linker sections or otherwise messing with the C runtime code, there's a bug
> and I'd like to see a reproducing test case filed on the mspgcc tracker at
> http://sourceforge.net/tracker/?atid=432701&group_id=42303&func=browse.
>
> Peter
>
>
>>
>> thanks very much,
>>
>> steve
>>
>>
>> On 09/29/2011 12:33 PM, Peter Bigot wrote:
>>
>>> Are you using -mdisable-watchdog, or otherwise stopping the watchdog
>>> from resetting your board 32ms after power-up? The current msp430
>>> toolchain does not do this automatically like the old one did.
>>>
>>> Peter
>>>
>>> On Thu, Sep 29, 2011 at 11:12 AM, steve ayer<[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> hi folks,
>>>
>>> last summer (july 2010) i bought a ti eval board for the 5438 and
>>> proceeded to pull together and test the dirt-simple devel pieces before
>>> proceeding on to trying to work with tinyos on this mcu.
>>>
>>> short story is that is used the then-current mspgcc4; wrote my own bsl
>>> so that i had a boilerplate for modding tos-bsl to support this mcu;
>>> wrote a ~25-line blink in c to test it.
>>>
>>> result: i could compile, objcopy -> ihex, bsl, and execute blink on
>>> the
>>> little eval board. nothing elaborate or fancy:
>>>
>>> msp430-gcc -mmcu=msp430x5438 -o blink.exe blink.c
>>> msp430-objcopy --output-target=ihex blink.exe blink.ihex
>>> bsl /dev/ttyUSB0 blink.ihex
>>>
>>> happiness, now i could try out real stuff. then i got sidetracked
>>> until
>>> now.
>>>
>>> following all of work of peter bigot, eric decker, razvan, et. al on
>>> the
>>> uniarch toolchain, i pulled the latest assembled bits (most easily from
>>> tinyprod.net<http://tinyprod.net>, thanks guys) and went back to
>>>
>>> step one.
>>>
>>> after the requisite header/prototype changes to blink.c, everything
>>> seems to work properly, except that the code doesn't run. (yes, i can
>>> install the old ihex and make the board blink again).
>>>
>>> a quick comparison of the working ihex file with the new one i see that
>>> they're vaguely similiar, the addresses/sizes of the code/vectors seem
>>> right, but...
>>>
>>> i did try adding the -mcpu=430xv2 flag to the compile line, but that
>>> makes no difference in the ihex.
>>>
>>> can anyone please offer a pointer on how to proceed?
>>>
>>> thanks,
>>>
>>> steve ayer
>>>
>>>
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ------------------
>>> All the data continuously generated in your IT infrastructure contains
>>> a
>>> definitive record of customers, application performance, security
>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>> sense of it. Business sense. IT sense. Common sense.
>>>
>>> http://p.sf.net/sfu/splunk-**d2dcopy1<http://p.sf.net/sfu/splunk-d2dcopy1>
>>> ______________________________**_________________
>>> Mspgcc-users mailing list
>>> Mspgcc-users@lists.**sourceforge.net<[email protected]>
>>>
>>> <mailto:Mspgcc-users@lists.**sourceforge.net<[email protected]>
>>>>
>>>
>>> https://lists.sourceforge.net/**lists/listinfo/mspgcc-users<https://lists.sourceforge.net/lists/listinfo/mspgcc-users>
>>>
>>>
>>>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
>
>
>
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
