flashforth-devel

[Flashforth-devel] problems with recent source build (FlashForth 5 PIC18F46K22 13.06.2019)

[craig b. <dab...@ya...>]

I had been using a kernal build from 2015 source but ran into problems with words that would run if invoked directly from interactive terminal but instantly cause warm reset if used in other words (no cause code shown).
I've assembled the 13.06.2019 Pic18 source in MPLabX and tested my words.  The work as intended and I can include them in bigger things.
The problem comes when I try to load up the several large text files that comprise the application.  It appears that somewhere  between 2/3 and 3/4 of my package the compiler wraps an address and starts over-writing the beginning of the user-dictionary.  I'm trying to get a number close to the address where things blow up, but it isn't always consistant, possibly from wiping out something that it's trying to use/

Here's one post-mortem that I caught (^O stoppes the runaway periods in the word dump):

 FlashForth 5 PIC18F46K22 13.06.2019

  ok<#,ram>
decimal ram  ok<#,ram>
 flash hi here - u. cr 39713
 ok<#,flash>
 eeprom hi here - u. cr 917
 ok<#,eeprom>
 ram hi here - u. cr  3461
 ok<#,ram>
words
p2+ p++ pc@ @p hi d. ud. d> d< d= d0< d0= dinvert d2* d2/ d- d+ dabs ?dnegate dnegate s>d rdrop endit next for in, inline repeat while again until begin else then if until, again, begin, else, then, if, not, nc, nz, z, br? dump .s words >pr .id ms ticks s0 latest state bl 2- ['] -@ ; :noname : ] [ lst does> postpone create cr [char] ( char ' abort" ?abort ?abort? abort prompt quit true false .st inlined immediate shb interpret 'source >in tiu tib ti# number? >number a> >a ud/mod ud* sign? digit? find immed? (f) c>n n>c @+ c@+ place cmove word parse \ /string source user base pad hp task ulink bin hex decimal . u.r u. sign #> #s # digit <# hold up min max ?negate tuck nip / u*/mod u/ * u/mod um/mod um* 'key? 'key 'emit p+ pc! p! p@ r>p !p>r !p u> u< > < = 0< 0= <> within +! 2/ 2* >body 2+ 1- 1+ negate invert xor or and - m+ + abs dup r@ r> >r rot over swap drop allot ." ," s" (s" type accept 1 umax umin spaces space 2swap 2dup 2drop 2! 2@ cf, chars char+ cells cell+ aligned align cell c, , here dp ram eeprom flash c@ @ c! ! sp@ 2constant constant co: 2variable variable @ex execute key? key emit ver warm empty btfss, btfsc, bsf, bcf, bra, rcall, call, goto, br3 br2 as3 as1 rshift lshift ic, i, operator Fcy mtst mclr mset iflush pause turnkey is to defer value cwd u1- u1+ fl+ fl- >tblp literal int! ;i di ei scan skip n= rx1? rx1 tx1 i] [i andlw, movf, w, a, load busy idle exit

?R2 R2: ?R1 R1: ?T2 T2: ?T1 T1: ch# adcal _adcal N2m N1m R2 R1 R2m R1m T2 T1 adc@ xring adcinit .dp2 .dp1 1sectst maxtmr0 t6if? t6if0 t5if? t5if0 t4if? t4if0 t3if? t3if0 t2if? t2if0 t1if? t1if0 t0if? t0if0 t0ie0 -FUNCTION -STOP2 tstch adcmanual cvttrig adcreset adc!cfr adc@dat adc@cfr adcdfalt adcwakeup adchansel spib_19 spib_4 -ADS8332 spibinit RSTd RSTb, RSTb| RSTb> INTb, INTb| INTb> CVTb, CVTb| CVTb> SSb, SSb| SSb> SDIb, SDIb| SDIb> SDOb, SDOb| SDOb> SCKb, SCKb| SCKb> -SPIb_BANG slowspi spi@F/64 spi@F/16 spinit ssp1con2 SSP1M, CKP, SSPEN, SSPOV, WCOL, ssp1con1 BF, CKE, SMP, ssp1stat ssp1add ssp1buf ssp1msk BOEN, ssp1con3 SS1, _ENA, LDAC, SDI1, SDO1, SCK1, -SPI1 getpercent %heat heatoff heaton maxheat pwms analogoff ccp1init ccp2init t6init t6pwms v#hex s#Lo s#Hi heatset bump cnt nbuf adcy adcx gledoff gledon yledoff yledon 2.5/ 2.5* Splus ccptmrs1 ccptmrs0 t6con pr6 t4con pr4 t2con pr2 t5con tmr5l tmr5h t3con tmr3l tmr3h t1con tmr1l tmr1h t0con tmr0l tmr0h ccp5con ccpr5l ccpr5h ccp4con ccpr4l ccpr4h ccp3con ccpr3l ccpr3h ccp2con ccpr2l ccpr2h ccp1con ccpr1l ccpr1h -H385SYS ansela anselb anselc ansele trise trisc trisb trisa late latc latb lata porte portc portb porta -PORTS 2array type2 tx2 tx2dis tx2ena u2cfg. setu2baud u2init u1init tx2ip1 tx2ip0 tx2ip? rc2ip1 rc2ip0 rc2ip? tx2if? rc2if. tx2ie1 tx2ie0 tx2ie? rc2ie1 rc2ie0 rc2ie? rx2, tx2, anseld portd latd trisd 460.8K 230.4K 115.2K 57.6K 38.4K 19.2K 9.6k baudcon2 rcsta2 txsta2 txreg2 rcreg2 spbrg2 spbrgh2 pie3 pir3 ipr3 rcsta1 txsta1 txreg1 rcreg1 spbrg1 spbrgh1 baudcon1 pie1 pir1 ipr1 \dbar \hln2 \ulf2 \llf2 \lrg2 \urg2 \vln2 \hbar \ulft \lrgt \cros \hlin \lfmi \lmdn \lmup \llft \urgt \rgmi \vlin \hlf3 \hlf2 \hlf1 \ohm \deg \bs \c- \c+ \hid \rev \bli \unl \bri \res \attr \t \cp \cbn \cb \cfn \cf \cdn \cd \cun \cu \nl \eel \esl \el \clsh \cls \h \; .n esc[ -VT100 .Y......n.j.. . B.v .....R3.f ...............  ..... ...............  ..... ...............

It appears to have over-written these words previously written:

-VT100 darray carray array f.4 f.3 f.2 f.1 $. %. #. crev p_hi p_lo splitword swapbytes uq* qm+ d>q uq/mod tmp dcnt divisor dividend -QMATH m*/ um*/ ut/ ut* */ */mod mod /mod fm/mod sm/rem m* d1- d1+ -MATH bit?: bit^: bit1: bit0: (bit) -BIT ov, mi, cc, tblwt+*, tblwt*-, tblwt*+, tblwt*, tblrd+*, tblrd*-, tblrd*+, tblrd*, nop, sleep, return, retlw, retfie, reset, push, pop, daw, clrwdt, xorlw, sublw, mullw, movlw, movlb, lfsr, iorlw, addlw, btg, xorwf, tstfsz, swapf, subwfb, subwf, subfwb, setf, rrncf, rrcf, rlncf, rlcf, negf, mulwf, movwf, movff, iorwf, infsnz, incfsz, incf, dcfsnz, decfsz, decf, cpfslt, cpfsgt, cpfseq, comf, clrf, andwf, addwfc, addwf, as2 as0 Tp plusT Tminus Treg status Sp Srw SWrw plusS Sminus Sreg b, f, -AS default| | jumptable -JMPTBL endcase endof default of case (of) -CASE .heres .free pick 2literal count in? ?dup blanks erase fill forget evaluate -CORE marker

Am I violating some limit I'm unaware of yet? (It IS a lot of words...)
Is there an earlier known-stable version of the source that I should be using?
Could I be puting something into a colon-definition that could trash a system pointer?

Any thoughts and/or suggestions appreciated gratly.
Thanks.
craig bair

Re: [Flashforth-devel] problems with recent source build (FlashForth 5 PIC18F46K22 13.06.2019)

[Mikael N. <mik...@fl...>]

Hi Craig.

If your flash DP grows over $ec00 it will overwrite the system DPs in 
eeprom.

There is no check or warning about this limit.

You can put 'flash here cr u. cr' in your source files to see what 
happens.

BR Mike

On 2019-08-29 23:19, craig bair via Flashforth-devel wrote:
> Am I violating some limit I'm unaware of yet? (It IS a lot of words...)
> Is there an earlier known-stable version of the source that I should be 
> using?
> Could I be puting something into a colon-definition that could trash a
> system pointer?
> 
> Any thoughts and/or suggestions appreciated gratly.
> Thanks.
> craig bair
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

Re: [Flashforth-devel] problems with recent source build (FlashForth 5 PIC18F46K22 13.06.2019)

[craig b. <dab...@ya...>]

 Thanks, Mike, but I'm guessing that's not my problem... Results aren't necessarily the same sending the same file to the same processor after sending the "empty" word. I emptied it last night before going home, started everything back up this morning, added extended version of immediate free at every marker and loaded the file up. It finished successfully.

Here's the starting point from "empty":

 flash hi dup u. here dup u. - u. cr ebff 2300 c8ff 
 ok<$,flash>
 eeprom hi dup u. here dup u. - u. cr efff ec0c 3f3 
 ok<$,eeprom>
 ram hi dup u. here dup u. - u. cr ff37 f1a1 d96 


Here's the ending stats:

 flash hi dup u. here dup u. - u. cr ebff 640e 87f1 
 ok<$,flash>
 eeprom hi dup u. here dup u. - u. cr efff ec2c 3d3 
 ok<$,eeprom>
 ram hi dup u. here dup u. - u. cr ff37 f22e d09 


I'm still under the half-way point on flash space according to this log.
Also, this same file loaded to a Pic18F45K22 build of the same source behaved just as badly.

If I were to empty the chip and try to load it again at this point, it's highly likely that things would blow up again. instead, I'm going to shut everything down, let it cool off, and try to load the interrupt system words later.

I've added 528 words to the user dictionary beyond the 294 of the system. As I remember, there was a way in the older forths to daisy-chain multiple used dictionaries. That probably isn't as useful in an empeded context, but is it worthwhile to do an "iflush" every once in a while? Will this force the flash dp to a 64-byte boundry or will it carry any already-defined bytes in the buffer over and add on from that point when more comes in?

I'll keep playing with it to see if I can spot more behavioral patterns. If it matters, I'm developing on an old Gateway P3 based laptop running Win-XP Home SP2 using TerraTerm v4.75...

Oh, one thing that struck me as odd with this board is when TeraTerm connects. I routinely plug its onboard FTDI into the computer, start TerraTerm (which is already set to its virtual com port), then apply power to the board. Normally I expect to see the FF5 self-announce at this time, but on this board I see nothing at all until I hit enter. If I hit enter before applying board power, there's a "?" vefore the OK prompt. Odd, and I don't do board design so I have no idea why it acts like that.

Many thanks for your time,
craig


     On Friday, August 30, 2019, 5:36:39 AM EDT, Mikael Nordman <mik...@fl...> wrote:  
 
 Hi Craig.

If your flash DP grows over $ec00 it will overwrite the system DPs in 
eeprom.

There is no check or warning about this limit.

You can put 'flash here cr u. cr' in your source files to see what 
happens.

BR Mike

On 2019-08-29 23:19, craig bair via Flashforth-devel wrote:
> Am I violating some limit I'm unaware of yet? (It IS a lot of words...)
> Is there an earlier known-stable version of the source that I should be 
> using?
> Could I be puting something into a colon-definition that could trash a
> system pointer?
> 
> Any thoughts and/or suggestions appreciated gratly.
> Thanks.
> craig bair
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael


_______________________________________________
Flashforth-devel mailing list
Fla...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel
  

Re: [Flashforth-devel] problems with recent source build (FlashForth 5 PIC18F46K22 13.06.2019)

[craig b. <dab...@ya...>]

 Mike,

Out of sheer annoyance and desperation, I went through my source-text with a fairly large fire-axe and cut out all of the comments, everything ALREADY DEFINED, anything that popped out "?" or a COMPILE ONLY, and the drivers for chips that weren't on this board. Size dropped from over 63k to just under 29k and nothing that wasn't intended to get fed in to be compiled was left. LO-and-BEHOLD it reliably loads consistantly.
Being in a hurry under pressure bit me again, you'ld think I'ld learn (old bears take a while to pick up new tricks).

One of the new things I needed was increment and decrement for double-cell 32-bits. This seems quick on the Pic18 and I haven't found a hole in the logic yet:

$ffeb constant SWrw \ PLUSW0 \ FSR0 + Offset to Sp in W

: d1+ ( d -- d+1 ) \ increment double on stack
 [ $fd movlw, SWrw f, a, incf, ]
 [ $fe movlw, status $0 a, btfsc, SWrw f, a, incf, ]
 [ $ff movlw, status $0 a, btfsc, SWrw f, a, incf, ]
 [ $00 movlw, status $0 a, btfsc, SWrw f, a, incf, ]
;

: d1- ( d -- d-1 ) \ decrement double on stack
 [ $fd movlw, SWrw f, a, decf, ]
 [ $fe movlw, status $0 a, btfss, SWrw f, a, decf, ]
 [ $ff movlw, status $0 a, btfss, SWrw f, a, decf, ]
 [ $00 movlw, status $0 a, btfss, SWrw f, a, decf, ]
;


Thanks once again for your patience and attention,
craig



     On Friday, August 30, 2019, 5:36:39 AM EDT, Mikael Nordman <mik...@fl...> wrote:  
 
 Hi Craig.

If your flash DP grows over $ec00 it will overwrite the system DPs in 
eeprom.

There is no check or warning about this limit.

You can put 'flash here cr u. cr' in your source files to see what 
happens.

BR Mike

On 2019-08-29 23:19, craig bair via Flashforth-devel wrote:
> Am I violating some limit I'm unaware of yet? (It IS a lot of words...)
> Is there an earlier known-stable version of the source that I should be 
> using?
> Could I be puting something into a colon-definition that could trash a
> system pointer?
> 
> Any thoughts and/or suggestions appreciated gratly.
> Thanks.
> craig bair
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael


_______________________________________________
Flashforth-devel mailing list
Fla...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel