PIC18F8722 A1 Errata Sheet Released

[kmcclary]

I just received notification by Microchip that they've released an Errata Datasheet for the PIC18F8722 Rev A1 wafer. It outlines a lot of the known problems with the die (and some workarounds, if discovered). (FYI all: The PIC18F8722 is the 2006 Robot Controller's CPU.)

"PIC18F6627/6722/8627/8722 Rev. A1 Silicon Errata"
http://ww1.microchip.com/downloads/en/DeviceDoc/80221c.pdf

Every team's Programming Group should probably download this to their CPU doc area and review it, so you're all aware of the software vagrancies of this die. It may strongly assist you in debugging code, when things don't seem to work as "advertised".

I hope this helps!

- Keith

[eugenebrooks]

Given the scope of the errata on this chip, I would hope that IFI switches back to the 8520 in the robot controller. Lacking that, given the trouble we experienced last year, we will find ourselves putting a VEX controller in the robot to front end sensors and timers that we had so much trouble with on the 8722. I hope it does not take up too much weight or space...

Eugene

[yongkimleng]

Originally Posted by eugenebrooks

Given the scope of the errata on this chip, I would hope that IFI switches back to the 8520 in the robot controller. Lacking that, given the trouble we experienced last year, we will find ourselves putting a VEX controller in the robot to front end sensors and timers that we had so much trouble with on the 8722. I hope it does not take up too much weight or space...

Eugene

The 8722 is still relatively new imho (like intel duo core) and hence I'd prefer to keep away from it in the meantime. I've found 8520 already suitable for the task, not to mention alot of unused extra features. Sourcing around, sometimes i feel AVR's mega1280 very featurefull too.

[kmcclary]

Originally Posted by eugenebrooks

Given the scope of the errata on this chip, I would hope that IFI switches back to the 8520 in the robot controller. Lacking that, given the trouble we experienced last year, we will find ourselves putting a VEX controller in the robot to front end sensors and timers that we had so much trouble with on the 8722. I hope it does not take up too much weight or space...

Eugene

I can't comment on IFI's reaction, or what you should do...

I'm just hoping that as the die revs up through the last two quarters of '06 that IFI will either upgrade it before kickoff shipments, or else give us the appropriate caveats about the current die rev.

In the meantime though I just really felt Programming Teams should be aware of these problems, to assist them in debugging code they may be working on this fall using the 2006 controller.

OOC, has anyone pulled their controller apart yet, to see the die rev in it? If so, feel free to post your die rev here, so we can all compare notes.

Originally Posted by yongkimleng

The 8722 is still relatively new imho (like intel duo core) and hence I'd prefer to keep away from it in the meantime. I've found 8520 already suitable for the task, not to mention alot of unused extra features. Sourcing around, sometimes i feel AVR's mega1280 very featurefull too.

I'm posting this because in case you weren't aware, the PIC18F8722 is the chip in the 2006 Robot Controller.

Now what you do for a payload widget's co-processor is totally up to you.

Good luck, and again I hope this helps everyone!

- Keith

[Qbranch]

Originally Posted by kmcclary

I just received notification by Microchip that they've released an Errata Datasheet for the PIC18F8722 Rev A1 wafer. It outlines a lot of the known problems with the die (and some workarounds, if discovered). (FYI all: The PIC18F8722 is the 2006 Robot Controller's CPU.)

"PIC18F6627/6722/8627/8722 Rev. A1 Silicon Errata"
http://ww1.microchip.com/downloads/en/DeviceDoc/80221c.pdf

Every team's Programming Group should probably download this to their CPU doc area and review it, so you're all aware of the software vacancies of this die. It may strongly assist you in debugging code, when things don't seem to work as "advertised".

I hope this helps!

- Keith

I use the 18F series processors to run many machines around where I work, and have found them very stable.

The 8722 HPC does have some issues, especially with the ECCP/CCP peripherals, the RETFIE FAST command and some shake on the 10bit ADC peripheral. However the FAE for Microchip came out to my work and he verified along with me that the problems i had were real silicon problems. THE 8722 DIE IS BEING RECUT THIS WINTER. The FIRST controllers for next season *should* have the fixed and updated processor by then.

Also, there are workarounds for all problems I've found so far. If anyone has problems with the capture/compare peripherals I can give you some workaround hints. The ADC instability can be overcome with some simple code, and the RETFIE FAST problem can be solved by simply using the low priority interrupt vector instead of the high.

Well... plus the fact that I'm sitting on about 15 PICdem HPC Explorer boards might have something to do with me trying so hard to make them work...

-Q

[kmcclary]

Originally Posted by Alex "Qbranch"

I use the 18F series processors to run many machines around where I work, and have found them very stable.

The 8722 HPC does have some [actual silicon issues, verified by their FAE, but there ARE workarounds for all problems I've found so far. If you need help, contact me...]

THE 8722 DIE IS BEING RECUT THIS WINTER. The FIRST controllers for next season *should* have the fixed and updated processor by then.

Well... plus the fact that I'm sitting on about 15 PICdem HPC Explorer boards might have something to do with me trying so hard to make them work...
-Q

That's good to hear... Hopefully, we won't swap old bugs for new ones...

<edit> (Whoops... The die being rev'd is good, not the fact that you're having problems!) </edit>

BTW... Here's a link to the PICdem HPC Explorer (for the curious):
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName =en022480

OOC Alex, are you making FIRST RC "co-processors" (or "smart widget controllers") out of the PICdem HPC Explorer boards?
...If so, you may wish to start a thread about that!

<edit> BTW... I haven't had a chance to exercise the 2006 RC to check for these faults yet. Since you've been working with this chip very intimately Alex, have you noticed if they are showing the A1 die faults, more/other faults (if so please list them), or none of them? </edit>

Thanks!

- Keith

[Qbranch]

Originally Posted by kmcclary

That's good to hear... Hopefully, we won't swap old bugs for new ones...

<edit> (Whoops... The die being rev'd is good, not the fact that you're having problems!) </edit>

BTW... Here's a link to the PICdem HPC Explorer (for the curious):
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName =en022480

OOC Alex, are you making FIRST RC "co-processors" (or "smart widget controllers") out of the PICdem HPC Explorer boards?
...If so, you may wish to start a thread about that!

<edit> BTW... I haven't had a chance to exercise the 2006 RC to check for these faults yet. Since you've been working with this chip very intimately Alex, have you noticed if they are showing the A1 die faults, more/other faults (if so please list them), or none of them? </edit>

Thanks!

- Keith

Well... FIRST RCs are really really exepensive... and I can't afford to get one for every little project I might have. So, the HPC's make awesome robot controllers, at a much lower price.

Not to mention you can have breakpoints, watches, whatever. Plus, you get to do whatever you want with the processor, no restrictions.

Here's my word on co-processors. Can I make one? Certainly. Do you need one? not if your smart about your time. The 8722 is a very powerful chip, operating at 10mips.

The most taxing project I have running on an HPC is a two axis motion controller, running step motors at a max of 12.5KHz... as well as doing motion path calculations and motivation.

The only time i can think of (correct me if i'm wrong) that you would need a co processor is when you are doing vision processing. However, no one need worry since all vision processing is done off site in the CMUcam's Fujitsu processor....

Hey this is off topic but does anyone know if we'll be getting the new CMUcamII+ this year?

If anyone needs any help with using HPCs or any microchip development boards... just hit me up.... along with the HPC i'd also suggest the PICkit2

-Q

[Qbranch]

OK i know this is my second post but I forogt to answer some of Kieth's (kmccleary) questions:

When used within the '06 RC, the 8722 seems to exibit few problems... because few of the really neato features of the chip can be accessed due to the sort of 'shell' IFI lets you work in.

ECCP/CCP and Timers exhibit the most problems.... but if Timers are used in overflow mode, as is outlined in the IFI whitepaper on using timers, there are no problems. Also, the ECCP/CCP pins (so far as i know) are not brought out on the board, so you can't use them anyhow. Big bummer for me since thats one of my favorite ways to get the speed of something...

Really i'd say about 90-99% of first teams should not encounter the problems with the 8722 die if they are using them within the '06 RC.

IF any of you believe you have a die problem please tell me and i'll verify it, then pass it on to my FAE.

Again, any questions just tell me.

-Q

[bear24rw]

Originally Posted by Qbranch

Hey this is off topic but does anyone know if we'll be getting the new CMUcamII+ this year?
-Q

Is there really anything that much better about it?

When compared with our other CMUcam2 products, the CMUcam2+ has these important differences:

* Thinner profile
* 15% lighter weight
* Uses only the more capable OV6620 camera*
* No level-shifter on board for more efficient connection to +5V controllers
* Minimal packaging: does not include printed manual, AC adapter, or CD-ROM
* Different connector arrangement with horizontal pins for easier stacking

I doesnt look like its much different at all...
Im waiting for CMUcam3!

or to get motivated enough to use a coprossesor and a webcam...

[kmcclary]

Thanks for the reply, Alex...

Originally Posted by Qbranch

The only time i can think of (correct me if i'm wrong) that you would need a co processor is when you are doing vision processing. However, no one need worry since all vision processing is done off site in the CMUcam's Fujitsu processor....

Actually, I wouldn't say that at all. We've found co-processing a GREAT boon to development.

FYI we did a co-processor PIC at 1502 this season, to monitor and control our shooter's speed. IMHO that was a great decision. The Shooter PIC and the RC talked to each other via only a few digital I/O lines. The RC gave the PIC the desired shooter speed in RPM. The co-processor monitored the shooter wheel's encoder, ran a PID loop within itself, then told the RC both what command to send to the shooter's motor Victor (and when it was "ready to shoot" via a separate line).

It worked wonderfully! The Shooter code team simply provided a few "shooter call functions" on the RC side to do all the R/W dirty work, and the RC programming team had a very simple to use "smart device" on their hands.

Advantages of co-processing:
- it separated the shooter's software development from the RC, breaking code development up into parallel tracks with separate programmers on separate workstations;
- it totally unloaded the RC from all "high prio widget timing issues" (eg no interrupt code required on the RC side);
- for the shooter code, it avoided the RC's classic "going mental for significant blocks of time" issue due to interprocessor overhead, that tends to screw up realtime code (both encoder sampling and PID calculations);
- the PID loop was extremely fine tunable because it ran in a "clean environment" (no RC code to contend with).
- Using the digital I/O for interprocess communications allowed the RC to determine the data clocking between them, eliminating all realtime timing issues on the RC side (again avoiding the RC's "going mental" problem).

In the end our final shooter's performance was fantastic. It settled into any new commanded speed within a second! We'll definitely consider using co-processing again for any future "smart payload devices" a future game may require.

The reason I bring this up is as I've said, up to now we've used other PIC processors as RC co-processors. Moving to a PIC18F8722 HPC board as a "generic co-processor board" might make sense to us. Handling both RC and co-processor programming with a single target MPU (and programming environment) would vastly reduce the amount of new student training we'd have to set up and maintain.

My concern with that plan though is again Errata issues with the 8722 die (especially after you said the HPC boards DO have issues...). If they're too flaky, we may be better off sticking to the PIC PCB we developed for the 2006 season.

So... have you tried using your HPC as a RC co-processor board? If so, have you run into any issues yet? (ESPECIALLY Errata Sheet related issues... After all, that is this thread...)

Speaking of which... Guys, please don't hijack this thread with off topic issues like camera model speculations, unless they interact with "errata" issues. Please start another thread instead. (That's also a cool topic!)

Thanks!

- Keith

[Kevin Sevcik]

Our team actually ran into one of the die issues with Timer1/3. Specifically, the external clock input is exposed on one of the I/O ports, so we were using Timer1 as an async counter to count encoder pulses. This would have worked brilliantly, as it required no interrupts, and could handle a very high pulse frequency. Unfortunately, the die issue with 16-bit R/W of the timer in async mode was a large stumbling block and limited our resolution once we figured it out. Otherwise, it worked brilliantly for measuring the shooter wheel. Since that only ever goes one direction and all that.

Anyways, I'm questioning the need of an entire co-processor for simply processing the shooter encoders and PID. Or atleast the PID. Unless you're being fancy, your PWM update rate on the controller is rather limited, so I can't see the the advantage of doing a really fast off-board calculation and then queuing it up to wait to be output in the RC.

To Qbranch,

I recall having some difficulties with using shifts instead of divides to try to save processor cycles. Specifically:
A. I don't know if it actually saves any time or not.
B. I'm pretty sure shifting a signed 16-bit number didn't preserve the sign, which made it useless for trying to save cycles, since all the negative numbers ended up positive.

[kmcclary]

Originally Posted by Kevin Sevcik

Anyways, I'm questioning the need of an entire co-processor for simply processing the shooter encoders and PID. Or atleast the PID. Unless you're being fancy, your PWM update rate on the controller is rather limited, so I can't see the the advantage of doing a really fast off-board calculation and then queuing it up to wait to be output in the RC.

Actually, no queuing was involved. We simply SWAPPED a 16-bit word every RC loop, bitwise simultaneously on one clocking (one bit in and one bit out per clock bit). IOW every loop the RC exchanged its currently desired RPM for the Shooter PIC's latest Victor command, which the RC then simply echoed. That's a relatively short driver for the RC.

I already listed the main advantages above. But in addition, I knew in the past a lot of teams have had encoder driver, sampling/averaging, and PID loop timing problems with the RC. Most of that stemmed from one or more of: filtering on the I/O lines, Die Errata problems, interrupt interactions, library function problems, or because of the RC's internal interprocessor communications overhead. (IOW, random vagrancies of the RC, which we could not control nor modify.)

For that reason alone we simply elected to avoid the whole shebang by taking it all off the RC.

But IMO the biggest payoff was that (MUCH to our surprise) our shooter control subsystem hardware ended up being built, written and debugged all in about one week, off to the side. ( IOW, it was all done BEFORE we even had the shooter's hardware in hand...) IMO this was primarily because we knew EXACTLY what the co-processor circuit was (and could tweak it if need be), and we did NOT have to interleave testing and software integration with our other RC software work. This avoided ALL of the RC's "black box" vagrancies.

Once the shooter hardware was ready we only had to "tune the loop". To do that, we still didn't require the RC. Instead, the Shooter Team simply used our spare "field swap / repair copy" of the PIC board as an RC "protocol simulator". Add a simple harness, a short test program running on the spare, and Hyperterminal, and we were in business.

That let the Drivetrain and Manip teams keep the real RC to themselves 99% of the time, which sped THEM up.

<edit>
Now don't get me wrong. The RC works just fine with straight code. But if we wish to do high code, realtime, interrupt driven, high math, or time intensive code, and one has a working co-processor on hand, why should you even want to wrestle with the RC's limitations and perhaps even risk delivery?
</edit>

Now that we have a generic RC vs co-processor "swap data" routine running, the big code is already done. Why not do it again? From now on, making ANY kind of future co-processor to "smarten up our payload widgets" should be fairly straight forward, and an attractive option.

- Keith

[Kevin Sevcik]

Keith,

Great post. I suppose I can't argue with being able to troubleshoot the entirety of the shooter loop sans RC. That's definitely sweet. I was just noting that the PWM update rate for the RC is 26.2ms, unless you're doing fancy things with interrupts and PWM13-16. If you can't do your PID calc in the RC that quickly, you've got serious problems in your code.

Now, you can relatively easily make your own code for PWM13-16 so they update at the 120Hz that's the max the Victors can handle. In which case you might need a quicker calc for your PID.

Come to think of it, I'm curious about the exact signaling and timing of all that data passing back and forth between your processors. If I'm thinking about it right, you'd get at least a 1 cycle delay from your commanded RPM change to the new command being sent to the motors. Maybe more.... Which probably doesn't matter in the rather stable systems in FIRST, but could still be a concern.

[kmcclary]

Originally Posted by Kevin Sevcik

Keith,

Great post. I suppose I can't argue with being able to troubleshoot the entirety of the shooter loop sans RC. That's definitely sweet. I was just noting that the PWM update rate for the RC is 26.2ms, unless you're doing fancy things with interrupts and PWM13-16. If you can't do your PID calc in the RC that quickly, you've got serious problems in your code.

Now, you can relatively easily make your own code for PWM13-16 so they update at the 120Hz that's the max the Victors can handle. In which case you might need a quicker calc for your PID.

Come to think of it, I'm curious about the exact signaling and timing of all that data passing back and forth between your processors. If I'm thinking about it right, you'd get at least a 1 cycle delay from your commanded RPM change to the new command being sent to the motors. Maybe more.... Which probably doesn't matter in the rather stable systems in FIRST, but could still be a concern.

Thanks! (Feel free to send positive Rep if you actually found my babbling useful... )

You are correct in that with a single conversation per loop you normally have one loop delay between command and reply. (Send the problem in one loop, pick up results in the next one.) But there is absolutely no technical reason prohibiting you from talking more than once to the co-processor in any one RC main loop or interrupt. After all, you have DIRECT user program control of many of the Digital I/O lines, which can babble to your heart's content at multiple MHz within your driver call...

However, once your loop is done (and due to reentrancy concerns with calling things from interrupt drivers) you normally end up waiting for the next loop to get control again. So for all intents and purposes you're always somewhat limited to roughly the loop time for updating Victors. (Attempting to refresh a Victor multiple times within one loop won't do much good. There's that darn frame time delay between calling the RC's realtime PIC and it "getting around to sending it out"...)

Now WRT Victors and delays, don't forget to add in another 17ms or so of delay, for the Victor to hear and interpret the PWM command. Remember, the data first has to be sent from the user code PIC to the RC's realtime PIC, then encoded and sent again as PWM after the current PWM frame is sent, and then decoded back by the Victor's PIC. I was also told by IFI that the time between the output call to the realtime PIC and the updated PWM appearing is asynchronous.

Therefore, even with a fresh PWM value in your hot little hand, you may end up with up to 40ms or so of delay between your code loop's output call and the Victor's response. Right away, that seriously limits any PID's bandwidth.

That's yet another reason why sweating the vagrancies, delays (and Errata) of the RC was something we wanted to minimize. Going with a co-processor, its basic job is tuning the PID loop, and "accommodating" the "RC and Victor chain's" variable delay.

WRT communications, we should probably take the general discussion of Co-Processing nitty gritty to another thread. But briefly, for this project we used just five signal lines. Four were for the basic bidirectional "co-processor board #1" communications that runs at blazing rates. One additional line was used as a dedicated "The Shooter Is At Requested Speed" signal to the RC, to simplify our FullAuto firing routine (which guaranteed all balls left with the right KE). FYI, bidirectional talking to more co-processor boards only requires TWO additional RC digital I/O lines per board. The RC runs the exchange, so it can go as mental as it wishes without data corruption or overrun. No analog or serial ports (nor their handshake wires) are required. Message length is arbitrary, yet message sync can't be lost. Co-processor power comes from a raw breaker panel fuse, not the RC.

(Thought Exercise: Even without starting a new thread, that spec should allow one to determine what all the signals are, and what their timing needs to be...)

The Bottom Line (and back to Errata!): Though the OI/RC set is cool, IFI won't allow any of us access to their schematic nor firmware listings. Now that's OK, but that'll always make the RC somewhat of a Black Box, which at times may exhibit "exotic behaviors", especially due to Errata, firmware bugs, etc....

We simply got tired of dealing with Errata and other random timing problems for doing complex things, especially when it could possibly "risk the farm" during the build. So though we'll still have the RC do a lot of work, IMHO developing co-processing technology for "any BIG thing" that might stress the RC (or our Programming Team) was well worth the initial development effort spent last year. This gives US more design control, and greatly reduces the possibility of Errata interactions should we ever need to "do/make something complicated" again.

Does that all make sense?

- Keith

[Kevin Sevcik]

Makes a lot of sense, I'll be looking into this for our team next season. Also figuring out how to do that fast serial comm through digital I/O you're doing. Also, check your PMs for further discussion.