Lpc2000

Some more information on this problem:
- When temporarily disabling the SSP through SSPCR1 SSE=0 continuous 
  data transmit terminates (as would be expected), but then 
  reappears when setting SSE=1 a second or two later.
- Same thing happens if temporarily setting SSPCR1 SOD bit=1 (to stop 
  transmission of MISO pin in slave mode).
- SSPCPSR>=12 and is even.  Still no change.
- No change whether one or both MISO and MOSI pins left floating, 
  pulled up/down, or actually connected to the CODEC MOSI/MISO lines.
- No change if I attempt to perform a bunch of reads from the SSPDR 
  data register to try and flush it.
- No change when putting the SSP into SSI mode through SSPCR0 FRF=0x01 
  and setting CODEC accordingly by using configuration pull-up/down 
  resistors.  The only change will be that SSEL coming out of CODEC 
  will be normally low with the high sync pulse to start the data 
  frame (which is what would be expected).
- If CODEC is disconnected completely, including SCLK, SSEL, MISO, and 
  MOSI lines, and processor's SSP is put into master mode, all the 
  data I want can be sent out the MOSI line.  When completed, the MOSI 
  line will go back to normal status (not transmitting).

What's going on here?

--- In lpc2000@yahoogroups.com, "jeffbranc01" <jeffbranc01@...> wrote:
>
> Hello,
> Forgive me for being so new to the SPI/SSP peripheral.  I'm having a
> problem with my SSP port (LPC2220 processor, but probably the same for
> other LPC2000 processors having this feature).  My hardware
> configuration is the following:
> 
> - LPC2220's SSP configured for slave operation (16 bit data 
>   transfers), SCLK and SSEL supplied by external CODEC.
> - For testing, currently my processor's MOSI and MISO lines are 
>   floating.
> - After initial reset, CODEC is sending SCLK and SSEL signals fine, 
>   and the processor's MISO line has nothing on it.
> - CODEC's reset line is connected to processor GPIO line.  When this 
>   line is held low CODEC's SCLK and SSEL lines are held low.
> 
> When I attempt to transmit data (a 16-bit short) once out of the
> processor's MISO line by placing data into the SSP Data Register
> (SSPDR) I can see the data go out just fine.  I can do this multiple
> times and still the data is fine out the MISO line returning to a low
> voltage.  The problem that I'm encountering is that every time when I
> attempt to transmit the data on the eighth time, suddenly the MISO
> line starts continually transmitting whatever was last placed in the
> SSPDR register indefinitely, with a period that matches the SSEL
> signal coming from the CODEC.  Also, while it's doing this, if I do go
> ahead and change the value of the SSPDR it will switch and continually
> transmit that data instead.  What's even more amazing is that even
> when terminating the JTAG debug session the same data is still
> transmitted out the MISO port.  It will go on transmitting until I
> finally low assert the RESET line on the processor.  This will happen
> no matter how fast or slow I transmit these eight shorts whether back
> to back or with a four second interval in between them.  
> 
> Also, when I hold the CODEC's reset line low (disabling the SCLK and
> SSEL signals) obviously the MISO line will discontinue the
> transmission of continuous data.  As soon as I let this RESET line go
> back high, however, the SCLK and SSEL signals will be re-applied and
> the processors MISO pin will continue transmitting the data it had
before.
> 
> Some more info:
> - SSPCR0 FRF=0x00.  (SPI mode).
> - SSPCR1 Loop Back Mode (LBM) is set and verified to 0 (loop-back mode 
>   off).
> - SSPCR1 Master/Slave (MS) is set and verified to 1 (slave mode).
> - After initialization, the CODEC runs in continuous mode (meaning 
>   SCLK and SSEL lines are always going at the same periods regardless 
>   of whether there is data to be sent or not (but I still don't have 
>   the MISO and MOSI lines on the processor connected yet either).
> - All interrupts are disabled during these tests and SSPIMSC=0x0000.
> 
> Anyone have any idea of what might be happening?  I thank you in
> advance for your help.
> 
> Jeff.
>