I recommend that you recompile FF with
the SKIP_MULTITASKING option defined in the p18f-main.cfg
And flash it to the chip.
The Turnkey value in eeprom is at address hex ec00
BR Mike
On 05/08/2014 11:16 PM, Simon Bradley wrote:
> Mikael Nordman wrote:
>> Simon,
>>
>> Does it failafter turnkey definition immediately in the first warm
>> start ?
> I have just tried both a warm restart with WARM and also power off and on
> It worked this time around. I have an LCD display which I write text to
> when the PIC starts up. I only notice the fault when the display doesn't
> show the expected text and find that turnkey has been changed.
>
> the turnkey I use doesn't loop and exits back to the interpreter after running.
>
>
>> Otherwise I cannot think about any reason except that your
>> application corrupts the turnkey.
>>
>> One typical error scenario is return stack overflow which will write
>> crap into the bottom of the parameter stack.
>> Thus causing unexpected behaviour.
> Not sure if that happens as programs seem to run correctly
>
>> Multitasking gives you more opportunities to overflow the return
>> stack.
>> Once in each task.
> I haven't yet got into the multitasking scenario yet, so that probably
> isn't it. (Still learning FORTH using this device :)
>
>> The PIC HW return stack is written to the user area in PAUSE even if
>> you only run the operator task. Defining SKIP_MULTITASKING before you
>> compile FF excludes this copying.
>>
>> You could also increase the RETURN_STACK_SAVE_SIZE to d'62'.
>> It is a bit on the small side in the FF3.8 !
>>
>> ; Max size is d'62'
>> #define RETURN_STACK_SAVE_SIZE d'30' ; 15 cells return stack save area
> Ok, that's currently beyond me !
>
> Is there a way to check if the turnkey has been corrupted ? Is it stored
> in the EEPROM and copied to RAM ?
>
> Is there a memory map I can refer to to help try and understand what is
> going on?
>
>> BR Mike
> Thanks for your help,
> Simon.
>
>
|
