On a sunny day (Tue, 27 Mar 2012 13:50:41 -0600) it happened hamilton
<
hami...@nothere.com> wrote in <jkt5mk$q09$
1...@dont-email.me>:
>On 3/27/2012 1:11 PM, Jan Panteltje wrote:
>
>> As the 18F14K22 SPI is broken,
>
>Whats broken with the SPI ??
I would have to look it up,
but it was reported here by me last year, google may still have it.
Let me look in my ownw archive, moment...
Ok this I ran into when I wanted to drive the Microchip ethernet chip
from th 18F14K22 with SPI, in may last year I wrote:
>After waisting some hours to get SPI working with the PIC 18F14K22 connected to an ENC28J60 Ethernet cotroller,
>and finally grabbing the scope, I found it sort of always loses bit 0 in the SPI.
>So looking for that sort of disaster with googke pointed to the 'errata',
>well I should have looked for that first, so anyways, that 'errata' says:
>4. Module: MSSP (Master Synchronous
> Serial Port)
> 4.1 In I2CTM Master mode, baud rates obtained
> by setting SSPADD to a value less than
> 0x03 will cause unexpected operation.
> Work around
> Ensure SSPADD is set to a value greater
> than or equal to 0x03.
> Affected Silicon Revisions
> A1 A2 A3 A7 A8
> X X X X
> 4.2 In SPI Master mode, when the CKE bit is
> cleared and the SMP bit is set, the last bit of
> the incoming data stream (bit 0) at the SDI
> pin will not be sampled properly.
> Work around <--------------------------------------------------- throw chip away and find an other if you need this
> None.
>
> Affected Silicon Revisions
> A1 A2 A3 A7 A8
> X X X X
> 4.3 When SPI is enabled in Master mode with
> CKE = 1 and CKP = 0, a 1/FOSC wide pulse
> will occur on the SCK pin.
> Work around
> Configure the SCK pin as an input until after
> the MSSP is setup.
>
>Affected Silicon Revisions
> A1 A2 A3 A7 A8
> X X X X
>
>4.4 In I2C Master mode, SSPADD values of
> 0x00, 0x01, 0x02 are invalid. The current I2C
> Baud Rate Generator (BSG) is not set up to
> generate a clock signal for these values.
> Work around <--------------------------------------------------- throw chip away and find an other if you need this
> None.
>
>Affected Silicon Revisions
> A1 A2 A3 A7 A8
> X X X X
>
>
>4.5 In I2C Master mode, the RCEN bit is not
> cleared by hardware if improper Stop is
> received on the bus.
> Work around
> Reset the module via clearing and setting
> the SSPEN bit of SSPCON1.
>Affected Silicon Revisions
> A1 A2 A3 A7 A8
> X X X X
>
>
>4.6 In SPI Master mode, when the SPI clock is
> configured for Timer2/2 (SSPCON1
> <3:0> = 0011), the first SPI high time may
> be short.
> Work around
> Option 1: Ensure TMR2 value rolls over to
> zero immediately before writing to
> SSPBUF.
> Option 2: Turn Timer2 off and clear TMR2
> before writing SSPBUF. Enable
> TMR2 after SSPBUF is written.
>Affected Silicon Revisions
> A1 A2 A3 A7 A8
> X X X X
>
>4.7 In any SPI Master mode, SCK = TMR2/2, if
> SSPBUF is written to while shifting out data,
> a ninth SCK pulse is incorrectly generated.
> At that point, the module locks the user from
> writing to the SSPBUF register, but a write
> attempt will still cause 8 or 9 more SCK
> pulses to be generated.
>
> Work around
> The WCOL bit of the SSPCON register is
> correctly set to indicate that there was a write
> collision. Any time this bit is set, the module
> must be disabled and enabled (toggle
> SSPEN) to return to the correct operation.
> The bus will remain out of synchronization.
>Affected Silicon Revisions.
> A1 A2 A3 A7 A8
> X X X X
>---------------------------------------------------------------
>
>Looks bit like those old Intel erratas, that got me in the past.
>Do they not want people to use their chips?