FALCON 030 RTC (2017 Batch)

[exxos]

The "fault" was the time wasn't advancing, but it wasn't something I actually took notice of on the last batch of boards during testing :roll: , So I don't know if they had that problem when shipped or not. I did have a lot fail on the last 2017 batch, but I had a lot of issues with solder paste on the last run of purple boards, so put it down to that. Those failed boards just went in the bin anyway.

The blue ones are all fully checked now that the time advances, There was like 80 of them made up and not one failed in any way. So I don't know why one batch would work perfectly, and another lot fail. Again, I put it down to the paste, but its only a guess. It can't be ruled out that something on your machines has killed them either.

I don't think there was many that batch, looking back there was 25 built, but I remember a lot failed, more failed than passed for sure. So probably about 10 ended in stock, you guys probably went through 5 of them.. But of course some problems were down to no capacitor on the falcon motherboard causing some faults as well.

Looking back again, it was likely Aug 24, 2017 batch. The next purple boards were Jan 30, 2018, I think those were the "in between" batches where I started fitting the capacitor (which your boards didn't have). Some later purple boards were stamped 2018. It doesn't mean of course that "all" boards during that batch had issues as the "Cause" of the failure isn't known.

[squareeyes]

Just thought I'd add to the conversation.

The only time I have issues updating the Exxos NVRAM is when I use the utility bootc201.zip by Uwe Seimet. After using that my Falcon boots to a black screen without fail. Popping the battery out of the NVRAM before powering back on after a few seconds often resolves this.

I now use http://centek.free.fr/atari/softs/s_nvram.htm instead to configure the NVRAM and it works flawlessly.

Obviously popping the battery or not having a NVRAM reset boot floppy handy is not going to work for everyone.

I also noticed that in the HDDriver app, one of the menu drop downs does report issues interrogating the Exxos NVRAM (can't remember which option) but it did before I ripped out the Dallas so am wondering if I didn't really need to swap it out after all?

Anyhow this doesn't prevent me setting up a bootbale CF device so I'm not too worried about it.

[exxos]

The only time I have issues updating the Exxos NVRAM is when I use the utility bootc201.zip by Uwe Seimet. After using that my Falcon boots to a black screen without fail. Popping the battery out of the NVRAM before powering back on after a few seconds often resolves this.

Thanks for letting us know. Maybe there NVRAM software is buggy somehow, I guess nobody considered that could be a issue. I will add your file to the NVRAM page, thanks.

[Stimpy]

I had a similar experience with a customers Falcon, replaced the NVRAM and it didn't boot. Put original back in and it was OK. I seem to remember it wouldn't even attempt to load from floppy so I had no chance getting that autobooting disk to work. I do remember fixing it by trying all the different NVRAM tools, probably from funet.fi or something :D Perhaps the tool by Uwe Seimet is good for pre-programmed NVRAM but not "fresh" ones where I guess all contents are 0xFF? If you look at the datasheet there is talk about bits needing to be set to make the oscillator run etc.

[exxos]

Perhaps the tool by Uwe Seimet is good for pre-programmed NVRAM but not "fresh" ones where I guess all contents are 0xFF? If you look at the datasheet there is talk about bits needing to be set to make the oscillator run etc.

Possible I guess.. Some modules people had problems where the time did not advance, It brought about the idea that there may have been faulty modules, though I couldn't get the ones returned to me working.. but never gave it a thought that software may not be setting the thing up right to start with.

Even so, people have had issues even using CP as well. I uploaded the ones I was using as seems to be multiple versions. Though I guess its possible it could be all software related issues rather than hardware. Everything works fine here, all the modules, time date saving/setting, boot options, even boards I have fitted it to. Though when the user gets the things, its nothing but trouble for some people. Typical day in Atari land....

[troed]

The "fault" was the time wasn't advancing, but it wasn't something I actually took notice of on the last batch of boards during testing :roll: , So I don't know if they had that problem when shipped or not. I did have a lot fail on the last 2017 batch, but I had a lot of issues with solder paste on the last run of purple boards, so put it down to that. Those failed boards just went in the bin anyway.
(snip)

So I'm not really able to follow the above. This is the one I have and am planning to mount, is that one of the more problematic ones? I don't really care either way except if I can help the debugging of the issue somehow :)

falc_rtc.JPG

[exxos]

So I'm not really able to follow the above. This is the one I have and am planning to mount, is that one of the more problematic ones? I don't really care either way except if I can help the debugging of the issue somehow :)

There isn't exactly any problematic ones that are known at the moment..

The difference between them all was I added a capacitor on later boards as it seemed to solve the read issues on boot up... But that is on the bottom of the board anyway..

Seems to be an epic load of random odd issues which I just cannot really correlate in any way currently. The only thing I know that on my end, is that everything tests out fine when I send stuff out.. As to why people are having issues, that's why I started the other thread, but there simply isn't enough information to even really speculate what the problem could be other than maybe the normal bad soldering and bad sockets with people main fitting. But it doesn't explain the boards which I have fixed which don't work properly when the user gets them.. Could be my bad soldering, but I do test things out for a few days before I send stuff out.

Even people fitting other modules are obviously having issues as well,even Dallas/maxium chips, so it isn't something simply to do with my modules, but the Falcon is not working with different chips for some bizarre reason. So I really don't know it is going on with it all.

EDIT:
I suspect this may be relating to the "bad" reset circuits in the Falcon.

[alienkidmj12]

just received one of these for my falcon, the solder on the top doesn't look great, half the holes look like the solder isn't filled in, i guess these have all been tested though. don't really want to try putting more solder in case i melt the battery holder :(

1644587976130.jpg

doesn't even fit, as the chip hits the centre bar, the pins ain't long enough

the one on this video shows the pins very long

[exxos]

just received one of these for my falcon, the solder on the top doesn't look great, half the holes look like the solder isn't filled in, i guess these have all been tested though. don't really want to try putting more solder in case i melt the battery holder :(

Don't fix things which are not broke!

The solder does not protrude the top like in this image, because of exactly what is seen, the solder causes the battery holder not to lay flush.

3.jpg

IMG_5644.JPG

The soldering "on top" is practically irrelevant and would mostly be just be cosmetic as these are Via holes which is where the main soldering joint is done. If you honestly think it is that bad then just return it and I will refund it.

[alienkidmj12]

the pins aren't long enough, the chip hits the centre bar so the pins don't hold it in :( not even long enough to directly solder to board even :(