G
Guest
Hello, I've been working with the Siemens/Infineon PEB20534 chip and I
have found many apparent bugs not mentioned in the errata. I am
listing them here below for reference. Note that these are just my
notes, and they are chaotic and generally unorganised - it works for me
because I don't read them, just grep them. I am posting them in hopes
they may be useful to someone else. Note also that these are
suspicious behaviours I observed at one time or another, and any of my
observations may turn out to be incorrect. I stopped making attempts
to report to Siemens, because generally they do not seem to care to fix
this chip. I simply avoid situations described here if I can, and if
not at least I know what kind of problem can potentially happen.
Enjoy.
Mark Galeck
-----------------------------------------------
I configure the PEB 20534 for General Purpose Port (binary 100 to
GMODE.PERCFG ).
I then configure GPDIR for all outputs and write some data to GPDATA.
I then configure GPDIR for all inputs and drive the pins from the
outside of the chip to standard logic 1. Each pin is driven from 5V
power supply through a 10Kohms resistor.
BUG: when I then read GPDATA, I expect all inputs to be logic 1. They
are not - bits GP3, 7, 11, 15 are equal to what I last wrote to them
while in output mode, so if I wrote 0, they are 0.
We suspect there is either:
a timing problem on the chip, where one has to wait a certain amount
of time after GPDIR is switched to inputs, before GPDATA input data is
valid, or
A latching problem, where one has to read GPDATA a certain number of
times first and discard the results, before there is a valid read
--------------------------------------------
According to Errata 5, the RDR command will cause the ERR interrupt.
However, we observe that in addition to the ERR bit set, the RX DMA
interrupt vector also has FI bit set, if FI interrupt generation is
enabled for that channel with bit MRFI 0 and where there is no
reception going on whatsoever.
According to the manual:
"FI='1' indicates, that a frame has been received completely or was
stopped by a DMAC receiver reset command or a hold condition set in a
receive descriptor."
So, clearly, if there is no reception going on at all, the FI bit
should not be set. Probably the manual needs to be clarified that FI
will always happen on RDR.
------------------------------------------------
The ITF is not working properly.
Setup: 4 channels on the chip looped back 1-2, 3-4 through a RS-422
physical interface
The following testing function is executed repeatedly in a loop. The
function is composed of 3 simpler functions: 1. Initialize chip 2.
Transmit synchronously 1 frame (use ITF bit) and verify the received
data 3. Reset (not all reset is performed here, but only some
necessary steps, see details below)
There are 2 kinds of symptoms. One of them happens usually after
several executions of the function. Without the ITF bit, the function
executes in a continous loop without any problems.
Problems:
1. The received data is corrupted. More precisely, first some garbage
data is received, about 30 bytes, then the contents of the transmitted
data are received (which is 255 bytes). That is, one frame is
received, but it is longer, and the first about 30 bytes are garbage.
Or, 2. The system hangs (as if DMA controller malfunctioned and
overwrote system memory).
More details:
Register dump after initialization, similar for all channels:
GCMDR=300200,GSTAR=0,GMODE=C0000,GPDIR=FFFF,GPDATA=AAAA,GPIM=FFFF
DMAC: FIFOCR1=318C3000,FIFOCR2=108410AA,FIFOCR3=E,FIFOCR4=5050505
Port 0 DMAC: CFG=5000000
RxDesc
WORD1=21000000,Comp=0,
TxDesc:Info=C0FF0000,Comp=0
Port 0: STAR = 1080000,CCR0 = 80000030,_CCR1 = 2488000,_CCR2 = 8040008
Port 0: ACCM = 0,UDAC = 7E7E7E7E,TTSA = 0,RTSA = 0 Port 0: PMCT =
0,PMCR = 0,BRR = 7,TIMR = 0 Port 0: XADR = 0,RADR = 0,RAMR = 0,RLCR =
0 Port 0: XNXR = 0,TCR = 0,TICR = 0,SYNR = 0 Port 0: IMR =
FFFFFFFF,ISR = 0 Port 1: STAR = 1000000 Port 2: STAR = 1080000 Port 3:
STAR = 1000000
The oscillator used is 14745600Hz, so that the baud rate is 1843200Hz
with the above register values. The transmit clock of each channel is
exported and given as the receive clock of the partner channel.
RX and TX descriptors are chained in rings, but a hold bit is used in
each descriptor. The buffer length of each descriptor is 256, and each
buffer contains one frame. The frame length is 255 bytes , so that I
expect the status byte will be added and the resulting frame will fill
one RX descriptor, if the first RX descriptor buffer is filled
completely before proceeding to second. The TX FI interrupt is
disabled and the RX is enabled. Every descriptor has FI bit set. The
descriptors are set up, and the IDT command is issued to transmit one
frame. I wait until the interrupt comes and the first frame is
received.
The reset step merely issues RDR, which is necessary due to an item in
Errata 5, and powers down the chip (PU bit down).
--------------------------------------------------
The following function is executed in the continuous loop. The
function consists of 4 steps. The first 3 steps are as in bug above
(but there is no ITF bit, so that bug above does not happen).
Step 4 is: power up (PU bit up), then bits SM(1:0) of CCR0 are set to
ASYNC. Then based on manual recommendation, the receiver is disabled
(RAC bit), XRES and RRES are issued, and received is enabled.
The function then executes again from step 1, which means the SYNC mode
is initialized.
Without step 4, the function executes in a loop without any problems.
However, with step 4 added, even though I follow all the recommendation
for switching modes, the loop hangs the system after several
iterations. Note that I don't even transmit any data in ASYNC; it is
simply a bit switch to ASYNC (and then back to SYNC again during SYNC
init). This causes failure after several iterations. It looks like
one should not switch between SYNC and ASYNC without cold reboot (but
this would make it impossible to set ASYNC mode, since SYNC mode is
default at cold reset).
-------------------------------------
The setup is as in ITF bug above, but without the ITF bit (so that the
ITF bug above does not happen). However, if I set the BCR bit, again I
have a system failure after several iterations. The BCR bit should be
ignored in SYNC mode according to the manual, so I can have it set and
nothing bad should happen.
----------------------
This chip can send continuous logical 1's or flags, in between frames
in synchronous mode, and it can increase efficiency by combining
closing with opening flag of a next frame if it is immediately
available. . However, on reception, it suppport this "shared flags"
feature automatically. This means that on reception, it cannot accept
continuous logical 1's between frames, even if it can transmit such
things (because it won't know if this is a frame).
-------------------------
At RX init in HDLC mode, a spurious frame may be received (even though
the transmitter did not transmit anythign) - it looks like an aborted
frame, with status byte RSTA RAB bit set. One should discard such a
frame.
-------------------------
In the chip manual "start of operation" recommendation, they say to
keep RAC inactive while doing IDR. Even if no data is coming, it
seems that the DMA receiver may dump a spurious frame while doing IDR,
if RAC is active. It does not make sense, but that is the way it
seems. . So follow the recommendation, even if no data is coming.
--------------------------------
Chip manual says, in section 9.3, that upon AR, "if enabled, INT signal
is activated and DMAC stores the corresponding interrupt vector...".
This does not always work: Do not try to issue the command bit
CFGIQCFG and enable CFG interrupt vector by setting IMAR to 0. Think
about it. The chip may transfer the interrupt vector to the queue
whose base is being configured. You don't know for sure the latter
happens first. In fact, I saw system crash when I was trying to do
this - not always, sometimes it works fine.
-------------------------------
TX ERR interrupt on descriptors with HOLD = 1, FE = 0, NO = 0, does
not seem to be working - the interrupt does not appear.
-----------------------------
It may not be a good idea to change TX FIFO size for one channel while
another channel is transmitting. So, may be the best thing is to
decide ahead of time, at init time for all channels, on the FIFO sizes
for them, and then do not change them.
----------------------------
It may not be a good idea to set the TX FIFO size to 0 for a channel,
then try to IDT on a dummy descriptor with NO = 0. Even though the
channel is not transmitting anything, so the channel transmitter is
"not used", it may still cause problems if TX FIFO size is 0.
---------------------
When IDT is isssued but at the time SCC does not have TX clock, and
later TX clock is provided, garbage may spew out on TxD. So, cut off
TxD from the beginning and cut off TxC from the outside world at init,
but provide clock when issuing IDT, even internal clock.
DMAC uses PCI clocking domain, and SCC uses oscillator or external
clock at a specific baud rate. Even so, a change in one of these
clocks may confuse the other part, because they interract where the 2
clock domains meet. So, any change in SCC clock, should be done at
DMAC reset for that channel.
------------------
In SCC clock mode 0b, no TOE, and similar, we expect the chip to
ignore the TxC pin. Not so - if that pin is driven from the outside,
the chip gets confused.
-----------------
RDR and RDT commands may null the previous value in the BRDA, resp.
BTDA registers
-----------------------
The manual says that RX DMAC ERR interrupt will be generated if already
started DMA transfer is interrupted by RDR. But, this may also happen
if we just did IDR but no data is coming yet. Still, RDR may generate
ERR then.
------------------------
In case of RX DMAC ERR interrupt, it is difficult to catch it in the
ISR, because the GSTAR indication is the same as for ordinary RX DMAC
interrupts, and the interrupt queue is circular and we cannot prevent
the hardware from overwriting it if ISR is too late coming. So, one
way to catch this ERR interrupt, is that apparently, it results in a
complete RX descrip but with 0 bytes received.
However, a strange thing is that we also get a FE assert, but no RSTA
byte.
------------------------
After following the next descriptor pointer field from a TX descriptor
to the next descriptor to be transmitted, the chip may apparently clean
(put zeros) in hte next descriptor pointer field. This is done even
though the manual says this field is written by the CPU . Beware. and
not by DSCC4.
------------
Don't try to do reset in the direction that is actively moving data.
For example, do not do RRES while receiving. If you do, a part of a
frame might be discarded, such as the closing HDLC flag, and the
hardware might get confused between in-frame and interframe fill and
never receive anything anymore (hang).
-------------
DSCC4 DMAC does not write DWORD4 in RX descriptors after setting RBDA
and receiving IDR command. Even though CPU is not supposed to write
there, it has to zero it, if DWORD4 will be checked prior to this
descriptor ending receiving data. Same for DWORD5.
------------
The IMAR bit in GCMDR: only if 0, completion of AR does generate an
interrupt. However, one of ARACK, ARF bits in GSTAR is always
generated on completion of AR.
--------------------
While the AR request in GCMDR is in progress (until the finishing
interrupt is issued or ARACK or ARF is flagged), do not write more AR
commands to GCMDR or CHiCFG. It is not clear how the chip would
behave, and I seem to have seen malfunction here.
-------------------
If a channel on PEB20534 is not connected: the receive and/or clock
lines are floating, the channel may receive spurious data. To prevent
that, disable RAC in CCR2 for disconnected channels.
--------------------------------------------
The threshold in FIFOCR3 - in SYNC mode and in ASYNC mode where there
is no receive timeout or termination character, if the threshold is
more than 0, there is nothing in the manual that says data has to be
moved to host memory at all! Especially in SYNC mode it appears that
the complete frames are always eventually moved, regardless of the
threshold, but there is apparently nothing in the manual that says it
has to be so. So, it appears that the safe thing to do is to set this
threshold to 0.
-------------------------------------------
In the register CCR2, field RFTH, it is not clear whether the threshold
has to be exceeded or merely achieved, for the request transfer to take
place. We observed unusual behaviour here, so do not assume it is
enough to achieve the threshold. In particular, if you set threshold
to 1d, it is not guaranteed the transfer will take place immediately
after at least one character. To ensure transfer, therefore, it is
best to use a block end indication - termination character or the time
out set (TOLEN and TOIE in CCR1 reg).
----------------------------------------
Do not use CCR2 field RFTH settings of 4 or less bytes. They may not
work (this is not known for sure, so do not bother Infineon support).
Also values 32d or 60d don't work for sure - I have observed situations
where they fail - cause data corruption.
-----------------------------------------
Apparently, the IDT command executed for the first time may not work.
The action request indication is completed successfully, but the
descriptors are not marked as complete. When that happens, I find that
what helps is to do this sequence:
IDT channel 0
reset TX DMA channel 0
IDT channel 1
reset TX DMA channel 1
IDT channel 2
reset TX DMA channel 2
IDT channel 3
reset TX DMA channel 3
(some of the above may not succeed, even if they are done for a dummy
descriptor with a HOLD bit, the chip does not really get into the hold
mode)
IDT channel 0
IDT channel 1
IDT channel 2
IDT channel 3
(these IDTs do succeed)
Specifically, it happens for me with the first IDTs for the first two
channels, with either the dummy descriptor (FE = 0 and HOLD bit) - I
cannot do TXPR afterwards, or with a real descriptor chain: 2
descriptors, each with 2 data bytes, second with HOLD, FE, but none
with HI
------------------------------------------
According to errata 3.3.1, if a clock signal is not generated
internally, it must be provided externally for a XRES or RRES command
to indicate its completion. However, in ASYNC mode, even if clock mode
is configured to be exported, it may not be (since it is ASYNC mode).
So if you wire channels clocks of PE?20534 to each other, you may not
be able to do XRES or RRES on a channel, if that channel gets a clock
from another channel, that exports it but is configured to ASYNC.
-----------------------------
The TX FIFO size values for FIFOCR1 register, should not be 0 even for
channels that are not transmitting. We have seen bad things happen
with that. In fact, due to the fact, that these values need to be at
least 3 more than one of the thresholds, and divisible by 4, have them
at least 4.
And, if you do use the channel for transmission, be generous: at least
20 is a good value. Don't do less than that or you are asking for
trouble - remember this is a buggy chip - I have seen trouble happen
when I (erroneously) set the value too low, which should have still
been fine though, theoretically.
---------------------------------
When switching from ASYNC to SYNC in CCR0, first, set CCR1 to not
auto-mode. It is not well explained in the manual, but this chip does
not like switching from ASYNC to SYNC in automode.
-----------------------------------------------
A frequent "gotcha" in this chip, is the requirement that CTS in signal
be supplied low, in the default configuration, for the transmission to
take place. This is the default setting of FCTS field of CCR1.
-------------------------------
CCR0 register bit BCR should be ignored in SYNC mode, but when 1 it
causes problems when in HDLC mode. Set to 0.
--------------------------------
There is an Infineon Errata item that says, the IDT commands must be
executed "for the first time" in specific order. Does this mean the
specific order of IDT's must be only enforced the first time IDT's are
executed and then later you can execute them in any order you want? Or
does "for the first time" merely restate the fact that IDTs are
initialization commands? It is not clear, for me (Mark) and Luca
Marcchi.
He corresponded with Siemens on this and they clarified that you have
do IDT in the specific order, only the first time they are called (So
this would allow one to use IDT with LTDA transmit mode. )
However, I found that if I do IDTs in the specific order, reset (you
have to do reset after IDT before you can do IDT again) and then do IDT
in different order, I haveconfusion on the chip and failures, if the
IDTs are done in certain specific timing intervals. (This was done in
HOLD mode, but there is nothing specific in IDTs to HOLD mode and not
LTDA).
I forwarded the failures to Germany and suggested that maybe indeed
"for the first time" phrase in the Errata is meaningless, and really
IDTs can never be executed in different order than the one specified in
the Errata. They reaffirmed that no, one should be able to do IDTs
after resets, in any order, and the bug I found has origin elsewhere.
have found many apparent bugs not mentioned in the errata. I am
listing them here below for reference. Note that these are just my
notes, and they are chaotic and generally unorganised - it works for me
because I don't read them, just grep them. I am posting them in hopes
they may be useful to someone else. Note also that these are
suspicious behaviours I observed at one time or another, and any of my
observations may turn out to be incorrect. I stopped making attempts
to report to Siemens, because generally they do not seem to care to fix
this chip. I simply avoid situations described here if I can, and if
not at least I know what kind of problem can potentially happen.
Enjoy.
Mark Galeck
-----------------------------------------------
I configure the PEB 20534 for General Purpose Port (binary 100 to
GMODE.PERCFG ).
I then configure GPDIR for all outputs and write some data to GPDATA.
I then configure GPDIR for all inputs and drive the pins from the
outside of the chip to standard logic 1. Each pin is driven from 5V
power supply through a 10Kohms resistor.
BUG: when I then read GPDATA, I expect all inputs to be logic 1. They
are not - bits GP3, 7, 11, 15 are equal to what I last wrote to them
while in output mode, so if I wrote 0, they are 0.
We suspect there is either:
a timing problem on the chip, where one has to wait a certain amount
of time after GPDIR is switched to inputs, before GPDATA input data is
valid, or
A latching problem, where one has to read GPDATA a certain number of
times first and discard the results, before there is a valid read
--------------------------------------------
According to Errata 5, the RDR command will cause the ERR interrupt.
However, we observe that in addition to the ERR bit set, the RX DMA
interrupt vector also has FI bit set, if FI interrupt generation is
enabled for that channel with bit MRFI 0 and where there is no
reception going on whatsoever.
According to the manual:
"FI='1' indicates, that a frame has been received completely or was
stopped by a DMAC receiver reset command or a hold condition set in a
receive descriptor."
So, clearly, if there is no reception going on at all, the FI bit
should not be set. Probably the manual needs to be clarified that FI
will always happen on RDR.
------------------------------------------------
The ITF is not working properly.
Setup: 4 channels on the chip looped back 1-2, 3-4 through a RS-422
physical interface
The following testing function is executed repeatedly in a loop. The
function is composed of 3 simpler functions: 1. Initialize chip 2.
Transmit synchronously 1 frame (use ITF bit) and verify the received
data 3. Reset (not all reset is performed here, but only some
necessary steps, see details below)
There are 2 kinds of symptoms. One of them happens usually after
several executions of the function. Without the ITF bit, the function
executes in a continous loop without any problems.
Problems:
1. The received data is corrupted. More precisely, first some garbage
data is received, about 30 bytes, then the contents of the transmitted
data are received (which is 255 bytes). That is, one frame is
received, but it is longer, and the first about 30 bytes are garbage.
Or, 2. The system hangs (as if DMA controller malfunctioned and
overwrote system memory).
More details:
Register dump after initialization, similar for all channels:
GCMDR=300200,GSTAR=0,GMODE=C0000,GPDIR=FFFF,GPDATA=AAAA,GPIM=FFFF
DMAC: FIFOCR1=318C3000,FIFOCR2=108410AA,FIFOCR3=E,FIFOCR4=5050505
Port 0 DMAC: CFG=5000000
RxDesc
WORD1=21000000,Comp=0,TxDesc:Info=C0FF0000,Comp=0
Port 0: STAR = 1080000,CCR0 = 80000030,_CCR1 = 2488000,_CCR2 = 8040008
Port 0: ACCM = 0,UDAC = 7E7E7E7E,TTSA = 0,RTSA = 0 Port 0: PMCT =
0,PMCR = 0,BRR = 7,TIMR = 0 Port 0: XADR = 0,RADR = 0,RAMR = 0,RLCR =
0 Port 0: XNXR = 0,TCR = 0,TICR = 0,SYNR = 0 Port 0: IMR =
FFFFFFFF,ISR = 0 Port 1: STAR = 1000000 Port 2: STAR = 1080000 Port 3:
STAR = 1000000
The oscillator used is 14745600Hz, so that the baud rate is 1843200Hz
with the above register values. The transmit clock of each channel is
exported and given as the receive clock of the partner channel.
RX and TX descriptors are chained in rings, but a hold bit is used in
each descriptor. The buffer length of each descriptor is 256, and each
buffer contains one frame. The frame length is 255 bytes , so that I
expect the status byte will be added and the resulting frame will fill
one RX descriptor, if the first RX descriptor buffer is filled
completely before proceeding to second. The TX FI interrupt is
disabled and the RX is enabled. Every descriptor has FI bit set. The
descriptors are set up, and the IDT command is issued to transmit one
frame. I wait until the interrupt comes and the first frame is
received.
The reset step merely issues RDR, which is necessary due to an item in
Errata 5, and powers down the chip (PU bit down).
--------------------------------------------------
The following function is executed in the continuous loop. The
function consists of 4 steps. The first 3 steps are as in bug above
(but there is no ITF bit, so that bug above does not happen).
Step 4 is: power up (PU bit up), then bits SM(1:0) of CCR0 are set to
ASYNC. Then based on manual recommendation, the receiver is disabled
(RAC bit), XRES and RRES are issued, and received is enabled.
The function then executes again from step 1, which means the SYNC mode
is initialized.
Without step 4, the function executes in a loop without any problems.
However, with step 4 added, even though I follow all the recommendation
for switching modes, the loop hangs the system after several
iterations. Note that I don't even transmit any data in ASYNC; it is
simply a bit switch to ASYNC (and then back to SYNC again during SYNC
init). This causes failure after several iterations. It looks like
one should not switch between SYNC and ASYNC without cold reboot (but
this would make it impossible to set ASYNC mode, since SYNC mode is
default at cold reset).
-------------------------------------
The setup is as in ITF bug above, but without the ITF bit (so that the
ITF bug above does not happen). However, if I set the BCR bit, again I
have a system failure after several iterations. The BCR bit should be
ignored in SYNC mode according to the manual, so I can have it set and
nothing bad should happen.
----------------------
This chip can send continuous logical 1's or flags, in between frames
in synchronous mode, and it can increase efficiency by combining
closing with opening flag of a next frame if it is immediately
available. . However, on reception, it suppport this "shared flags"
feature automatically. This means that on reception, it cannot accept
continuous logical 1's between frames, even if it can transmit such
things (because it won't know if this is a frame).
-------------------------
At RX init in HDLC mode, a spurious frame may be received (even though
the transmitter did not transmit anythign) - it looks like an aborted
frame, with status byte RSTA RAB bit set. One should discard such a
frame.
-------------------------
In the chip manual "start of operation" recommendation, they say to
keep RAC inactive while doing IDR. Even if no data is coming, it
seems that the DMA receiver may dump a spurious frame while doing IDR,
if RAC is active. It does not make sense, but that is the way it
seems. . So follow the recommendation, even if no data is coming.
--------------------------------
Chip manual says, in section 9.3, that upon AR, "if enabled, INT signal
is activated and DMAC stores the corresponding interrupt vector...".
This does not always work: Do not try to issue the command bit
CFGIQCFG and enable CFG interrupt vector by setting IMAR to 0. Think
about it. The chip may transfer the interrupt vector to the queue
whose base is being configured. You don't know for sure the latter
happens first. In fact, I saw system crash when I was trying to do
this - not always, sometimes it works fine.
-------------------------------
TX ERR interrupt on descriptors with HOLD = 1, FE = 0, NO = 0, does
not seem to be working - the interrupt does not appear.
-----------------------------
It may not be a good idea to change TX FIFO size for one channel while
another channel is transmitting. So, may be the best thing is to
decide ahead of time, at init time for all channels, on the FIFO sizes
for them, and then do not change them.
----------------------------
It may not be a good idea to set the TX FIFO size to 0 for a channel,
then try to IDT on a dummy descriptor with NO = 0. Even though the
channel is not transmitting anything, so the channel transmitter is
"not used", it may still cause problems if TX FIFO size is 0.
---------------------
When IDT is isssued but at the time SCC does not have TX clock, and
later TX clock is provided, garbage may spew out on TxD. So, cut off
TxD from the beginning and cut off TxC from the outside world at init,
but provide clock when issuing IDT, even internal clock.
DMAC uses PCI clocking domain, and SCC uses oscillator or external
clock at a specific baud rate. Even so, a change in one of these
clocks may confuse the other part, because they interract where the 2
clock domains meet. So, any change in SCC clock, should be done at
DMAC reset for that channel.
------------------
In SCC clock mode 0b, no TOE, and similar, we expect the chip to
ignore the TxC pin. Not so - if that pin is driven from the outside,
the chip gets confused.
-----------------
RDR and RDT commands may null the previous value in the BRDA, resp.
BTDA registers
-----------------------
The manual says that RX DMAC ERR interrupt will be generated if already
started DMA transfer is interrupted by RDR. But, this may also happen
if we just did IDR but no data is coming yet. Still, RDR may generate
ERR then.
------------------------
In case of RX DMAC ERR interrupt, it is difficult to catch it in the
ISR, because the GSTAR indication is the same as for ordinary RX DMAC
interrupts, and the interrupt queue is circular and we cannot prevent
the hardware from overwriting it if ISR is too late coming. So, one
way to catch this ERR interrupt, is that apparently, it results in a
complete RX descrip but with 0 bytes received.
However, a strange thing is that we also get a FE assert, but no RSTA
byte.
------------------------
After following the next descriptor pointer field from a TX descriptor
to the next descriptor to be transmitted, the chip may apparently clean
(put zeros) in hte next descriptor pointer field. This is done even
though the manual says this field is written by the CPU . Beware. and
not by DSCC4.
------------
Don't try to do reset in the direction that is actively moving data.
For example, do not do RRES while receiving. If you do, a part of a
frame might be discarded, such as the closing HDLC flag, and the
hardware might get confused between in-frame and interframe fill and
never receive anything anymore (hang).
-------------
DSCC4 DMAC does not write DWORD4 in RX descriptors after setting RBDA
and receiving IDR command. Even though CPU is not supposed to write
there, it has to zero it, if DWORD4 will be checked prior to this
descriptor ending receiving data. Same for DWORD5.
------------
The IMAR bit in GCMDR: only if 0, completion of AR does generate an
interrupt. However, one of ARACK, ARF bits in GSTAR is always
generated on completion of AR.
--------------------
While the AR request in GCMDR is in progress (until the finishing
interrupt is issued or ARACK or ARF is flagged), do not write more AR
commands to GCMDR or CHiCFG. It is not clear how the chip would
behave, and I seem to have seen malfunction here.
-------------------
If a channel on PEB20534 is not connected: the receive and/or clock
lines are floating, the channel may receive spurious data. To prevent
that, disable RAC in CCR2 for disconnected channels.
--------------------------------------------
The threshold in FIFOCR3 - in SYNC mode and in ASYNC mode where there
is no receive timeout or termination character, if the threshold is
more than 0, there is nothing in the manual that says data has to be
moved to host memory at all! Especially in SYNC mode it appears that
the complete frames are always eventually moved, regardless of the
threshold, but there is apparently nothing in the manual that says it
has to be so. So, it appears that the safe thing to do is to set this
threshold to 0.
-------------------------------------------
In the register CCR2, field RFTH, it is not clear whether the threshold
has to be exceeded or merely achieved, for the request transfer to take
place. We observed unusual behaviour here, so do not assume it is
enough to achieve the threshold. In particular, if you set threshold
to 1d, it is not guaranteed the transfer will take place immediately
after at least one character. To ensure transfer, therefore, it is
best to use a block end indication - termination character or the time
out set (TOLEN and TOIE in CCR1 reg).
----------------------------------------
Do not use CCR2 field RFTH settings of 4 or less bytes. They may not
work (this is not known for sure, so do not bother Infineon support).
Also values 32d or 60d don't work for sure - I have observed situations
where they fail - cause data corruption.
-----------------------------------------
Apparently, the IDT command executed for the first time may not work.
The action request indication is completed successfully, but the
descriptors are not marked as complete. When that happens, I find that
what helps is to do this sequence:
IDT channel 0
reset TX DMA channel 0
IDT channel 1
reset TX DMA channel 1
IDT channel 2
reset TX DMA channel 2
IDT channel 3
reset TX DMA channel 3
(some of the above may not succeed, even if they are done for a dummy
descriptor with a HOLD bit, the chip does not really get into the hold
mode)
IDT channel 0
IDT channel 1
IDT channel 2
IDT channel 3
(these IDTs do succeed)
Specifically, it happens for me with the first IDTs for the first two
channels, with either the dummy descriptor (FE = 0 and HOLD bit) - I
cannot do TXPR afterwards, or with a real descriptor chain: 2
descriptors, each with 2 data bytes, second with HOLD, FE, but none
with HI
------------------------------------------
According to errata 3.3.1, if a clock signal is not generated
internally, it must be provided externally for a XRES or RRES command
to indicate its completion. However, in ASYNC mode, even if clock mode
is configured to be exported, it may not be (since it is ASYNC mode).
So if you wire channels clocks of PE?20534 to each other, you may not
be able to do XRES or RRES on a channel, if that channel gets a clock
from another channel, that exports it but is configured to ASYNC.
-----------------------------
The TX FIFO size values for FIFOCR1 register, should not be 0 even for
channels that are not transmitting. We have seen bad things happen
with that. In fact, due to the fact, that these values need to be at
least 3 more than one of the thresholds, and divisible by 4, have them
at least 4.
And, if you do use the channel for transmission, be generous: at least
20 is a good value. Don't do less than that or you are asking for
trouble - remember this is a buggy chip - I have seen trouble happen
when I (erroneously) set the value too low, which should have still
been fine though, theoretically.
---------------------------------
When switching from ASYNC to SYNC in CCR0, first, set CCR1 to not
auto-mode. It is not well explained in the manual, but this chip does
not like switching from ASYNC to SYNC in automode.
-----------------------------------------------
A frequent "gotcha" in this chip, is the requirement that CTS in signal
be supplied low, in the default configuration, for the transmission to
take place. This is the default setting of FCTS field of CCR1.
-------------------------------
CCR0 register bit BCR should be ignored in SYNC mode, but when 1 it
causes problems when in HDLC mode. Set to 0.
--------------------------------
There is an Infineon Errata item that says, the IDT commands must be
executed "for the first time" in specific order. Does this mean the
specific order of IDT's must be only enforced the first time IDT's are
executed and then later you can execute them in any order you want? Or
does "for the first time" merely restate the fact that IDTs are
initialization commands? It is not clear, for me (Mark) and Luca
Marcchi.
He corresponded with Siemens on this and they clarified that you have
do IDT in the specific order, only the first time they are called (So
this would allow one to use IDT with LTDA transmit mode. )
However, I found that if I do IDTs in the specific order, reset (you
have to do reset after IDT before you can do IDT again) and then do IDT
in different order, I haveconfusion on the chip and failures, if the
IDTs are done in certain specific timing intervals. (This was done in
HOLD mode, but there is nothing specific in IDTs to HOLD mode and not
LTDA).
I forwarded the failures to Germany and suggested that maybe indeed
"for the first time" phrase in the Errata is meaningless, and really
IDTs can never be executed in different order than the one specified in
the Errata. They reaffirmed that no, one should be able to do IDTs
after resets, in any order, and the bug I found has origin elsewhere.
