An other Microchip screwup on teh 18F14K22
in [Design]
|
From: krw on 7 May 2010 19:01 On Fri, 07 May 2010 09:27:35 -0700, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >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. The problem is that SPI is so poorly defined that there have to be a gazillion options to get it to do anything. Verification of every combination of register settings gets to be a problem, quickly. >We use ARM chips that have 30-character pin names, the pin functions >are so overloaded. When I build the library parts I reduce the pin names to the function I'm actually using. >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. Would be nice, but while I like SPI (I2C is a PITA), it's not likely to happen.
From: krw on 7 May 2010 19:07 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: > <snip> >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. If you think that's bad, don't go anywhere near the TI 5509 DSP. The DMA controller usually works but sometimes skips an operation, causing the I/O controllers to get out of sync. Since I2S multiplexes data on the serial link, data ends up a channel off and there is no way to know that it even happened. We had to take a codec output and wrap it back to an input, and put a tone on it as an expected result to figure out when the DMA controller got out of sync. We won't even discuss the "McBSP". They've told us the 5504/5/15 actually works. We'll see.
From: John Larkin on 7 May 2010 19:11 On Fri, 07 May 2010 22:39:16 GMT, nico(a)puntnl.niks (Nico Coesel) wrote: >Spehro Pefhany <speffSNIP(a)interlogDOTyou.knowwhat> wrote: > >>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. > >I mentioned something similar in comp.arch.fpga. Tell Xilinx to make >such a device. If the price and the tooling (drag & click your >microcontroller) are right they have a killer. A Spartan fpga with a (or several) hard ARM cores on board would be great. Except that decent ARMs cost $4, and little ones cost under $1. The soft cores are too expensive in FPGA resources and tend to be slow. John
From: krw on 7 May 2010 19:29 On Fri, 07 May 2010 16:11:35 -0700, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >On Fri, 07 May 2010 22:39:16 GMT, nico(a)puntnl.niks (Nico Coesel) >wrote: > >>Spehro Pefhany <speffSNIP(a)interlogDOTyou.knowwhat> wrote: >> >>>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. >> >>I mentioned something similar in comp.arch.fpga. Tell Xilinx to make >>such a device. If the price and the tooling (drag & click your >>microcontroller) are right they have a killer. > >A Spartan fpga with a (or several) hard ARM cores on board would be >great. Except that decent ARMs cost $4, and little ones cost under $1. Actel has a hard ARM core in their new SpartFusion line. Analogs too. IIRC the prices start in the mid single digits for 5K/year sorts of quantities. http://www.actel.com/products/SmartFusion/default.aspx >The soft cores are too expensive in FPGA resources and tend to be >slow. Depends on what you want to do. About 1k LUTs gets a pretty decent controller. No FP, of course.
From: Martin Riddle on 7 May 2010 19:29
"Jan Panteltje" <pNaonStpealmtje(a)yahoo.com> wrote in message news:hs1e12$15l$1(a)news.albasani.net... > 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. Just had found a bug in the 18f4420, depending upon which sfr you load from to the MSSP buffer, it will either not initiate a SPI transfer or it will. But the default code generation of the MC18 compiler causes no transfer if you use a passed variable. Copy it to a local variable in the function, then write the sspbuff and it generates the correct movf sspbuff, w Yet the documentation offers little insight, other than the sample asm code. Cheers |