Seems like CPR/CPR2 does not affect baudrate, so maybe EFR bit 4 (enhance mode) is not set?
If CPR is stuck at 8 (1.0 scaling), it all makes sense, these corresponds to what the oscilloscope gives:
2400 -> tcr: 9, cpr: 18, quot: 1286
62500000/9/(8*.125)/1286 -> 5400
4800 -> tcr: 7, cpr: 23, quot: 647
2500000/7/(8*.125)/647 -> 13799
9600 -> tcr: 9, cpr: 9, quot: 643
62500000/9/(8*.125)/643 -> 10800.
19200 -> tcr: 8, cpr: 31, quot: 105
62500000/7/(8*.125)/105 -> 85034
38400 -> 62500000/14/(8*.125)/30 -> 148809
/Anders
On 2022-09-13 18:19, Maciej W. Rozycki wrote:
Hi Anders,
Sorry to cause you trouble.
I really don't know what to do here, sorry. Are you saying a specific
commit has broken this? If so, did you test if you made a change it
fixed the issue?
Yes, commit 366f6c955d4d1a5125ffcd6875ead26a3c7a2a1c broke the one to one
correspondence
between programmed and actual baudrate; reverting it (and
9c5c8aaed50bf3478073ab51b8b1f3f5327d3cfa
that builds on that patch) restores the expected functionality (i.e. you get
the baudrate you ask for)
on 5.19.8.
I have implemented the calculation using parameters from original OxSemi
datasheets and verified this code across three architectures available to
me (POWER9, RISC-V, 32-bit x86) and a couple of cards made by different
manufacturers connected to a non-OxSemi serial device each at the other
end. I have checked the usual baud rates of up to 460800bps. Higher baud
rates work too, though I could only try them between OxSemi devices, so
actual rates were not verified for correctness.
And offhand I can say it works just fine at 230400bps with 6.0.0-rc2 as
at commit 10d4879f9ef0 and my RISC-V machine (using an EXSYS EX-44171
1S+1P port PCIe option card, built around the OXPCIe952 too) talking to a
remote console server in my lab. I don't have an oscilloscope available
to check actual waveforms produced.
What do you suggest happen here?
Either there is a bug in the code, or the chipset on my card (a Delock 2xRS232
card) is not a true oxford
chipset (the package and PCI id's says that they are).
A bug can never be ruled out. I doubt that Delock would use a fake chip
or indeed that anyone would choose to clone an OxSemi part, which seems
fairly complex to me for a serial port.
Since the chip seems to be discontinued since 2014 (see
https://www.mouser.com/PCN/PLX_Technology_2013_8.pdf),
I think a revert would not be uncalled for.
The problem is the original calculation is inaccurate enough for the
serial interface not to communicate correctly at higher baud rates. I
found setting two stop bits while talking to a remote end that has one
stop bit set a possible workaround for some cases, but why not do the
calculation correctly in the first place?
If you're willing to debug it, then I'll be more than happy to supply you
with diagnostic patches, some of which I made in the development of the
fix. Also what processor architecture do you use the interface with?
Maciej
--
Anders Blomdell Email: anders.blomdell@xxxxxxxxxxxxxx
Department of Automatic Control
Lund University Phone: +46 46 222 4625
P.O. Box 118
SE-221 00 Lund, Sweden
