P32-P47 would be the best, with all trace lengths 1638 mils +- less than 1 mil.
then P0 to P32, then P16 to P25.
P16 to P25 are actually the shortest traces, but not matched in length to each other.
Similarly the top row are not matched either, apart from P62 (TX) and P63 (RX), which are both 1600 mils long!
P0 to P32 is interesting, as they are also matched to 1638 mils +-1 mil, but I think the slightly longer ground return path on that side of the board has an impact at the HyperRam data rates. I've made a note to look at that next time Eval is reviewed.
@deets said:
Ok, I just did that. I flipped the accessory boards around. The HyperRAM now has base 32 instead of base 0 on the P2 eval board. Holy 🐄! The data is coming through clean. @rogloh any thoughts?
@deets
If the timing of HyperRAM data bus clocking is wrong for your wiring setup and temperature/frequency, you could read data that is offset by a byte or so (eg. read too early from 1 get address 2 data, read from address 2 but get address 3 data etc). Could that cause your particular corruption pattern?
You can experiment with the timing in the driver by calling setDelay - can pass a delay varying from 0-15 (probably 7 onwards gets reasonable), and addr is any mapped address of the HyperRAM you've setup for the memory driver which in your case started here I think...
RAM = $10_000000
I believe you can call this memory.spin2 API dynamically after you've initialized/mapped the memory.
PUB setDelay(addr, delay) : r
if delay +> 15
return ERR_INVALID
r := modifyBankParams(addr, $FFFF0FFF, delay << 12)
I don't have a Rev C P2-EVAL board here to test (just RevB and A) so the default timing delay values in my driver might not be fully appropriate for the pins you had used with a Rev C P2-EVAL (and could easily differ if the path length is significantly different in various port A, B positions).
I know on the revB P2-EVAL board @evanh found that port A 16-31 was the best group to use for performance and limiting the data pin skew.
Also in the HyperRAM driver I think I probably supplied a demo called delaytest which scans through a frequency range and finds the working delay values that can be used. You could use that to check the delay values in different base pin positions...
@rogloh I'm happy to look a bit deeper, but I have only ever encountered problems when driving the SD-card in parallel. Which speaks for me to a crosstalk or some such issue, not a general timing one, as that should occur on both scenarios. Or do you think I'm off the mark here? My electronics-foo is early stages...
Roger is hoping to rule out timing. Or to solve it by tweaking a compensation for your setup. The delaytest will answer any concern over timing. The reason for needing the test is a twofold effect compounding onto read timing. One is just the sheer speed means timings are tight. The other is a complicated I/O latency in Prop2s that makes it tricky to predict tight timings accurately.
Yeah the SD linkage is a weird one @deets. I hope there is nothing in that code affecting pins it is not meant to be touching...? I can't imagine it should but you never know. I've not seen crosstalk issues with HyperRAM and video pins at high speed both being output by the P2. The only signal issue related stuff I had was that PLL jitter thing on P28-P31 when high speed PSRAM data was toggling pins fast there, but it looks like you're not using those pins so that shouldn't be it, you could maybe move the ADC as well to see if that affects anything.
Comments
P32-P47 would be the best, with all trace lengths 1638 mils +- less than 1 mil.
then P0 to P32, then P16 to P25.
P16 to P25 are actually the shortest traces, but not matched in length to each other.
Similarly the top row are not matched either, apart from P62 (TX) and P63 (RX), which are both 1600 mils long!
P0 to P32 is interesting, as they are also matched to 1638 mils +-1 mil, but I think the slightly longer ground return path on that side of the board has an impact at the HyperRam data rates. I've made a note to look at that next time Eval is reviewed.
@deets
If the timing of HyperRAM data bus clocking is wrong for your wiring setup and temperature/frequency, you could read data that is offset by a byte or so (eg. read too early from 1 get address 2 data, read from address 2 but get address 3 data etc). Could that cause your particular corruption pattern?
You can experiment with the timing in the driver by calling setDelay - can pass a delay varying from 0-15 (probably 7 onwards gets reasonable), and addr is any mapped address of the HyperRAM you've setup for the memory driver which in your case started here I think...
RAM = $10_000000
I believe you can call this memory.spin2 API dynamically after you've initialized/mapped the memory.
PUB setDelay(addr, delay) : r if delay +> 15 return ERR_INVALID r := modifyBankParams(addr, $FFFF0FFF, delay << 12)I don't have a Rev C P2-EVAL board here to test (just RevB and A) so the default timing delay values in my driver might not be fully appropriate for the pins you had used with a Rev C P2-EVAL (and could easily differ if the path length is significantly different in various port A, B positions).
I know on the revB P2-EVAL board @evanh found that port A 16-31 was the best group to use for performance and limiting the data pin skew.
Also in the HyperRAM driver I think I probably supplied a demo called delaytest which scans through a frequency range and finds the working delay values that can be used. You could use that to check the delay values in different base pin positions...
@rogloh I'm happy to look a bit deeper, but I have only ever encountered problems when driving the SD-card in parallel. Which speaks for me to a crosstalk or some such issue, not a general timing one, as that should occur on both scenarios. Or do you think I'm off the mark here? My electronics-foo is early stages...
Roger is hoping to rule out timing. Or to solve it by tweaking a compensation for your setup. The delaytest will answer any concern over timing. The reason for needing the test is a twofold effect compounding onto read timing. One is just the sheer speed means timings are tight. The other is a complicated I/O latency in Prop2s that makes it tricky to predict tight timings accurately.
Yeah the SD linkage is a weird one @deets. I hope there is nothing in that code affecting pins it is not meant to be touching...? I can't imagine it should but you never know. I've not seen crosstalk issues with HyperRAM and video pins at high speed both being output by the P2. The only signal issue related stuff I had was that PLL jitter thing on P28-P31 when high speed PSRAM data was toggling pins fast there, but it looks like you're not using those pins so that shouldn't be it, you could maybe move the ADC as well to see if that affects anything.