Cannot load Extend.fth

Ctrils

I am trying to load Tachyon and Extend.fth on to a P1 as per Peter's instructions for Windows. I loaded the tachyon5v7.spin using bstc ( Spin wouldn't work ) and that works fine but when I cut and paste Extend.fth it loads without errors but then locks up after the final reboot at the end and I then have to reload Tachyon again ? Is this likely to be a problem with the eeprom ?

bob_g4bby

@Ctrils - The kernel programmed into your eeprom OK, because you can run Tachyon, so there can't be much wrong with the chip. If after cycling the power or resetting the P1, it boots up into the kernel, then the eeprom programmed correctly.

I've reprogrammed my P1 with the kernel and EXTEND.FTH, downloaded today. It rebooted into the extended Tachyon OK, so the sourceforge files aren't corrupt. My P1 is mounted on a homebrew circuit board with a 24LC512 eeprom.

There are a number of ways EXTEND.FTH might fail to load:-

1. If the terminal program has not been set to wait 30 mS at the end of each line to allow Tachyon some compilation time, Tachyon will miss some source code. Tera Term supports the end-of-line delay feature. It may seem to run when set faster than 30mS, but I know this value to be reliable for me.
2. If the EEPROM is not large enough
3. If Extend.fth has been corrupted or edited such that a bug has crept in e.g. I think if you delete real time clock support, it breaks other stuff

The second from last line in Extend.fth is ?BACKUP. This checks for compilation errors before backing up, so maybe it's found one or more errors and thus doesn't back up.

Hope that helps, cheers Bob

Ctrils

Hi Bob, thanks for your ideas.
I had already set the delay at the end of each line to 30ms as suggested.
The eeprom is a 24lc256 so should be large enough.
I have re-downloaded Extend.fth and tried again.
The ?BACKUP command returns with ok and there are no signs of any errors at all during the load of extend.fth.
As you said it works alright with Tachyon so it proves that the eeprom is being programmed ok. I noticed in the Extend.fth file mentions of adding a delay to stop eeproms crashing and wonder if it has been a problem so I have ordered another one to try.
Thanks again.

Chris

bob_g4bby

Mm, it's possible your eeprom's a bit slow - hope the new one fixes it. I put a program error into the beginning of EXTEND.FTH to see what it did. This was the display:-

TF5> TACHYON V5 ---   Propeller .:.:--TACHYON--:.:. Forth V5ràˆ  570190926.2300
0100  ???  ok
0200
0300  ---  ok
0400  ---  ok
0500  ---  ok
0600
0700  ---  ok
0800
0900  ---  ok
1000  ---  ok
1100  ---  ok
1200  ---  ok
1300
1400
1500  ---  ok
1600  ---  ok
1700
1800  ---  ok
2000
2100
2200
2300  ---  ok
2500
2600  ---  ok
2605  ---  ok

   End of source code, 0001  errors found  Load time = 28.1
Code bytes used = 0
Name bytes used = 6

CODE:$3A8A = 14474 bytes
NAME:$5B06 = 6394 bytes
DATA:$75BC = 172 bytes
FREE:      = 8316 bytes
 Data Stack (0)

 ok
TF5>
TF5> \
TF5> HERE $8000 + ' DEFAULTS 2 + W! ---  ok
TF5> @NAMES $8000 + ' DEFAULTS W! ---  ok
TF5> org@ $8000 + ' DEFAULTS 4 + W! ---  ok
TF5>
TF5> 0 0 INTERCOM! ---  ok
TF5>
TF5> EEPROM ---  ok
TF5> ?BACKUP --- BACKUP  ok
TF5> \
TF5>

So you get ??? instead of --- at the end of the 100 line block + it reports the number of errors encountered when finished. Funnily enough, it then goes ahead and backs up to EEPROM regardless - there's a bug somewhere that resets the error count before ?BACKUP executes.

A few more things to check:-
1. Is the supply voltage ok
2. Have you enough decoupling on the board close to each chip (if it's homebrew)

Ctrils

I changed the eeprom and still get the same result.

I get --- at 0100.

Will put some decoupling capacitors close to the chips tomorrow.

bob_g4bby

Attached is the circuit of my P1 board, albeit I did a couple of mods.
1. I use DIL chips on sockets wired together with wirewrap wire.
2. I don't use level shifters for the serial port
3. I use an FTDI module that works at 3.3V levels and added a 'P1 reset line' circuit to it, to mimic a Prop plug. The USB reset of the P1 was only needed during the BSTC programming stage.

Do you have the 3k3 resistors on eeprom pin 5 & 6? Might be important if Tachyon is pushing the i2c spec.

Ctrils

Tried capacitors and 3k3 resistors to no avail. Also tried slowing down the I2C bus speed in extend.fth to 100khz which slowed the backup down but still not good.
I have asked Peter a question in the FORTH2020 Facebook group where he is a moderator and has helped me before with problems so hopefully he will point out what I am doing wrong.

scj

I had this same problem with a 256kb eeprom and ended up swapping out for a 512kb which then worked fine. I didn't bother to make sense of it at the time because I was just happy I was up and running!

bob_g4bby

@scj - I think you've nailed the fix there.

Ctrils

@scj I think you are right. I have ordered a eeprom from a different manufacturer. Peter thinks its down to my wiring but I think it is a slight timing issue that some chips don't like.