There's only two places when the code will pulse nRST - so I agree this is v. fishy. The first is in the adapter probe, when it holds it active low for 100ms (not us). The second is in econet_adlc_cleardown(), which is used when the module things something has gone pretty catastrophically wrong and wants to do a wholesale reset. Again, it holds it low for 100ms. So, I don't reckon the software is deliberately generating these short pulses. Each would be accompanied by a messages in dmesg - either on module load, or when it decides to throw its toys out of the pram and start again.arg wrote: ↑Sun Sep 19, 2021 10:49 pmSomething fishy going on with nRST. It's pulsing low for only a very short time (below the resolution of the analyser to measure it properly, but about 100ns. I've found the datasheet limit now, and that's minimum 400ns. However this is extra odd in that software seems to be pressing on without doing any re-initialisation, and the hardware doesn't seem to mind much either, continuing to generate interrupts! So possibly this is a capture error and it's not actually being genuinely pulsed? However, we should look a little closer at this - the trace I looked at yesterday of the initial start-up seemed to have an illegal pulse width - suggest we need a decent delay when deliberately pulsing nRST.
I'm pretty sure the version @KenLowe is testing for these results already removed an extra read of SR2, because I went through and tinkered with that. Since I can't at present read the traces (software issues, not Ken's fault!), if they show two reads then I must have missed one!
I thought I'd got rid of the extra writes to CR2 as well - but will look for more... Whilst I've not quoted the observation before about a write to CR1 after receiving bytes, I thought I had ditched that too - I will look again when I get home.arg wrote: ↑Sun Sep 19, 2021 10:49 pm[*]However, this does highlight that the unnecessary writes of 0x65 to CR2 (clearing the Rx status) need to go: in some cases here, that write to CR2 occurs after nIRQ has already gone off signalling the next byte available - and if there was (for example) FV status in SR2 to go with that byte, the CR2 write will have silently cleared it.
Now this is the bit I wanted to understand. I think where you see a read of SR1 & SR2, the software actually thinks it's reading the FIFO, hence it's putting those bytes in its data packet storage and producing the dodgy packet that Ken has demonstrated (and I've seen a lot of on my Pi Zero). That is what makes me think something fruity is going on with the address bus, possibly bit 1 thereof - but not all the time. I get very similar behaviour on my Pi Zero - right number of bytes in the packet, but all look like status register content rather than data. It's almost as if A1 is not quite making it to the ADLC sometimes. One possibility is that something odd is being done in the userspace arena with the address lines, but on a different CPU core to the one handling the interrupt. Seems odd that we'd get a whole packet full of status register stuff though.arg wrote: ↑Sun Sep 19, 2021 10:49 pm...
And again 123400 to 142280. Around 140815 the level-triggered interrupt is doing its thing - failed to service the previous interrupt before the next one came along, but apparently no overflow. At 142215, things go wrong. SR1=0x81, SR2=0x80 as usual, then there's a pause of 6us when it would normally have done a read of the Rx data but nothing happens, followed by reading SR1/SR2 again (which haven't changed), finally the data is read and CR2 written as usual. The next interrupt then seems slow to service, but maybe the next action (at 142280us) isn't actually an interrupt service at all as it doesn't read SR1 - instead it writes CR2=0x65, CR1=0xe2, CR1=0x82 and all goes quiet for a while, with the end of the frame getting lost.
I will look again at the register writes on reception and see if I can find any more that want removing! Could have sworn I'd done it though, though this morning was littered with a constellation of unusual events which meant I had to work quicker than usual.