@evanh said:
However, through experience, Sync Clock is known to have narrower tolerances. Setting that to false gives slightly better margins. I don't have an explanation.
I did a bit more experimenting around this recently. To make pin input sampling timing at sysclock/1, and maybe helpful at sysclock/2 as well, reliable above 60 MHz I found a combination of toggling Data-Registered(Sync) and Data-Schmitt were excellent companions for effecting a sub-sysclock delay-line - https://forums.parallax.com/discussion/comment/1561512/#Comment_1561512 Clock pin is best left unregistered.
I think I could add schmitt mode as a flag - does it mess up the output drive in any way? Because currently all the pin modes are just set once on startup and I'd like to keep that.
Also oomf the misoyume ZIP i posted to make it easier to find just got paginated off again.
@Wuerfel_21 said:
I think I could add schmitt mode as a flag - does it mess up the output drive in any way?
It's just a pin input modifier.
However, the whole situation is temperature dependant so you kind of want to dynamically adjust as it warms up. It's also board design dependant, so it needs to at least run-time calibrate at boot as a minimum. ie: Ditch those constants.
The 4bit SD driver does the dynamic recalibration, although, since it is not using sysclock/1 transfers, it doesn't to try to calibrate for sub-sysclock delays.
@evanh said:
However, the whole situation is temperature dependant so you kind of want to dynamically adjust as it warms up. It's also board design dependant, so it needs to at least run-time calibrate at boot as a minimum. ie: Ditch those constants.
That sounds like pain. As-is configuring the constants on a per-board basis for sys/2 or sys/3 has worked fine. Auto-calibrating it on boot only is a bad and terrible idea as it might find a setting that is almost-but-not-quite reliable. And re-calibrating dynamically - no time/space for that.
Ok, misoyume running! We'll see how long can go without fan...
At first it didn't. Then, remembered how lost a day trying to get MegaYume running. Nothing was working. Tried about 4 versions of MegaYume and 4 versions of Flexprop in various combinations and nothing.
Finally realized that somehow the ROM files got corrupted and all showed up as 32 kB, obviously wrong.
Same thing happened here, 32 kB. No idea how or why this happened...
MisoYume died while typing this. Guess this is the point where a fan is needed. Will try with that now for a while...
What is the clock freq here? Think MegaYume is 325 MHz and NeoYume is 345 MHz, right?
The current master of MegaYume will run slightly different clocks depending on video mode. I still have to fix interlacing before I can merge video-nextgen into master. The progression in clock speed is not just for fun, there are codepaths that just barely fit in. I spent a lot of time squeezing down the video code in MisoYume and it still needs really high speed to fit in all cases.
At first it didn't. Then, remembered how lost a day trying to get MegaYume running. Nothing was working. Tried about 4 versions of MegaYume and 4 versions of Flexprop in various combinations and nothing.
Finally realized that somehow the ROM files got corrupted and all showed up as 32 kB, obviously wrong.
Same thing happened here, 32 kB. No idea how or why this happened...
Might need to unmount the SD card before pulling it from the PC. Normally that shouldn't be needed (all writes flush as soon as possible), but who knows what's going on. 32kB sounds exactly like one cluster.
Compared to 1.4-RC1:
- Slightly increase ROM loading speed
- Enable P_SYNC_IO for HDMI pins (fixes signal quality malarkey on some setups)
- update to usbnew 1.1.6 (should not matter)
New silly program: RAM tester.
Takes a NeoYume config file and just keeps testing the PSRAM (read and write). Reports errors on a per-chip basis.
Pictured: @MXX gaming board, settings as displayed. Chip on lane 1, bank 5 (i.e. the high nibble of the last 16MB) fails pretty much instantly. These settings appear to work fine-ish because to see this issue in NeoYume itself, you'd need to play a very large game and have the corruption happen to a BIOS code fetch (regular code ROMs load into a different bank). Note that there is a better setting on this board: 15,sync,async. Failure shown for illustration purposes.
Still need to add HyperRAM support and make sure it works on all configurations.
Nice one. I like how it identifies and displays the failing bank and 4 bit lane. Could be useful in case of a bad PSRAM device affecting everything. Might be good to eventually have a way to auto-iterate through different settings to find a good one too. You might be able to go down to single bit level as well in case there is a bad wire, although in that case it's likely that the read/write commands themselves won't be correctly recognized by the PSRAM so nothing will come back at all.
I forgot the PSRAMs need initialization, so need to add that so it can work from a cold start.
Though it appears to be possible to init a chip by accident (I guess if the data bus lines up just right to enable quad mode?)
Designed to be a close match to how specifically NeoYume operates (including any oddities it has - I don't know why WAIT=5 instead of WAIT=6). So it requires a config.spin2 file taken from NeoYume to configure RAM/video/etc. There's no default config in the ZIP download.
Supports 4/8/16 bit PSRAM and HyperRAM (same as NeoYume)
RAM is tested using a sequence of 7 block patterns. The length of the test pattern depends on the bus width, so that it always takes 256 transfer cycles.
pseudo-random (XORO32 seeded by address)
3 kinds of "chirp" signal (FF00FF00FF style bit toggling)
3 kinds of "checkerboard" signals (55AA55AA style bit toggling)
(Because usual RAM sizes are not divisible by 7, each RAM block should get each pattern once after 7 iterations)
2 Unused cogs are set to run busywork.
The music frivolously added is the battle theme from Princess Maker 2 for PC-98 (If I had a spine I'd compose a "RAM test theme", but no energy for such fun right now)
This has been very quickly hacked together, so don't expect nice code.
Some interesting findings so far:
When there is an instability, it is usually found in under a minute. (I'd still suggest leaving it running for longer, so the system can reach thermal equilibrium)
As seen above, MXX gaming board has a pseudo-stable fast mode: 14,async,async, where only the last bank will fail. 15,sync,async is stable. (NO NOT REALLY! I DON'T KNOW WHAT TO THINK ANYMORE)
The mode I advise (in RAMCONFIG.MD) for the Rayslogic 24MB board, 15,sync,async, has fails on bank 0, but 14,async,async is ok.
The Rayslogic 96MB board does not have a single valid fast mode setting where any bank is working. Really a slow mode only board.
When you set a wrong value for PSRAM_BANKS, interesting things can happen (especially if you touch one of the CS pins with your finger) - this is what caused the screenshot above
An EDGE board running on a crappy power supply USB cable will produce a fail on lane 2
Oh no, it seems some more advanced skulduggery is afoot. After realizing what a difference those dummy cogs made, I realized I never tested it with those present on the MXX board and there tragedy struck: With dummy cogs, the 15,sync,async setting is no longer stable (and starts failing on the low-numbered banks! argh!). Interestingly, the 17,sync,sync slow setting is also not stable anymore on this (16, async, async seems fine?).
I may have created a monster I can't control. Or rather, the benchmark for new boards to beat.
Also, there's still that idea of using schmitt mode as an extra adjustment. I'm also not 100% sure if all the combinations of clock/data sync are really useful. Some might cause issues during write?
@Wuerfel_21 said:
Also, there's still that idea of using schmitt mode as an extra adjustment. I'm also not 100% sure if all the combinations of clock/data sync are really useful. Some might cause issues during write?
With all the different combinations in use with the clock as well it starts to complicate the code. I had that issue with the HyperRAM driver and had to do all sorts of tricks to add different clocks delays in different places. ie. the exact same code doesn't work with different pin settings.
Schmitt seems to not really help much at all. Maybe same issue where it messes up the writes.
But here's where I'm going ＭＥＮＴＡＬ: I think it's the fricking USB cables.
So backstory, I have two USB to barrel jack adapters. One of them is evil in some ineffable way and tends to cause things to not to work. At some point I misplaced the good one, so today I tried to run the EDGE off the evil one, which lead to many fails (I had to disconnect either the fan or the LCD that I had attached to get it to boot at all and even then the RAM test would have fails). Then I remembered that old tale of the two cables and went to find the good one (which I seem to have left laying around after some experiment measuring mains voltage leakage on various power supplies). That fixed the EDGE and made it pass the RAM test with both LCD and fan still attached (in being derived from NeoVGA, the test output can even be on the LCD!)
So, the MXX board. I just received it like yesterday and I just quickly wanted to test it. It uses a full-size B connector, so I grabbed the first thing I had for that, which is some super thin retractable thing. That worked fine. Until I just tried running the final version of the RAM test (with dummy cogs) - fails where there previously weren't any. And now guess what - after I grabbed a proper nice USB cable, the fails are gone again!!!!!
I feel like I need to repent and start apologizing for making fun of audiofools for buying low-oxygen platinum-plated 10000$ cables now.
(In all of these cases, it's connecting to the same USB port on my PC - despite my own recommendations, I often run the EVAL off of just that, too, no aux power. I guess these new-style 3.1 kinda ports have enough juice in them?)
(also, interesting how the crappy barrel cable is somehow worse than the super-thin retractable USB cable)
If you get a chance could you do us all a favor and measure what "5V" signal reaches the boards with the crappy cables? ie is it 4.5 volts? 4 volts? etc (when running your test code)
Relatedly, MXX board running off good cable:
Notice "First fail: 08:19:15". That seems a bit odd that it'd run for 8 hours and then fail a few minutes before I come down to check it. Maybe someone turned on the toaster or something and that got it?
@Tubular said:
Ada good that you found/remembered that.
If you get a chance could you do us all a favor and measure what "5V" signal reaches the boards with the crappy cables? ie is it 4.5 volts? 4 volts? etc (when running your test code)
Well, preliminary result with the following caveats: a) measured from USB port VBUS b) using a crappy USB power meter that's partially broken c) running NeoYume and not the RAM tester because the latter doesn't turn VBUS on on the MXX board.
PC USB port, good cable: 4.84V
PC USB port, dubious retractable cable*: 4.57V
Old Smasnug charger**, dubious retractable cable: worked once, 4.80V, never again (???)
Old Smasnug charger, good cable: Refuses to turn on (????)
*: Connected to the end of a good cable with a bunch of adapters. This is how I had it initially.
**: Probably came with a Galaxy S5 or something of that vintage. "5.3V 2A". It really is 5.3V without a load.
So there seems to be an issue with using a charger that causes it to not power on at all (no LEDs). I also tried some others, but they're not of note. There's also a barrel input on this board. There's a "K7805-3AR3" regulator in there, which allegedly wants a 24V DC input. The Rayslogic boards also have one. Need to dig out a supply for that. Lots of things to test. All of that and more will have to wait till sunday evening or monday though.
tl;dr; crappy cables drop 5V rail to dubious levels, though even the good cable isn't much better. Using 12/24V supply might lead to better results. Should also try the 5V supply from a powered hub.
There's a "K7805-3AR3" regulator in there, which allegedly wants a 24V DC input. The Rayslogic boards also have one. Need to dig out a supply for that. Lots of things to test. All of that and more will have to wait till sunday evening or monday though.
Please note the "K7805-3AR3" regulator is wide input and accepts from 8VDC to 36VDC, BTW Burning Test is looking great !!!!!
PS
I'm working on the PCB to try improve PSRAM connections
@Wuerfel_21 Memory tester sounds very useful. I'm just seeing the background. How do I get it to show test results?
Oh, this may be the board that needs outside Vdd help to hit >335 MHz...
Comments
I did a bit more experimenting around this recently. To make pin input sampling timing at sysclock/1, and maybe helpful at sysclock/2 as well, reliable above 60 MHz I found a combination of toggling Data-Registered(Sync) and Data-Schmitt were excellent companions for effecting a sub-sysclock delay-line - https://forums.parallax.com/discussion/comment/1561512/#Comment_1561512 Clock pin is best left unregistered.
I think I could add schmitt mode as a flag - does it mess up the output drive in any way? Because currently all the pin modes are just set once on startup and I'd like to keep that.
Also oomf the misoyume ZIP i posted to make it easier to find just got paginated off again.
It's just a pin input modifier.
However, the whole situation is temperature dependant so you kind of want to dynamically adjust as it warms up. It's also board design dependant, so it needs to at least run-time calibrate at boot as a minimum. ie: Ditch those constants.
The 4bit SD driver does the dynamic recalibration, although, since it is not using sysclock/1 transfers, it doesn't to try to calibrate for sub-sysclock delays.
That sounds like pain. As-is configuring the constants on a per-board basis for sys/2 or sys/3 has worked fine. Auto-calibrating it on boot only is a bad and terrible idea as it might find a setting that is almost-but-not-quite reliable. And re-calibrating dynamically - no time/space for that.
Oh, that's not so bad, I had thought fast mode was sysclock/1. EDIT: Duh, of course, it's not DDR.
That can be reliable. Just needs some attention.
That's fair.
NeoYume ran overnight and to now with no fan and still good. Thermals are definitely better on this new board.
I'll try misoyume beta06 now...
Ok, misoyume running! We'll see how long can go without fan...
At first it didn't. Then, remembered how lost a day trying to get MegaYume running. Nothing was working. Tried about 4 versions of MegaYume and 4 versions of Flexprop in various combinations and nothing.
Finally realized that somehow the ROM files got corrupted and all showed up as 32 kB, obviously wrong.
Same thing happened here, 32 kB. No idea how or why this happened...
MisoYume died while typing this. Guess this is the point where a fan is needed. Will try with that now for a while...
What is the clock freq here? Think MegaYume is 325 MHz and NeoYume is 345 MHz, right?
MegaYume (video-nextgen branch): ~322 MHz
NeoYume: ~338 MHz
MisoYume: ~344 MHz
The current master of MegaYume will run slightly different clocks depending on video mode. I still have to fix interlacing before I can merge video-nextgen into master. The progression in clock speed is not just for fun, there are codepaths that just barely fit in. I spent a lot of time squeezing down the video code in MisoYume and it still needs really high speed to fit in all cases.
Might need to unmount the SD card before pulling it from the PC. Normally that shouldn't be needed (all writes flush as soon as possible), but who knows what's going on. 32kB sounds exactly like one cluster.
I've created a git for MisoYume. It's just the same old beta06 code, but now version-controlled and easy to find: https://github.com/IRQsome/MisoYume
Just released NeoYume 1.4-RC2.
Compared to 1.4-RC1:
- Slightly increase ROM loading speed
- Enable P_SYNC_IO for HDMI pins (fixes signal quality malarkey on some setups)
- update to usbnew 1.1.6 (should not matter)
New silly program: RAM tester.
Takes a NeoYume config file and just keeps testing the PSRAM (read and write). Reports errors on a per-chip basis.
Pictured: @MXX gaming board, settings as displayed. Chip on lane 1, bank 5 (i.e. the high nibble of the last 16MB) fails pretty much instantly. These settings appear to work fine-ish because to see this issue in NeoYume itself, you'd need to play a very large game and have the corruption happen to a BIOS code fetch (regular code ROMs load into a different bank). Note that there is a better setting on this board: 15,sync,async. Failure shown for illustration purposes.
Still need to add HyperRAM support and make sure it works on all configurations.
Nice one. I like how it identifies and displays the failing bank and 4 bit lane. Could be useful in case of a bad PSRAM device affecting everything. Might be good to eventually have a way to auto-iterate through different settings to find a good one too. You might be able to go down to single bit level as well in case there is a bad wire, although in that case it's likely that the read/write commands themselves won't be correctly recognized by the PSRAM so nothing will come back at all.
Could be very helpful.
Btw: wish Chip’s driver had these delay and sync options…
It looks like all that's needed is to tweak the
+ 23ofcmdnibncombined with toggle of pin registering.PS: Only supporting sysclock/2 transfer rate sure simplifies the code. It's impressive how small that driver is.
Program inspires confidence
I forgot the PSRAMs need initialization, so need to add that so it can work from a cold start.
Though it appears to be possible to init a chip by accident (I guess if the data bus lines up just right to enable quad mode?)
So here it is.
Short overview:
RAM is tested using a sequence of 7 block patterns. The length of the test pattern depends on the bus width, so that it always takes 256 transfer cycles.
(Because usual RAM sizes are not divisible by 7, each RAM block should get each pattern once after 7 iterations)
Some interesting findings so far:
Oh no, it seems some more advanced skulduggery is afoot. After realizing what a difference those dummy cogs made, I realized I never tested it with those present on the MXX board and there tragedy struck: With dummy cogs, the 15,sync,async setting is no longer stable (and starts failing on the low-numbered banks! argh!). Interestingly, the 17,sync,sync slow setting is also not stable anymore on this (16, async, async seems fine?).
I may have created a monster I can't control. Or rather, the benchmark for new boards to beat.
Also, there's still that idea of using schmitt mode as an extra adjustment. I'm also not 100% sure if all the combinations of clock/data sync are really useful. Some might cause issues during write?
With all the different combinations in use with the clock as well it starts to complicate the code. I had that issue with the HyperRAM driver and had to do all sorts of tricks to add different clocks delays in different places. ie. the exact same code doesn't work with different pin settings.
Schmitt seems to not really help much at all. Maybe same issue where it messes up the writes.
But here's where I'm going ＭＥＮＴＡＬ: I think it's the fricking USB cables.
So backstory, I have two USB to barrel jack adapters. One of them is evil in some ineffable way and tends to cause things to not to work. At some point I misplaced the good one, so today I tried to run the EDGE off the evil one, which lead to many fails (I had to disconnect either the fan or the LCD that I had attached to get it to boot at all and even then the RAM test would have fails). Then I remembered that old tale of the two cables and went to find the good one (which I seem to have left laying around after some experiment measuring mains voltage leakage on various power supplies). That fixed the EDGE and made it pass the RAM test with both LCD and fan still attached (in being derived from NeoVGA, the test output can even be on the LCD!)
So, the MXX board. I just received it like yesterday and I just quickly wanted to test it. It uses a full-size B connector, so I grabbed the first thing I had for that, which is some super thin retractable thing. That worked fine. Until I just tried running the final version of the RAM test (with dummy cogs) - fails where there previously weren't any. And now guess what - after I grabbed a proper nice USB cable, the fails are gone again!!!!!
I feel like I need to repent and start apologizing for making fun of audiofools for buying low-oxygen platinum-plated 10000$ cables now.
(In all of these cases, it's connecting to the same USB port on my PC - despite my own recommendations, I often run the EVAL off of just that, too, no aux power. I guess these new-style 3.1 kinda ports have enough juice in them?)
(also, interesting how the crappy barrel cable is somehow worse than the super-thin retractable USB cable)
Ada good that you found/remembered that.
If you get a chance could you do us all a favor and measure what "5V" signal reaches the boards with the crappy cables? ie is it 4.5 volts? 4 volts? etc (when running your test code)
Might have to wait for after the weekend on that.
Relatedly, MXX board running off good cable:
Notice "First fail: 08:19:15". That seems a bit odd that it'd run for 8 hours and then fail a few minutes before I come down to check it. Maybe someone turned on the toaster or something and that got it?
(Also the heatspreader is incredibly hot)
Well, preliminary result with the following caveats: a) measured from USB port VBUS b) using a crappy USB power meter that's partially broken c) running NeoYume and not the RAM tester because the latter doesn't turn VBUS on on the MXX board.
*: Connected to the end of a good cable with a bunch of adapters. This is how I had it initially.
**: Probably came with a Galaxy S5 or something of that vintage. "5.3V 2A". It really is 5.3V without a load.
So there seems to be an issue with using a charger that causes it to not power on at all (no LEDs). I also tried some others, but they're not of note. There's also a barrel input on this board. There's a "K7805-3AR3" regulator in there, which allegedly wants a 24V DC input. The Rayslogic boards also have one. Need to dig out a supply for that. Lots of things to test. All of that and more will have to wait till sunday evening or monday though.
tl;dr; crappy cables drop 5V rail to dubious levels, though even the good cable isn't much better. Using 12/24V supply might lead to better results. Should also try the 5V supply from a powered hub.
Thanks Ada that helps. I'm going to measure this from now on too, because I've struck similar issues with dodgy cables in the past
Please note the "K7805-3AR3" regulator is wide input and accepts from 8VDC to 36VDC, BTW Burning Test is looking great !!!!!
PS
I'm working on the PCB to try improve PSRAM connections
@Wuerfel_21 Think usually try to write "6-9 VDC" next to barrel connector for the 7805.
24 VDC might make it explode...
@Wuerfel_21 Memory tester sounds very useful. I'm just seeing the background. How do I get it to show test results?
Oh, this may be the board that needs outside Vdd help to hit >335 MHz...
Does this only run at NeoYume freq?
Ok, it's all good with Platform Rev.A2 with Vdd supplied by Rev.A4's Eval style Vdd supply set to 2.0 V.
Gone 8 minutes now with no errors.
Might need a fan eventually though.
Maybe I'll let it go a while.
But, sounds like this isn't as stressful (i.e., power consuming) as the actual NeoYume, right?
over 20 minutes now with no fan and no failure, guess call that a success.
Guess I'll see if can change clock freq myself (guessing not).