STE V1.5 32MHz BOOSTER - STATUS

[exxos]

I've got enough GAL's to complete the 8 ish ones I have... but doesn't still mean they will work after I swap the GAL's.

I will spend 2 more days on these (not around much tomorrow though) and what ever is working goes in my store.

..and this red board on test has just locked up This is acting like the CPU is crapping out, so may try a 32MHz OSC in it if it keeps on doing that... I think in relation to CPU "over heating" its not helping as this booster runs at constant 36MHz. With the V1 booster, it basically spent half of the time in 8MHz mode, I half think that was a better design overall. But of course that had its own issues as well.

Though I am thinking these things are just more trouble than they are worth. Seems to be 1 step forward, 2 steps back all the time with them all the time

Will see how these last few boards pan out, but I think its getting very close to me abandoning this project, otherwise I will never get anything else done.

EDIT:

OK 32MHz didn't help.. So I'm back to blaming the GAL again... I am going to leave the GAL's running in my test board for a lot longer.. I'm thinking as they warm up its also causing them to fail.

[exxos]

So a new gal failed pretty quick. My old stock gal has been running for about a hour. So I think I'm just going to bin all these gals. Its getting stupid to have to pre test them all like this.

BUT.

https://uk.farnell.com/microchip/atf22v ... t=Atf22v10

I forgot those are still available..

The problem is they have a power down pin on pin 4 which I can't figure out how to disable. But I'm going to order 10 and see if I can reroute whatever is on pin 4 to another pin and then I can tie pin 4 to 5v.

I think its more than clear that these gals from China are just not worth bothering with anymore. They must be defective parts somehow. Its not like the atmel gals are costing huge amounts anyway.

My only concern is if they don't work with my booster for some odd reason.. I don't see any reason for them not to work.. But never know until i try some out...

[troed]

PD pin configuration is controlled by the design file, and appears as a separate fuse bit in the JEDEC file. When the power-down feature is not specified in the design file, the IN/PD pin will be configured as a regular logic input.
Note: Some programmers list the 22V10 JEDEC compatible 22V10C (no PD used) separately from the non-22V10 JEDEC compatible 22V10CEX (with PD used)

It does seem strange you even get problems with PD - if you're not specifically trying to use it it should not be an issue.

[exxos]

It does seem strange you even get problems with PD - if you're not specifically trying to use it it should not be an issue.

I was talking to Atmel a great deal in 2015 about it all.. A quick re-read and they think my programmer was enabling the PD feature as it didn't actually have a proper device number listed.

I am pretty sure I stopped using pin 4 and the problems went away. Also seems Atmel sent me a modified jed file to turn off the feature, and it still didn't work. So I assume I just gave up with them at that point... I will probably have to buy a different programmer to program them

[exxos]

ATF chips should be here sometime tomorrow

The irony in all this is...

22.jpg (61.3 KiB) Viewed 1839 times

Pin 4 isn't actually used, so I just need to tie to 0V I think to disable the PD thing..

I guess that is what happens when I copy paste bits of code year after year

[exxos]

I've not connected pin 4 on the PCB, but so far we are powered by Atmel! Just started the machine doing its loops in GB6...

IMG_3604.JPG (119.05 KiB) Viewed 1815 times

[exxos]

I got distracted yesterday with other things, so did not do much testing..

But yesterday the ATF chip booted but failed to complete a full loop.. I have actually removed the series resistor with the schmitt buffer and removed the small capacitor as well... It was last night, and it got to somewhere around 35 passes then quit to desktop :-\

I started this running this morning again and it is currently at about loop 48. So almost been going about three hours.. I need to know how long it runs for before it crashes so I can then retest again. This way I can try and find out if it is some sort of thermal fault or not.

I think part of the problem is that the GAL's output voltage is not consistent and sometimes does not drive the correct voltage levels for the buffer.

I am also half thinking that the tolerances of the GAL's drift as the chip warms up, but again I needed it to fail so I have a reference of how long it runs full with the ATF chip.

I'm also half wondering if the OSC itself as it drives the clock pin on the GAL, if you should have the resistor put back, it is only a guess, but if the voltage is higher than the GAL likes, maybe that is heating up junction inside the chip causing it to fail..

So I need to scope stuff out, but I do not want to start probing things while I am doing the soak testing as it may well cause it to crash.

The basic good news is that the ATF chip is definitely working considerably better than those other GAL chips.. So this is the least a huge step in the right direction..

[exxos]

Loop 108, So it least this particular ATF GAL works

Is been running for around 7 hours now.

So will start doing some scoping tests...

IMG_3633.JPG (17.28 KiB) Viewed 1779 times

EDIT:

Nope, can't see any real difference between the "duff " GAL's and the ATF in terms of voltages. Tried the scope on every pin in x10 and x1 modes, makes no odds. So a unsolvable mystery I guess

Will start testing a second ATF see what happens now...

[PhilC]

Just chalk it up to WTF

[exxos]

I just think they are sub-standard somehow. I mean they can run at 8MHz, but the only difference in 36MHz is the flip flops are active more. So I think the internal flip flops can't run fast for some reason. They seem to be 15ns parts stamped as 7ns, no surprise there, but 12ns should be fine, ATF's are 15ns and work fine. I think these ATF chips run cooler than the GAL's as well.