If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
bugs on Siemens/Infineon PEB20534, PEF20534 chip
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,FIFOCR 4=5050505 Port 0 DMAC: CFG=5000000 RxDescWORD1=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. |
#2
|
|||
|
|||
bugs on Siemens/Infineon PEB20534, PEF20534 chip
In article .com,
wrote: 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. snip As a hardware guy, I'd start by looking to see if the Linux world has developed a driver for the hardware you want to use. If there are too many adverse comments about the device, don't touch it with a barge pole :-) http://www.cl.cam.ac.uk/Research/SRG...et/wan/dscc4.c Based on the comments in that driver, there is a suggestion the hardware cannot even be properly handled without rebooting the computer. That is a sad state of affairs, and I've be spinning another prototype circuit board with a competitor's part on it, at the hint of problems like that. If you are forced to deal with a large installed base in the field, you have my sympathies. Trying to build a working solution for trusting customers, based on a bad hardware choice, will never earn you any kudos where you work, but will be one of the hardest jobs you could pick to do. Paul |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
best skt 939 chip for overclock? not too much $$$$$ | Bitsbucket | Overclocking AMD Processors | 6 | November 19th 04 02:06 AM |
After flashing my BIOS to 1011, my MB is dead | Hello | Asus Motherboards | 11 | July 22nd 04 11:07 AM |
REQ Help: A7N8X Deluxe -- need to upgrade BIOS ... problem! | Samantha | Asus Motherboards | 3 | July 6th 04 08:28 PM |
Thermal Grease on Processor Chip | Peter | Homebuilt PC's | 5 | April 18th 04 12:33 AM |
Opteron Overclocking? | Adrian Richards | Overclocking AMD Processors | 9 | October 5th 03 03:20 PM |