massi has quit [Remote host closed the connection]
someone-else has quit [Quit: Ping timeout (120 seconds)]
someone-else has joined #scopehal
<electronic_eel>
azonenberg: you are planning to use the STM32F7 for your ethernet/ssh to serial converter, right?
<electronic_eel>
did you look at the errata sheet? when i considered using the F7 for an ethernet application, errata 2.17.6 "Ethernet erroneous data received in RMII configuration" spooked me
<electronic_eel>
it seems to me that this basically means that in RMII mode sometimes the MAC receives garbage and you have to try to detect that state and reset
<electronic_eel>
i don't like that at all and i think it means one should use only MII with that chip
<electronic_eel>
the alternative i thought about was using the H7 series instead, they don't have this issue as far as i've seen
<electronic_eel>
there are some H7 chips available that are quite cheap because they don't have much integrated flash. but you can connect a cheap external spi flash easily.
<azonenberg>
electronic_eel: The issue is fixed in the Z silicon revision
<azonenberg>
I'm not using it for ethernet to serial per se, i'm running the CLI on the stm32 too
<azonenberg>
so it's going to be ssh in, spi/i2c/gpio management commands out
<azonenberg>
The board i'm using right now is the A silicon rev which is affected by the errata, all new shipments since 2019 or so should be Z
<azonenberg>
So for my initial dev platforms i'm going to implement a loopback test where the FPGA loops back the RMII data and I send a few pings and if one comes back bad i reset the MAC. gregdavill did this with PHY loopback and got good results
<azonenberg>
It's not garbage, it's single bit corruption
<electronic_eel>
ah, good to know that they fixed it. i didn't fully notice the table at the start where they list the revisions
<azonenberg>
see third octet of the dest mac address
<azonenberg>
33 33 00 -> 33 33 01
<azonenberg>
interestingly it's always that bit that i see corrupted on this board
<azonenberg>
LSB of the low byte on the third byte of the packet
<azonenberg>
of the LSB of the third byte*
<electronic_eel>
oh, so this issue already has bitten you
<azonenberg>
Yes
<azonenberg>
hence why i'm so familiar with the specifics of the errata :)
<azonenberg>
i looked it up while debugging the mac not seeing *any* frames early on
<electronic_eel>
i just saw STM32F777 in the checkin logs and remembered this issue
<azonenberg>
that was due to unrelated bugs in both my initialization code and the FPGA RMII bridge
<azonenberg>
but i knew about the errata before it hit so i expected it and was prepared
<azonenberg>
Greg had it too and like i said had good luck with the loopback approach
<azonenberg>
i dont even need loopback, i can just build a traffic generator into the FPGA
<azonenberg>
since i have a bridge there anyway
<azonenberg>
add a spi management command that sends all-zero frames on request (max sensitivity, since only 0->1 transitions are affected, 1->0 never happens with this bug)
<azonenberg>
Anyway, glscopeclient now has an RMII decode that i used to troubleshoot all of this lol
<electronic_eel>
do you think the bit that is affected depends on the exact chip?
<electronic_eel>
like they have a timing constraint violation and some chips miss the timing on some specific bits, while some others can handle it?
<azonenberg>
I have two integralsticks with stm32f777s and xc7a100t's
<azonenberg>
so we can find out soon
<bvernoux>
azonenberg, this errata is clearly a very bad ones
<bvernoux>
what a mess to manage that ...
<azonenberg>
I'm fairly sure it's related to the phase of the divider vs some internal logic
<bvernoux>
the best is maybe to use a new revision ;)
<azonenberg>
they assume the output of the divider is in phase but it's not
<azonenberg>
bvernoux: the new stm32f777's i ordered from digikey don't even have an ETA yet
<azonenberg>
at least the xilinx parts i ordered gave me dates in 2022
<bvernoux>
yes chip shortage is totally crazy pushed to end of 2022 now ...
<bvernoux>
some components have even ETA 2025 ...
<bvernoux>
even passive are affected now
<azonenberg>
the whole reason i'm working on the ssh and management CLI now is that it's work i can do with parts on hand
<azonenberg>
and not need to buy new components
<bvernoux>
yes I understand so there is no any choice as anyway good STM32F7 revision is not available (except maybe buying an eval board to desolder the STM32F7 and pray it has the revision which have the fi)
<bvernoux>
fix
<electronic_eel>
at least you can be sure that when you get some STM32F7 that they will be the new revision and not some old stock
<azonenberg>
lol yeah i'm sure all of the rev A have long since been snapped up
<azonenberg>
Nobody is sitting on old chip inventory in 2021
<electronic_eel>
i haven't checked F7, but i once saw an F4 offered for about 140 US$ per piece on LCSC...
<azonenberg>
o_O
<azonenberg>
bvernoux: also what do you think about my oscilloscope-and-signal-generator "VNA" idea?
<bvernoux>
it is a VNA with poor dynamic range
<bvernoux>
but depending on what you want to do it can be good enough
<bvernoux>
I'm waiting the price of ADL5960 ;)
<bvernoux>
will be a must have (even if the performance are not like 100Keuro 20GHz VNA) if it could cost less than 2KUSD
<bvernoux>
On my side I'm waiting InfiRay T3Pro Thermal Camera ;)
<electronic_eel>
wouldn't a signal-gen+spectrum analyzer be more useful for a makeshift VNA?
<bvernoux>
But it is a real mess with DHL I have already paid the VAT and they want I pay again ...
<electronic_eel>
there would need to be some external reflection bridge and some external rf switches. only difficult question i see is how to get phase information. maybe with an external mixer that mixes the signal coming from the siggen and the signal coming from the port of interest?
<bvernoux>
yes at the end SigGen+SA+Reflection Bridges it is a big mess ;)
<azonenberg>
electronic_eel: yeah phase is the hard part
<azonenberg>
The point is that i dont have a specan
<azonenberg>
i'm about to buy the signal generator
<azonenberg>
the goal isnt to make an awesome VN
<azonenberg>
VNA*
<azonenberg>
It's to make a hopefully-good-enough VNA with stuff i mostly have around the lab already
<azonenberg>
I just need enough dynamic range for de-embedding cables on the scope
<azonenberg>
that's my main use case
<azonenberg>
Without using any doublers, the SSG5060X-V will let me do sweeps from 9 kH to 6 GHz
<azonenberg>
The PicoVNA only goes down to 300 kHz so the low freq range will be nice to have. But more importantly since the range mostly overlaps
<azonenberg>
i can measure the same DUT using both instruments
<azonenberg>
and compare the resulting data to see how well my setup agrees
<azonenberg>
Which will be good to ground truth my experiments before i scale up to something new
<azonenberg>
Then for higher BW i can use my SMA test board and see how well my data matches up with with measurements that Derek took
<azonenberg>
although that will be somewhat impacted by the fact that we tested different physical pcbs so there's unit to unit soldering/assembly variation to contend with