An other Microchip screwup on teh 18F14K22
in [Design]
|
From: Jan Panteltje on 7 May 2010 12:10 After waisting some huors 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: Anyways, I did the SPI bit banging in C via the par port, this I tried in asm... so maybe with 64 MHz clock I can bit bang it slowly... 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? Paul Schoen was right 18F14K22 SPI sucks.
From: John Larkin on 7 May 2010 12:27 On Fri, 07 May 2010 16:10:04 GMT, Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote: >After waisting some huors 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: > >Anyways, I did the SPI bit banging in C via the par port, this I tried in asm... >so maybe with 64 MHz clock I can bit bang it slowly... > > > > >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? >Paul Schoen was right 18F14K22 SPI sucks. That's pretty bad. But uPs are getting so complex, so overloaded with features, that the designers are sort of shoveling hunks of home-made or purchased IP into compilers and hoping for the best. And, apparently, not taking much time to simulate and verify. Or document! We had to do a bunch of experiments on the SPI interface on our NXP ARMs; even high-level support people couldn't answer some fundamental timing/framing questions. The SPI and ADC documentation is awful. We use ARM chips that have 30-character pin names, the pin functions are so overloaded. What would be nice would be if things like SPI were small RAM-driven microengines. Then the functionality would be in loadable code, not hard-wired silicon. Sort of like Motorola's TPU blocks. They could be repurposed, too. John
From: Spehro Pefhany on 7 May 2010 14:16 On Fri, 07 May 2010 09:27:35 -0700, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >That's pretty bad. But uPs are getting so complex, so overloaded with >features, that the designers are sort of shoveling hunks of home-made >or purchased IP into compilers and hoping for the best. And, >apparently, not taking much time to simulate and verify. Or document! >We had to do a bunch of experiments on the SPI interface on our NXP >ARMs; even high-level support people couldn't answer some fundamental >timing/framing questions. The SPI and ADC documentation is awful. > >We use ARM chips that have 30-character pin names, the pin functions >are so overloaded. Who's are you using now? We're getting going with the Luminary parts. >What would be nice would be if things like SPI were small RAM-driven >microengines. Then the functionality would be in loadable code, not >hard-wired silicon. Sort of like Motorola's TPU blocks. They could be >repurposed, too. > >John You'd think it would be relatively simple to put a thin FPGA or CPLD fabric around the core, perhaps preloaded from ROM with some useful defaults.
From: Jan Panteltje on 7 May 2010 15:25 On a sunny day (Fri, 07 May 2010 09:27:35 -0700) it happened John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in <t8f8u5d858e95v5mjqt17m4td3s4b9ia7q(a)4ax.com>: >>Looks bit like those old Intel erratas, that got me in the past. >>Do they not want people to use their chips? >>Paul Schoen was right 18F14K22 SPI sucks. > > >That's pretty bad. But uPs are getting so complex, so overloaded with >features, that the designers are sort of shoveling hunks of home-made >or purchased IP into compilers and hoping for the best. And, >apparently, not taking much time to simulate and verify. Or document! >We had to do a bunch of experiments on the SPI interface on our NXP >ARMs; even high-level support people couldn't answer some fundamental >timing/framing questions. The SPI and ADC documentation is awful. > >We use ARM chips that have 30-character pin names, the pin functions >are so overloaded. I have been thinking 'ARM' quite a few times today, I planned on this feature to work... I have some more data, for those who run into similar problems: First in SPI master transmit mode, the least significant bit (bit 0) on SO is does not follow input. Second SPI SI (input) does nothing and always reads some constant. Tested at 16 MHz, and at 64 MHz. The SSPSTAT, BF (transmission complete bit) never gets set, as if that last bit is never transmitted? The example from their own dataheet does not work: LOOP BTFSS SSPSTAT, BF ;Has data been received (transmit complete)? <------------------- gets never set. BRA LOOP ;No MOVF SSPBUF, W ;WREG reg = contents of SSPBUF MOVWF spi_in ;Save in user RAM, if data is meaningful MOVF spi_out, W ;W reg = contents of TXDATA MOVWF SSPBUF ;New data to xmit So if you skip the test for SSPSTAT, BF, then it transmits 7 valid bits, and bit 8 always some fixed value, also if you add huge delays between transmissions, so no collisions can cause this. The device ID of this chip: 23 4f >What would be nice would be if things like SPI were small RAM-driven >microengines. Then the functionality would be in loadable code, not >hard-wired silicon. Sort of like Motorola's TPU blocks. They could be >repurposed, too. I dunno what you mean by RAM driven. It is just a simple shift register, plus up to 8 counter, .... I they cannot do that in hardware then they have BIG problems.
From: Jan Panteltje on 7 May 2010 15:37
On a sunny day (Fri, 07 May 2010 14:16:26 -0400) it happened Spehro Pefhany <speffSNIP(a)interlogDOTyou.knowwhat> wrote in <p4j8u594cn3gpth7r6ml0sohclhpmsqlfa(a)4ax.com>: >On Fri, 07 May 2010 09:27:35 -0700, John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >> >>That's pretty bad. But uPs are getting so complex, so overloaded with >>features, that the designers are sort of shoveling hunks of home-made >>or purchased IP into compilers and hoping for the best. And, >>apparently, not taking much time to simulate and verify. Or document! >>We had to do a bunch of experiments on the SPI interface on our NXP >>ARMs; even high-level support people couldn't answer some fundamental >>timing/framing questions. The SPI and ADC documentation is awful. >> >>We use ARM chips that have 30-character pin names, the pin functions >>are so overloaded. > >Who's are you using now? We're getting going with the Luminary parts. > >>What would be nice would be if things like SPI were small RAM-driven >>microengines. Then the functionality would be in loadable code, not >>hard-wired silicon. Sort of like Motorola's TPU blocks. They could be >>repurposed, too. >> >>John > >You'd think it would be relatively simple to put a thin FPGA or CPLD >fabric around the core, perhaps preloaded from ROM with some useful >defaults. Oh, yes, like the Xilinx shift registers.... patents, patents, patents. |