Problem transferring files from a Mac

[srayner]

Hi Tom, I wonder if you can offer any advice on my issue.

I'm on a Mac. I have installed lrzsz using Brew. I then use the screen command to connect to the TommyPROM. Press w and enter, then press ctrl+A, then type
:exec !! lsx -b -X /path/to/my/file

It seems to start sending, fails on the first few bytes, then seems to successfully send until it reaches 65536.

What I think is happening is that the first few bytes are my small test program, and the remaining bytes are probably all zeros. I wonder if the checksum is failing for the bytes containing my program, but succeeding for all the zeros. Just a guess.

I get a success message at the end, but the result is a chip full of zeros.

I have tried with the XMODEM_CRC_PROTOCOL commented out/in and seem to get the same results.

Any advice is appreciated.

w
Send the image file using XMODEM CRC
CCCCSending /Users/steve/Downloads/test.z80.bin, 512 blocks: Give your local XMODEM receive command now.
Xmodem sectors/kbytes sent: 0/ 0kRetry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Bytes Sent: 65536 BPS:2650

Transfer complete

[TomNisbet]

If the checksum fails then the transfer will stop. If all of the bytes were sent then the code was probably happy with the transfer. Have you verified that your build can write to your chip? Try the Zap command to make sure you can write to the chip. Z 0 followed by D 0 should show a test pattern in the first 32 bytes.

There are some debug commands that may help if there is a problem with the XModem transfer.

• After the command finishes and you are back to a prompt, use the forward slash '/' key to reprint the last status message. Sometimes the output gets eaten by the XModem code, so this lets you display it again.
• There is an Info command 'I' that will print some debug information.
  If you post the output of those two commands, I may be able to spot something.

[srayner]

Hi Tom, thanks for your reply.

I can poke and zap fine. It's just file transfers that I'm having issues with. So I'm happy the hardware is working.

I have to be quite fast typing in the transfer command otherwise it times out. Here is a reasonably successful file transfer:

w
Send the image file using XMODEM CRC
CSending /Users/steve/test.bin, 512 blocks: Give your local XMODEM receive command now.
Xmodem sectors/kbytes sent: 0/ 0kRetry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Bytes Sent: 65536 BPS:2655

Transfer complete
/
Status of last command:

INFO: Success writing to EEPROM device. NumBytes=65536

I
debugBlockWrites: 1024
debugLastAddress: 0
debugLastExpected: 0
debugLastReadback: 0
debugRxDuplicates: 0
debugExtraChars: 98
debugRxStarts: 6
debugRxSyncErrors: 1

but it just seems to result in a chip full of zeros.

[srayner]

I've now switched to minicom as you seem to refer to that in your documentation. I have commented out the XMODEM_CRC_PROTOCOL

I have turned off hardware flow control in minicom.

I can connect and issue commands to the TommyPROM ok.

If I press w and enter
then press Esc-Z, S (to send file), select xmodem and press enter, space (to select file), then enter to send, I just get three beeps and nothing seems to happen.

Is there some configuration I need for minicom?

[TomNisbet]

I don't think the problem has to do with the communication protocol. The transfer would halt if the XModem transfer detected a problem or if the PromDevice28C::burnBlock code failed. Your example above shows that that the transfer completed after sending 64K bytes. The block size on the 28C256 chips is 64 bytes and the debugBlockWrites count is 1024, so that means that the code tried to write 64K to the chip and thinks it was successful.

I hate to ask this, but is it possible that your file is all zeroes? Was the chip all FFs before the transfer? It would be good to know if that data in the chip changed.

If your file is correct, then it feels like the burn code is failing quietly. Maybe make use of one of the debug variables to verify your data. For example, in burnBlock, add something like
debugRxDuplicates = data[0];
and send a file with less than 128 bytes. The debug info would then show the first byte of your file.

If the file data is making it as far as burnBlock, then try a check at the bottom, like
if (readByte(address) != data[0] return false;
That will verify the first byte in the block after writing the entire block.

[srayner]

Well this is a bit embarrassing. I think I've realised what the problem is. It seems I'm trying to write a 64K file to a 32K Eprom. I tried smaller files and they work fine. I guess the addresses are wrapping back around to the beginning again. The first 32K probably writes out fine, but then gets overwritten by the second 32K of data.

If it helps anyone else that might be using ASM80.com to generate bin files, specify:

.binto 32768

at the top of the source code.

I have noticed another issue though. I can't use the dump (d) command on any addresses above 00FF. I've been using the EEPROM for a while and I've not noticed a problem, but I've only ever used a small program in the first few bytes. So I suppose I could yet still have a hardware issue.

[TomNisbet]

64K - I probably should have noticed that! In my defense, I'm working with SST39FGS040s right now, so that didn't seem so big. You are correct that the EEPROM would write twice and end up with the last 32K of data.

What happens when you dump the higher addresses? Are you just seeing the same 256 bytes of data everywhere? Maybe the higher shift register isn't connected correctly. You can try the verify sketch in the Troubleshooting section and use the A command to set different addresses and verify the output pins with a multimeter or an LED and resistor.

[srayner]

The good news is it is correctly writing the full 32K of data, even though I can't see it with the dump command. I wrote a small Z80 program to display the contents of the memory and it all looks good.

When I try to dump using the d command with any address over FF I just get blanks back. It doesn't display the address or any numbers at all. I'm not near the programmer right now. I'll try to get a screenshot of the output tomorrow.