Hi Kris I didn't see that, but I had a lot of trouble using an 803 as a SPI slave, and still may not have it working right (I had to work on something else for a few weeks). First, I had no luck at all using the 803 as a Slave with CPHA=1, which is supposed to let you receive data while the /SS signal stays grounded. When I went to CPHA=0 (/SS must toggle between each character), I got some valid data. Then, I threw long delays between each character, and got better behavior. Then I had to work on other things before I could test if it was really reliable - I could get a screenful of data without obvious garbles, but that just means 99% or more correct. There were many flavors of bad data when things were not just right - bit shifts, lost chars and pure garbage. I think someone else reported seeing a few dozen good chars followed by a few dozen bit-shifted chars. I've heard people have good luck with the 80x as a SPI Master, and using it in polled mode, not interrupt-based. I will certainly post again when I get back to testing it, if I get success. Our project had to throw SPI out, and limp along with a slow serial port for now. Here is my situation: 56803 as SPI Slave I use interrupts to send and receive I use the RX IRQ to indicate both RXEmpty and TXFull CPHA=0 (toggle /SS to 1 between each character) CPOL=1 ColdFire5272 QSPI as Master long delays added between each character, and between leading edge of SS and first bit of data medium-low baud rate When I looked at the signals on a scope, they looked good to me, but the 5272 ColdFire was generating /SS and SCLK and MOSI. If you are so unfortunate as to be working with a Motorola evaluation board, beware! We bought five, and did not get even one with the rev F silicon - date code 0137 or higher. We got one "Proto A" chip, and a "Pilsen B", two rev Cs and one rev D. It was like taking a test drive at the auto dealer, and being given a car with three flat tires and no brakes. My erratum sheet suggests that the 805 rev F might have the same date codes. Rev F still has errata - no shortage of those. However, earlier revs simply did not have working SPI Slave silicon at all. From the Moto errata sheet, rev D, dates 0111-0128: "Slave Mode SPI data is corrupted on the MISO output." That cost me weeks, maybe a month, because I had memorized the date code for working CAN silicon, and confused that with the date for semi-working SPI silicon. "Slave" doesn't work at all, don't waste your time trying. Lesson learned: the most important document when working with Moto chips is the errata sheet. Re-read it often, and interpret it liberally. "SPI Slave data corrupt" was stated to have been fixed by rev E or F, which I will believe when I can test it on my desk with production silicon. Good luck to you, and *please* let me know if you succeed! Rick Corey -----Original Message----- From: kj831ca [mailto:] Sent: Wednesday, October 08, 2003 10:12 PM To: Subject: [motoroladsp] SPI Problem in 56F805 Hi I wonder if anyone had the problem with SPI in slave mode like mine. I'm setting 56F805 in slave mode, 8 bits transmition. By using Oscilloscope to capture the signal from MISO pin compare to SCLK pin found that 56F805 shift data out on both rising and falling edge of external clock. Let say if I write 0xAAAA to SPI Data Transmit Register , I will get the same signal as external clock . Anybody has any idea, is it hardware or software problem ?? _ _ _ _ _ __| |_| |_| |_| |_| |____ SCLK _ _ _ _ _ __| |_| |_| |_| |_| |____ MISO Best Regards Kris _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/