An other Microchip screwup on teh 18F14K22
in [Design]
|
From: Joel Koltner on 7 May 2010 20:04 Keith, <krw(a)att.bizzzzzzzzzzzz> wrote in message news:uu69u59n1l3eaoqrr7if0it27eue6c3hfs(a)4ax.com... > 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. Do you know if TI ever officially documented this somewhere? We're using 5507s, and to date we haven't run into that particular problem. (Heck, we were even lucky in that TI sent us an errata sheet detailing how the ADC of theirs we're using could get into a weird configuration and completely lock up and die until power was cycled... but it turned out we weren't using it in a mode that could provoke the bug.) ---Joel
From: krw on 7 May 2010 20:23 On Fri, 7 May 2010 17:04:07 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: >Keith, > ><krw(a)att.bizzzzzzzzzzzz> wrote in message >news:uu69u59n1l3eaoqrr7if0it27eue6c3hfs(a)4ax.com... >> 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. > >Do you know if TI ever officially documented this somewhere? Not that problem, to my knowledge. They admit to the DMA dropping data if it gets too busy (they originally blamed it on the way we were using the McBSP); "don't do that". It's a lot more insidious than what they claimed, though. Sure, you'll see it more when the DMA controller is heavily loaded, because it's doing more DMA, but it does it anyway. It wouldn't have been a major issue for us if there was some way of knowing that the thing was out of sync, but there isn't. I can almost understand DMA dropping a cycle here or there (1 in 1E11, perhaps) but to have no way to tell that the whole I/O subsystem is out of sync is incredible. >We're using 5507s, and to date we haven't run into that particular problem. >(Heck, we were even lucky in that TI sent us an errata sheet detailing how the >ADC of theirs we're using could get into a weird configuration and completely >lock up and die until power was cycled... but it turned out we weren't using >it in a mode that could provoke the bug.) They promise that they'll be better partners now. They keep showing up (the whole staff, I think) telling us how good it'll be next time. We got a couple of 5504/5/15 development kits out of them, though.
From: Spehro Pefhany on 7 May 2010 21:58 On Fri, 07 May 2010 17:57:31 -0500, the renowned "krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote: >On Fri, 07 May 2010 14:16:26 -0400, 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. > >That's a lot easier said than done. First, X, A, and A have most of the IP >locked up for FPGA sorts of things. Second, the development software for such >things is non-trivial. Great idea, but not likely to fly. Xilinx have just announced a hard ARM core (800MHz dual core Cortex M9, roughly Intel Atom class) with what I imagine will be a metric cr*pload of FPGA in 28nm for some time next year or so. Eventually it will filter down to the microcontrollers, but I agree with what you say, in general. Your first point is likely why it's coming from an FPGA company that licensed an ARM core and fiddled the bus to work rather than a traditional microprocessor/microcontroller supplier. And, come to think of it, the second point as well, since gcc takes care of much of the compiler development. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff(a)interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
From: Spehro Pefhany on 7 May 2010 22:01 On Fri, 07 May 2010 18:01:11 -0500, the renowned "krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote: > >When I build the library parts I reduce the pin names to the function I'm >actually using. Makes things harder than necessary for the firmware developers when they are reading the schematic. Maybe not as important if one person is doing both jobs and repurposing of pins etc. isn't likely. >>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. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff(a)interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
From: krw on 7 May 2010 22:41
On Fri, 07 May 2010 22:01:45 -0400, Spehro Pefhany <speffSNIP(a)interlogDOTyou.knowwhat> wrote: >On Fri, 07 May 2010 18:01:11 -0500, the renowned >"krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote: > >> >>When I build the library parts I reduce the pin names to the function I'm >>actually using. > >Makes things harder than necessary for the firmware developers when >they are reading the schematic. Maybe not as important if one person >is doing both jobs and repurposing of pins etc. isn't likely. How so? The name reflects its purpose _in_the_design_. He doesn't care what the pin is able to do. >>>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. > > >Best regards, >Spehro Pefhany |