Isomax FSM tick limitation?

[fabio]

Folks,

I have been cleaning up some IsoMax code to improve efficiency/speed and seem to have stumbled upon an undocumented limitation. Here is an example. This example is a simple state machine to transmit ASCII codes to a serial 40-character display. The USART port employed had to be a software-created UART port (see Isopod documentation), in this case GPIO PE3.

In the example a contiguous block of memory stores a 40-character string which is loaded in one state transition and then transmitted character-wise in another state transition.

I have found that when the total number of characters to be stored and transmitted is set at 40, then the IsoMax locks up and must be scrubbed. I then made a series of versions which increased from 20 to 40 the total number of characters successively and also queried via SCI0 the TCFAVG and TCFMAX registers. (Actually there were two tiny state machines running in parallel to sense arrival of commands in the SCI1 buffer, and to sweep the ADC registers for display) Here are the results:


ISOPOD V2
ISOMAX V0.82
3 FSMs
Characters TCFMAX TCFAVG
20 4411 1804
30 5642 2282
36 6257 1802
37 6380 1804
38 lockup lockup


Although PERIOD is set to 50000, it appears that the individual state machine cannot consume more than about 6400 ticks, in this case.

QUESTION: Can anyone confirm this apparent FSM tick limitation?

Thanks in advance,
Fabio

( **************************************************************************** )
( **************************************************************************** )
( FOR ILLUSTRATION PURPOSES ONLY )
( NO WARRANTY EXPRESSED OR IMPLIED )
( PORTIONS ADAPTED FROM PUBLIC DOMAIN EXAMPLES )
( **************************************************************************** )

DECIMAL

PE3 IS-TX
9600 PE3 BAUD

( DISPLAY STORAGE UOM IS 16b CHARACTERS )
VARIABLE DISPLAY-STRING ( DISPLAY CHARACTER STRING )
-1 ALLOT ( BACK OUT THE WORD ALLOTTED FOR THE VARIABLE IN RAM )
40 ALLOT ( OPEN A HOLE IN RAM FOR THE STRING )
EEWORD ( MOVE DEFINITION TO EEPROM )
DISPLAY-STRING 40 ERASE ( CLEAN OUT THE HOLE WITH NULS )
( **************************************************************************** )

VARIABLE DCC EEWORD ( DISPLAY CHARACTER COUNT )
( **************************************************************************** )

MACHINE DISPLAY-M EEWORD
ON-MACHINE DISPLAY-M
APPEND-STATE DISPLAY-SEND-STATE EEWORD
( **************************************************************************** )
IN-STATE DISPLAY-SEND-STATE CONDITION PE3 TX? DCC @ 20 < AND
CAUSES
( DISPLAY NEXT CHARACTER OF DISPLAY STRING )
DISPLAY-STRING DCC @ + C@ PE3 TX
DCC 1+!
THEN-STATE DISPLAY-SEND-STATE TO-HAPPEN IN-EE
( **************************************************************************** )
IN-STATE DISPLAY-SEND-STATE CONDITION PE3 TX? DCC @ 20 = AND
CAUSES
0 DCC ! ( MUST RESET DCC AGAIN FOR STATE CONDITIONS )
( ISOLATE EACH NUMERAL IN 16b VALUE VIA DIVISION BY POWERS OF TEN )
( ASSUME FIVE SIGNIFICANT DIGITS PER VARIABLE ADDRESS )
( ADD 48 TO THE NUMERIC VALUE TO SHIFT ASCII CODE INTO NUMERALS )
VAR-ADDR @ 10000 /MOD 48 + DISPLAY-STRING 00 + C!
1000 /MOD 48 + DISPLAY-STRING 01 + C!
100 /MOD 48 + DISPLAY-STRING 02 + C!
10 /MOD 48 + DISPLAY-STRING 03 + C!
@ 48 + DISPLAY-STRING 04 + C!

VAR-ADDR @ 10000 /MOD 48 + DISPLAY-STRING 05 + C!
1000 /MOD 48 + DISPLAY-STRING 06 + C!
100 /MOD 48 + DISPLAY-STRING 07 + C!
10 /MOD 48 + DISPLAY-STRING 08 + C!
@ 48 + DISPLAY-STRING 09 + C!

VAR-ADDR @ 10000 /MOD 48 + DISPLAY-STRING 10 + C!
1000 /MOD 48 + DISPLAY-STRING 11 + C!
100 /MOD 48 + DISPLAY-STRING 12 + C!
10 /MOD 48 + DISPLAY-STRING 13 + C!
@ 48 + DISPLAY-STRING 14 + C!

VAR-ADDR @ 10000 /MOD 48 + DISPLAY-STRING 15 + C!
1000 /MOD 48 + DISPLAY-STRING 16 + C!
100 /MOD 48 + DISPLAY-STRING 17 + C!
10 /MOD 48 + DISPLAY-STRING 18 + C!
@ 48 + DISPLAY-STRING 19 + C!

( CONTINUE TO ADD MORE CHARACTERS AS DESIRED )

THEN-STATE DISPLAY-SEND-STATE TO-HAPPEN IN-EE
( **************************************************************************** )

DISPLAY-SEND-STATE SET-STATE
INSTALL DISPLAY-M

50000 PERIOD ( STANDARD STATE MACHINE CYCLE TIME - SEE TCFTICKS )
( **************************************************************************** )

[RMDumse]

Fabio, I haven't been able to absorb all you've written above, yet. But thought you might like some preliminary comments anyway.

38 is a curious number. Often I've found problems about there from stack problems, underflows or overflows. You might start looking there.

On the scheduled interrutps, if they occur, and do not terminate by the time the next scheduled interrupt comes along, the new interrupt will only run long enough to mark the overflow and return back to the previous running one. So one which is running long, can conceivable run forever, and when finally done, normal operations should pick up without a hitch. In theory at least.

So I'd suspect stack problems first, and timer overruns second.

[fabio]

Randy,

In support of your guess, I now have other evidence that disproves any FSM tick limitation. However, I have verified via SCI0 the stack neutrality of all of my procs and FSMs. Another clue is that querying AVAIL, EEAVAIL, PAVAIL, PFAVAIL via SCI0 reveals changing values. Here are the results of successive queries performed by pasting/downloading each set via SCI0.

?AVAIL OK
AVAIL ? 65 OK
EEAVAIL ? -8867 OK
PAVAIL ? 4481 OK
PFAVAIL ? 172 OK

?AVAIL OK
AVAIL ? 86 OK
EEAVAIL ? 172 OK
PAVAIL ? 4481 OK
PFAVAIL ? 172 OK

?AVAIL OK
AVAIL ? 53 OK
EEAVAIL ? -24320 OK
PAVAIL ? 4481 OK
PFAVAIL ? 172 OK

Is it expected that the data memory values should change so greatly?

Perhaps I am crossing boundaries in RAM during definition and/or manipulation of the multi-cell variables holding strings? Have any tips on how to check for this error?

Thanks for your help,
Fabio

[fabio]

Let me confess and share my journey,

Well I have learned viscerally the lesson of program RAM management during incremental compilation on the Isopod V2/Isomax v0.82 platform. I can now explain the problem with my text display finite state machine (FSM). It is quite simple, my display FSM consumes all of the program RAM when expanded to include the transmission of the 38th character and beyond. I have since dramatically improved efficiency of the code and also split it into smaller words of convenience rather than function. I was further confused by my inexplicable belief that words like AVAIL were registers thus causing misuse (see my first reply).

Several lessons were learned. These lessons are my opinion and no warranty is expressed or implied.

1. Fault isolation continues to be a fundamental concept in debugging programs.

2. The incremental/interactive compilation paradigm of FORTH and the Isomax v0.82 extension makes fault isolation much easier than traditional 3G programming.

3. The managed utilization of resources for compilation is equally important to the managed utilization of resources of the application. Conventional 3G compilers provide resource warnings automatically, but this is problematic to provide in FORTH.

4. The words provided to measure resource utilization must be integrated into the source code to track those resources during compilation.

4a. and every block of variables defined and moved into program flash should be followed by a check of data RAM thus
VARIABLE TESTVAR1 EEWORD
VARIABLE TESTVAR2 EEWORD
?AVAIL
AVAIL .

4b. and every word defined should have a check of program RAM before moving to program flash thus
: TESTWORD
\CODE GOES HERE
; PAVAIL .
EEWORD

4c. and every FSM state transition thus
MACHINE TESTMACHINE EEWORD
ON-MACHINE TESTMACHINE
APPEND TEST-STATE1 EEWORD
APPEND TEST-STATE2 EEWORD
IN-STATE TEST-STATE1
\CODE GOES HERE
THEN STATE TEST-STATE2 TO HAPPEN
PAVAIL .
IN-EE

4D. and every application compiled should have a total review of resources thus
?AVAIL
AVAIL .
EEAVAIL .
PAVAIL .
PFAVAIL .

5. As with all utilities, their proper use requires knowledge of their limitations. In addition to the Isopod V2 and Isomax v0.82 documentation I offer my personal clarifications of the memory-querying words (Isopod V2 memory map only):

( THESE ARE WORDS AND NOT REGISTERS NOR VARIABLES - NEVER USE '?' OPERATOR EG: AVAIL ? )
?AVAIL ( DATA RAM CELLS AVAILABLE AFFIRMATION SENT TO SCI0 )
AVAIL . ( DATA RAM CELLS AVAILABLE FROM $0293 THRU $07FF )
EEAVAIL . ( USER DATA FLASH CELLS AVAILABLE FROM $1800 THRU $1FFF )
PAVAIL . ( PROGRAM RAM CELLS AVAILABLE FROM $7E00 THRU $7FDF )
PFAVAIL . ( PROGRAM FLASH CELLS AVAILABLE FROM ???? THRU $7CFF )

NOTE: Documentation shows program flash from $5400 thru $7CFF but after SCRUB an examination of PDUMP reveals a different story. PFAVAIL's result appears to be reliable so I do not worry about the lower limit of program flash memory.

6. Special note for EEAVAIL: The data flash cells ($1800 thru $1FFF) are not reserved by the operating system and so are available for the user to store long-term data such as logs, look-up tables, calibration factors, etc. The EEAVAIL word result did not change when I manually loaded a few bytes into data flash which were verified with the DUMP word. I am unsure of the use of this word. I suspect that the issue is related to memory pages instead of cells. Using DUMP appears to be reliable in determining which cells are erased in data flash.

Hope these notes help others in solving mysterious problems on the Isopod V2/Isomax v0.82 platform.

Fabio :)