Debugging issues with STE

News, questions and bugs reports about CosmosEx by Jookie. Now we have a Raspberry Pi in our machines!

Moderators: Jookie, Moderator Team

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Debugging issues with STE

Postby rj1 » Tue Nov 22, 2016 2:09 pm

Hi Jookie,

I have an STE which causes weird issues with CosmosEx.

Your HD test shows errors as in attached photo, but only in read tests. Write is OK.
In everyday use, games won't always load, refreshing a directory in GEM causes to go 1 level up, after booting only 1 or 2 of 3 saved open windows shown on desktop, etc.

What's interesting, when in use with Mega STE or a MEGA1, there is no issues with this particular CE.
CE is updated to latest firmware.
STE PSU and motherboard was recapped recently.

So far I have done the following, but nothing helped:

1. Tried 3 different DMA chips:
C398739-001A - original chip in this STE
C025913-38 - from a MEGA 1 machine
C100110-001 (IMP) - from another MEGA 1 machine

I also tried the original DMA with a diode on supply pin (as in some MEGA machines.)

2. Replaced all 4 ICs that are connected to the DMA port:
U302
U307
U305
U306

3. Added some more electrolytic capacitance close to the DMA (470uF).

4. Used TOS chips from Mega STE.

5. Used RAM modules from Mega STE.

Any ideas how to debug this?
I have a scope, logic analyzer.

Thanks
You do not have the required permissions to view the files attached to this post.

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Debugging issues with STE

Postby Jookie » Wed Nov 23, 2016 2:37 am

Hello rj1,

now that's another strange situation - working fine with 2 machines, having bad read operations with 3rd 8O

So the simplest thing you could do is:
- connect it do the good machine, run the HD test
- look at the ACSI signals with a scope during read and write oprations of the test, possibly take screenshots, or take some notes at least
- then connect it to the misbehaving machine, run the HD test
- check out those ACSI signals with the scope again (on read and write), compare it to the good machine results

I wonder if there will be any difference visible on the scope, because if not, then it might be harder to find...

The possible future option to examine this would be to alter the test to stop after such error (e.g. don't do retry), and also use some spare pin on Hans (STM32) as a trigger for such situation, so you could capture it better on the scope, but this would require a custom built Hans firmware...

Jookie

mikro
Atari God
Atari God
Posts: 1303
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: Debugging issues with STE

Postby mikro » Wed Nov 23, 2016 3:36 am

rj1, just before you destroy your STE completely ;), have you tried to source the power for the CE from a reliable USB adapter? (I use the one from iPad as it provides good current).

I had all sorts of strange issues, all due to a weak PSU. Recapped PSU doesn't equal stronger PSU.

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Debugging issues with STE

Postby Jookie » Wed Nov 23, 2016 5:59 am

mikro wrote:have you tried to source the power for the CE from a reliable USB adapter?


My guess would be that he already is using a good power supply - it works fine on 2 machines, it failes on 1 machine...

mikro
Atari God
Atari God
Posts: 1303
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: Debugging issues with STE

Postby mikro » Wed Nov 23, 2016 6:55 am

Jookie wrote:
mikro wrote:have you tried to source the power for the CE from a reliable USB adapter?


My guess would be that he already is using a good power supply - it works fine on 2 machines, it failes on 1 machine...

On the contrary, he's using different PSUs in each machine. So if the (recapped but still weak) PSU in the STE is failing, it would explain the symptoms. But that's only a very wild guess.

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Debugging issues with STE

Postby Jookie » Wed Nov 23, 2016 7:26 am

mikro wrote:On the contrary, he's using different PSUs in each machine. So if the (recapped but still weak) PSU in the STE is failing, it would explain the symptoms. But that's only a very wild guess.


Ah, ok, if he's using internal supply, then you're right. I though he was using an external USB PSU. Did I miss that in the original question?

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: Debugging issues with STE

Postby rj1 » Wed Nov 23, 2016 7:31 am

Thanks for replies.

I forgot to mention I actually has been checking also with a genuine Garmin USB charger and it was giving the same results, so I assumed it's not the PSU.
But let's try a PSU from a MEGA 1.

Then it's time to take the scope to the signal lines and start comparing.

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: Debugging issues with STE

Postby rj1 » Wed Nov 23, 2016 1:46 pm

Tried recapped MEGA PSU - even worse results.
Made a 4 wire 5V supply+remote sensing cable and supplied the STE from a lab PSU with really good regulation (25mV p-p on the scope) - really bad results too, lots of C, some 1's and some 2's errors on Read tests.

So this takes PSU out of equation I guess.

All the errors are on Read line though, there is never any Write error.

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: Debugging issues with STE

Postby rj1 » Wed Nov 23, 2016 2:00 pm

Found something interesting...
I noticed HD1 signal has about 44k pull up to 5V rail when CE is connected to STE (measured inside the STE, on 68R resistor).
When disconnecting the CE, it goes up to ~400k.
Then when taking the multimeter probe away and putting it back at the resistor, it now is mega ohms range... weird.
All other signals show no pull up resistance.
Might be the socket is broken.

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Debugging issues with STE

Postby Jookie » Wed Nov 23, 2016 2:37 pm

Found something interesting...
I noticed HD1 signal has about 44k pull up to 5V rail when CE is connected to STE (measured inside the STE, on 68R resistor).


And by HD1 you mean the DATA1 line?

...because I've checked the schematics, I got a 47k pull down (not up) on DATA1 line by mistake - it was on ACSI RESET line in version 1 (with smaller CPLD chip), and it seems like I've made a mistake when drawing version 2 (with bigger CPLD and SCSI support) and placed the resistor on a wire next to it :cry: You could remove this resistor in CosmosEx and see if there's an improvement in this issue.

https://dl.dropboxusercontent.com/u/50798228/bad_hombre.jpg

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: Debugging issues with STE

Postby rj1 » Wed Nov 23, 2016 3:00 pm

On STE schematics it's called HD1 so I suspect it's the same as DATA1:
http://dev-docs.atariforge.org/files/ST ... 3-1989.pdf
Could be to ground, yes, as I'm seeing about 90R constant resistance after all the capacitance charges between 5V and ground.

I'll remove it and re-check.

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: Debugging issues with STE

Postby rj1 » Wed Nov 23, 2016 3:55 pm

Removed the resistor and the 44k resistance is now gone, but it didn't fix it, with MEGA PSU it still gives lot of errors.

Powering from lab PSU and changing the 5V rail a bit, as soon as I get to about 5.06V measured in the DMA area on the MB, it starts to work fine (at least for some short testing time). Below that level lots of 'c' errors start to appear.

My MEGA PSU gives about 4.99V on DMA chip.

Also noticed the STE has 68R resistors and 74245 in line with HD0-7 signals while MEGA machines have none (direct connection from DMA socket to DMA chip.)

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Debugging issues with STE

Postby Jookie » Wed Nov 23, 2016 5:30 pm

Damn, I hoped for some better results with that resistor removed :)

Anyway, interesting find with that with the bit higher voltage it works better... That reminds me that Exxos (Chris Swinson) made some experiments with STE DMA, there were some pull ups involved on DMA chip, it's an interesting read. Did you see that one?

http://www.exxoshost.co.uk/atari/last/DMAfix/

User avatar
1st1
Atari Super Hero
Atari Super Hero
Posts: 694
Joined: Mon May 07, 2012 11:48 am

Re: Debugging issues with STE

Postby 1st1 » Wed Nov 23, 2016 5:47 pm

rj1 wrote:1. Tried 3 different DMA chips:
C398739-001A - original chip in this STE
C025913-38 - from a MEGA 1 machine
C100110-001 (IMP) - from another MEGA 1 machine

Be carefull, DMA chip from standard ST is the wrong one! You need special STE DMA chip.

chips'n'chips from my friend Michael R. explains it:

http://phoenix.inf.upol.cz/~opichals/li ... P&index=57

Google translated:
1040STe and problems with hard drive operation

In this configuration, there have been isolated cases in which
It can lead to sporadic adulteration of data or mutilated
Directories on the hard drive has come.

The following remedy is proposed:


(1) Check whether pin 9 of resistor network P105 is connected
And pin 1 of the video converter U401 (data-
Bit DB7). If this is not the case, a connection between the
Both points by means of a wire.
(2) resistance network P100 (2.2 kohm, can also factory a 2 kohm
Type) with one with 8 * 1.2 KOhm.
(3) A capacitor of 30 pf between pin 5 of the resistor-
Network P100 and ground (XBR).


Very often I am asked why not the C025913-38A as a DMA chip
In the list. The answer is quite simple, the 520 / 1040STE,
MegaSTE and TT030 have a modified ACSI-DMA interface and
In the aforementioned computers, only the C398739-001 works
Or C398789-001A (DMA chip STE (U300)) as a DMA chip.

The following symptoms indicate a C025913-38 / -38A as an ACSI-DMA-
Close the controller: In the middle of the formatting process the mel-
The diskette is write-protected.
Write access to one or more connected hard disks
End with data loss, but read accesses work!
Power without the Price. It's not a bug. It's a feature. _/|\_ATARI

1040STFM in PC-Tower (PAK68/2, OvrScn, 4 MB, 1GB SCSI, CD-ROM...) * 2x Falcon 030 32GB/14MB+ScrnBlstrIII * 2x TT030 73GB/20MB+Nova * 520/1040STFM * 520/1040STE * 260/520ST/+ * some Mega ST * 2x Mega STE 500MB/4MB+M.CoCo * Stacy * STBook * SLM605 * SLM804 * SLM605 * SMM804 * SH 204/205 * Megafile 30/44/60 * SF314 * SF354 * 5x Pofo * PC3

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: Debugging issues with STE

Postby rj1 » Wed Nov 23, 2016 5:50 pm

Well at least you have now a small bug ironed out in your design thanks to this thread :)

I know about that investigation, thanks anyway.
I already tried some pull up values (I had 5k6, 10k I think) before I started to swap DMAs. It wasn't helping for me.

Since CE is using XC Xilinx CPLD, I assume it's running on 3.3V. So when reading from CE it sends 3.3V logic high, if you don't mind sharing some details?

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: Debugging issues with STE

Postby rj1 » Wed Nov 23, 2016 5:53 pm

Ok that's interesting, thanks for info.

1st1 wrote:
rj1 wrote:1. Tried 3 different DMA chips:
C398739-001A - original chip in this STE
C025913-38 - from a MEGA 1 machine
C100110-001 (IMP) - from another MEGA 1 machine

Be carefull, DMA chip from standard ST is the wrong one! You need special STE DMA chip.

chips'n'chips from my friend Michael R. explains it:

http://phoenix.inf.upol.cz/~opichals/li ... P&index=57

Google translated:
1040STe and problems with hard drive operation

In this configuration, there have been isolated cases in which
It can lead to sporadic adulteration of data or mutilated
Directories on the hard drive has come.

The following remedy is proposed:


(1) Check whether pin 9 of resistor network P105 is connected
And pin 1 of the video converter U401 (data-
Bit DB7). If this is not the case, a connection between the
Both points by means of a wire.
(2) resistance network P100 (2.2 kohm, can also factory a 2 kohm
Type) with one with 8 * 1.2 KOhm.
(3) A capacitor of 30 pf between pin 5 of the resistor-
Network P100 and ground (XBR).


Very often I am asked why not the C025913-38A as a DMA chip
In the list. The answer is quite simple, the 520 / 1040STE,
MegaSTE and TT030 have a modified ACSI-DMA interface and
In the aforementioned computers, only the C398739-001 works
Or C398789-001A (DMA chip STE (U300)) as a DMA chip.

The following symptoms indicate a C025913-38 / -38A as an ACSI-DMA-
Close the controller: In the middle of the formatting process the mel-
The diskette is write-protected.
Write access to one or more connected hard disks
End with data loss, but read accesses work!

User avatar
exxos
Hardware Guru
Hardware Guru
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: Debugging issues with STE

Postby exxos » Wed Nov 23, 2016 9:39 pm

rj1 wrote:Powering from lab PSU and changing the 5V rail a bit, as soon as I get to about 5.06V measured in the DMA area on the MB, it starts to work fine (at least for some short testing time). Below that level lots of 'c' errors start to appear.


What happens with 5.5V ?
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: Debugging issues with STE

Postby rj1 » Thu Nov 24, 2016 11:56 am

I don't feel comfortable supplying 5.5V, I could check 5.25V.

exxos wrote:
rj1 wrote:Powering from lab PSU and changing the 5V rail a bit, as soon as I get to about 5.06V measured in the DMA area on the MB, it starts to work fine (at least for some short testing time). Below that level lots of 'c' errors start to appear.


What happens with 5.5V ?

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Debugging issues with STE

Postby Jookie » Thu Nov 24, 2016 12:23 pm

rj1 wrote:Since CE is using XC Xilinx CPLD, I assume it's running on 3.3V. So when reading from CE it sends 3.3V logic high, if you don't mind sharing some details?


Well, basically that's just it. There's XC9572XL, running from 3.3V, having this code inside:
https://github.com/atarijookie/ce-atari/blob/master/ce_xilinx_v2_acsi/main.vhd

When doing write from ST, the data port is in Hi-Z.
When doing read to ST, the data is driven on that ACSI port, and the INT and DRQ lines are either hight-Z (and thus H, due to pull ups in ST), or pulled low (and thus low).

The pins of Xilinx are 5V tolerant, so it handles signal levels on write just fine.
The pins of Xilinx should produce at least 3V when chip is powered by 3.3V, which is enough above 2V minimal voltage for TTL high level. But as it seems those buffers in STE think otherwise...

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: Debugging issues with STE

Postby rj1 » Thu Nov 24, 2016 1:14 pm

Jookie wrote:
rj1 wrote:Since CE is using XC Xilinx CPLD, I assume it's running on 3.3V. So when reading from CE it sends 3.3V logic high, if you don't mind sharing some details?


Well, basically that's just it. There's XC9572XL, running from 3.3V, having this code inside:
https://github.com/atarijookie/ce-atari/blob/master/ce_xilinx_v2_acsi/main.vhd

When doing write from ST, the data port is in Hi-Z.
When doing read to ST, the data is driven on that ACSI port, and the INT and DRQ lines are either hight-Z (and thus H, due to pull ups in ST), or pulled low (and thus low).

The pins of Xilinx are 5V tolerant, so it handles signal levels on write just fine.
The pins of Xilinx should produce at least 3V when chip is powered by 3.3V, which is enough above 2V minimal voltage for TTL high level. But as it seems those buffers in STE think otherwise...


Thanks, I'm asking because Xilinx actually recommends to drive low for 0 and go into high-z for 1 and then rely on pull-ups of 500-1kohms to pull up to 5V, when driving 5V logic:

https://www.xilinx.com/support/document ... /ug445.pdf, page 21 and later.

This is what me and Rodolphe are doing in our 020 board (we have XC95144XL).

Xilinx even have a shorter rise time version in that pdf, where you first drive 3.3V for a short period then go into high-z, but we couldn't get it to work so far.

Since the CE code is available, I could do some testing on my side after adding some pullups, and report if it works better when the supply level is lower than say 5V.

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Debugging issues with STE

Postby Jookie » Thu Nov 24, 2016 1:40 pm

rj1 wrote:Thanks, I'm asking because Xilinx actually recommends to drive low for 0 and go into high-z for 1 and then rely on pull-ups of 500-1kohms to pull up to 5V, when driving 5V logic:
https://www.xilinx.com/support/document ... /ug445.pdf, page 21 and later.


Wow, nice to know that (after so many years of doing it not the proper way 8O :D ).

In the SCSI setup it's doe this way exactly - either driven low, or Hi-Z so the termination can take over the high level - on every pin, even the data ones. And that reminds me - for the SCSI+ACSI version - in ACSI setup - if you would use different terminating resistors than for SCSI, also connect different pull up voltage (5V instead of SCSI Vterm), e.g. by placing the resistor network one pin off the socket, then you would need to solder only 2 wires - to 5V and to those free pins of resistor network, while the resistor networks would be in the sockets. On the ACSI only version you could solder those resistor networks from bottom side of the CE pcb, which would be more soldering, but you still got the nice pads for each of the wire...

rj1 wrote:Since the CE code is available, I could do some testing on my side after adding some pullups, and report if it works better when the supply level is lower than say 5V.


Now that could be the only and best non-me contribution to the hardware! Looking forward for the results :)

Jookie

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: Debugging issues with STE

Postby rj1 » Thu Nov 24, 2016 2:17 pm

I'm glad I can help a bit :)

I have the ACSI+SCSI version, the one pin off the socket method sounds very easy to implement.
Though that needs to wait a week or so before I can test it.
For programming the CPLD, is there a JTAG port on the CE board or the only way is through update app?

Thanks

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Debugging issues with STE

Postby Jookie » Thu Nov 24, 2016 2:29 pm

rj1 wrote:For programming the CPLD, is there a JTAG port on the CE board or the only way is through update app?


There was the JTAG for Xilinx in the older version of the PCB, but it wasn't used as it's also connected to GPIO pins of Raspberry Pi, so you had to remove RPi to avoid those two fighting on the pins (although I think it worked without removing the RPI a couple of times when the Raspberry Pi was idle - not driving the pins).

So currently you either have to solder some wires to create that extra JTAG for Xilinx (e.g. under the GPIO connector of RPi, where those pins go), or - as you mentioned - use the update thing for that. There's the /ce/update/flash_xilinx app, which takes path to .xsvf file generated from Xilinx ISE, and it flashes the Xilinx (but make sure the CosmosEx main app is turned off during that - run /ce/ce_stop.sh ) - so just transfer the file to the device (e.g. using WinSCP), then run the flashing app.

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: Debugging issues with STE

Postby rj1 » Sat Dec 31, 2016 1:52 pm

OK, only now I'm able to move this forward.

For a start I successfully synthesized/translated/fitted the source you pointed:
https://github.com/atarijookie/ce-atari ... i/main.vhd
though I'm not sure if you leave all the settings for these processes as default? For example Optimization Goal/Effort, Slew Rates etc.
Do you have a .xise file for the project or could you share the settings?

Thanks

ijor
Hardware Guru
Hardware Guru
Posts: 3146
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Debugging issues with STE

Postby ijor » Sun Jan 01, 2017 6:17 pm

rj1 wrote:Thanks, I'm asking because Xilinx actually recommends to drive low for 0 and go into high-z for 1 and then rely on pull-ups of 500-1kohms to pull up to 5V, when driving 5V logic:
https://www.xilinx.com/support/document ... /ug445.pdf, page 21 and later.
This is what me and Rodolphe are doing in our 020 board (we have XC95144XL).


I can't rule out there is an issue with that, but it shouldn't. Xilinx recommendation doesn't apply here. As specified in that Xilinx document you link, using pullups is recommended only for devices where "5V is truly necessary". Here all the chips involved are either TTL, NMOS, or in the worst case CMOS with TTL compatible inputs. They need 2V, not 5V.

Actually, most DMA devices back at the day probably didn't drive 5V on the ACSI port either because they used TTL outputs (not CMOS) without pullups.

Also on the STE the ACSI bus is buffered. The DMA chips is not affected by the ACSI port voltage levels.


Social Media

     

Return to “CosmosEx”

Who is online

Users browsing this forum: No registered users and 1 guest