New PICs, New Errata [Update 2]

It’s been a while since the topic of chip errata has come up. This is due to the fact that things have pretty much settled down for existing PIC32MX parts (See the last update). Now by that I mean that everyone now pretty much codes around these errata on a permanent basis.

Sometime ago, a new series of PIC32MZ parts was announced and these are now starting to become available. What new and exciting features will be available here to power new products and projects? Here’s a really brief summary:

  • Operation up to 200 MHz with Instruction and Data Caching for up to 330 DMIPS of performance. [No too shabby at all but no speed demon either!]
  • Internal memory of up to 2048 KB of flash memory and 512 KB of ram. [YAY!]
  • An external 50 MHz memory interface for further external memory.
  • A Serial Quad Interface allows this PIC to take advantage of serial flash devices that move four bits at a time rather than the pokey one bit at a time [finally!] An added bonus is that the PIC can actually execute from serial memory using XIP mode! [Don’t cheer just yet…]
  • An Analog to Digital converter that can operate as high as 500 K Samples per Second. [Ditto.]

That is a lot of text, so here’s a cool picture:

PIC32MZECfamilybloc

There is a lot of new stuff going on here, so the skeptics and other normal people may be wondering about errata. Well here are the PIC32MZ Family Datasheet 60001191C and the latest PIC32MZ Errata 80000588F.

They ARE pretty dense reading so I’ll give a very brief summary of the issues. First some good news. While earlier PICs suffered from serious flaws in the CPU and Flash memory, these new PICs are not repeating those mistakes. This is a HUGE relief. The peripherals however have a few notable gosh-darns. Here are some selected notes:

11. Module: Secondary Oscillator
A crystal oscillator cannot be used as the input to the Secondary
Oscillator (SOSCI/SOSCO pins).
Work around
Instead, use the external clock. [This is all well and good except that this clock input is usually used for a 32.768 KHz RTC clock and getting battery operation may be more difficult to achieve with an external oscillator]

13. Module: Power-Saving Modes
Dream mode is intended as a feature allowing DMA operation while the CPU is in Idle mode; however, Dream mode does not function.
Work around
None. [Too bad, this sounds like a great idea.]

15. Module: SPI
The SPI clock speed does not meet the published specification. The maximum supported SPI clock speed is 27 MHz.
Work around
None.. [Bye bye 50 Mhz… On the bright side, 27 MHz should be useful for jamming annoying people who still use CB radio!]

27. Module: Random Number Generator
True RNG mode does not function.
Work around
Instead, use Pseudo-Random Number Generator (PRNG) mode. [I guess the NSA was not happy with the idea of people having effective security. PRNGs are easily cracked.]

31. Module: SQI
XIP mode is not operational (MODE<2:0> bits = 011 in the SQI1CFG register).
Work around
Use PIO mode (MODE<2:0> bits = 001) or DMA mode (MODE<2:0> bits = 010). [Sigh… This feature had such promise for code executing out of a pluggable memory device without a lot of extra expenses.]

34. Module: SQI
Clock speed for read operations does not meet the maximum specification (SQ10) of 50 MHz. For read operations the maximum clock is 25 MHz.
Work around
None. [Drat! Now we can’t even jam CB radios!]

44. Module: ADC
For Revision A3 and A4 silicon: The ADC module does not meet the published
Throughput Rate (AD51) and Full-Scale Input Range (AD12) specifications. The updated Maximum Throughput Rate (AD51) specification is 125 ksps, assuming 16x Oversampling mode. The updated Maximum Full-Scale Input Range is 2.5V for both Differential and Singled-Ended modes. The updated Minimum Full-Scale Input Range is -2.5V for Differential mode.
For Revision A5 and newer silicon: The ADC module does not meet [the] published throughput rate (AD51) and accuracy specifications. More information will be provided in a subsequent October 2014 update of this document.
Work around
None. [So the ADC runs at 1/4 speed but that may change. I’ll post an update when I get one.]

OK, so how do these errata compare? Overall, they are pretty light. While it is true that some nifty features are making an exit, on the whole the core is solid and the peripherals are a significant improvement over any available before. I look forward to working with this new PIC and will write about any interesting things that may come up.

As always, comments and suggestions are most welcome.

Best regards;

Peter Camilleri (aka Squidly Jones)

[Update Nov 27, 2014]

It has come to my attention that I’ve left out at least one important errata. Here it is:

41. Module: Oscillator 
A crystal oscillator cannot be used as the input to the Primary Oscillator (OSC1/OSC2 pins).
Work around
Use an external clock or an internal FRC. [I did not see this as a killer bug as I routinely design in both a crystal and an oscillator module (and populate only one part). The modules often perform better and it makes for more options in the final BOM while consuming very little space.]

As usual, check the docs for yourself and you be the judge!

Peter Camilleri (aka Squidly Jones)

[Update Jan 3, 2015]
The most recent errata (80000588G) for the PIC32MZ family reveals that the latest revision of silicon can finally use a crystal for its main oscillator. Yay! Mind you there are still some spec issues here, and those errata remain. IMHO those issues are minor compared to not being able to run with a crystal at all. For the most demanding applications though, an external oscillator module may still be the best bet.

Again, check the docs for yourself and you be the judge!

Peter Camilleri (aka Squidly Jones)

Wow! Did they really do that?

I once heard that the intelligence of any group of people is that of the person with the lowest IQ divided by the number of people involved. A recent case seems to be a supporting data point for this point of view.

Consider if you will the company FTDI. This company is (was?) the world leader in the area of USB bridge chips that make it easy to add USB access to all sorts of gadgets that would otherwise be difficult, expensive, and problem prone. The FTDI chips work well and come with easy to use software distributed for free with Windows, Mac, Linux, and many other sorts of computers. The chips and the software drivers were so good that many customers chose to go with FTDI rather than other vendors. The result of this is that these chips are expensive and often hard to find.

So FTDI gets to laugh all the way to the bank and otherwise all is well right? Well not quite. Counterfeits! With the real mccoy so hard to get, many legitimate vendors were tricked into buying fake chips. Do these fakes work? Mostly, it’s not as if the USB bridging function is that hard to do. FTDI however was not amused. They were losing some sales and lots of that delicious money! They had to do something and they did!

To stem the loss of revenue, a new software driver was released that detects some subtle difference between genuine and fake chips and then erases a vital data entry called the PID (Product ID) if a fake is detected. After that, the fake chip and the product it was embedded in will no longer function. The consumer is now the proud owner of a new paper weight or brick as it is sometimes called. The new driver was released through the Microsoft Windows update mechanism where it was incorporated into countless millions of computers all around the world.

So; Is this a nasty thing to do? Consider this bit on computer trespass (my emphasis):

In Virginia, computer trespass consists of, with malicious intent, copying, altering, or erasing data from a computer, causing a computer to malfunction, causing an electronic funds transfer, etc.[Wikipedia]

Yes this IS a very nasty thing to do! It hurts consumers at random. Some have gone so far as to label it cyber-terrorism! While I am not sure about that, one thing is certain, this action has caused serious, if not fatal, damage to the faith and value of the FTDI brand. Engineers chose and specified FTDI chips over others because they were trusted, reliable and dependable. That perception is gone and it will be very difficult to recover that goodwill.

I cannot even begin to imagine the legal fall-out from what would happen if a large number of products suddenly stopped working and the victim decided to let loose the dogs (lawyers) of war in revenge!

I am a big fan of the EEVBLOG and this posting does a good job of summarizing people’s feelings about this issue and the lameness of the company’s responses:

EEVblog #676 – RANT: FTDI Bricking Counterfeit Chips!

As for me, I am looking for other vendors. This sort behaviour is so unacceptable that it makes me seriously wonder what kind of crazy people are in charge at FTDI.

What do you think? I’d really like to hear what you think about this issue!

Best regards;

Peter Camilleri (aka Squidly Jones)

Magnus Errata Part 3

This article is the fourth in a two part series about some serious errata published regarding the Microchip PIC32 famility of embedded microcontrollers. Previous articles have been Magnus Errata Part 1,  Magnus Errata Part 2, and Magnus Errata Update. There has been a significant passage of time and with the arrival of new errata data, a new chapter in the story is called for. At the same time, a goal for this article is to clarify the application of errata data beyond the PIC32 designation. This is to reflect the fact that the PIC32 family is implemented in multiple varieties, each with unique characteristics.

The PIC32 family can be broadly divided into three main branches:

  1. Smaller parts: PIC32MX1xx/2xx
  2. Mid sized parts: PC32MX3xx/4xx
  3. Larger parts: PIC32MC5xx/6xx/7xx

The first condition was an issue with spurious Data Bus Exceptions when data constants were read from flash memory with interrupts turned on. The respective, current errata notes for this issue are:

1xx/2xx 3xx/4xx 5xx/6xx/7xx
Not applicable to these parts.

It is noteworthy that corrected silicon exists for the 5xx/6xx/7xx family but not the 3xx/4xx and that this issue does not apply to the 1xx/2xx family. I had hoped the errata would say more, but it does not. At the 2012 Master’s Conference I learned that this issue has never been observed when the cache and prefetch are set up normally. This explains why I have never seen this issue and why the vast majority never see it. If you are really paranoid, then implement the work-around, but for the majority of cases, I don’t see the point (PS: That’s my opinion, NOT engineering advice!)

The second condition was an issue with a double data write with interrupts turned on. This was indicated as mostly harmless except when the write target changed it’s state based on a write, like a UART, SPI port etc. The errata were:

1xx/2xx 3xx/4xx 5xx/6xx/7xx

Again, only the 5xx/6xx/7xxx family of parts has a note regarding a corrected revision, so this fix must still be forthcoming in the other two families. Also note that turning off interrupts during the write is now feature in addition to using DMA. And a correction to the errata is that the I/O port Toggle registers where left out as potential trouble spot. Double writing the Toggle register would create a very short spike rather than toggling the desired data bits.

One final word is that this article can never be the final word. I urge everyone working with a microcontroller to go to that chip’s web page and download and carefully study the published errata on that chip. As always; it’s what you don’t know that can hurt you.

Don’t forget that your comments and suggestions are most welcomed.

Peter Camilleri (aka Squidly Jones)

Impressions of Masters 2012 [Updated]

Welcome to Masters!

First a disclaimer. There is no way that the Microchip 2012 Masters Conference can be summarized here. It is simply far to vast in scale and extent to do it justice. Instead, consider this to be a series of first person impressions, notes, recollections, and anecdotes.

To put things in perspective, this was my seventh time attending the Masters conference. Previous years attended were 2000, 2001, 2002, 2004, 2009, and 2011.

.

The front door!

I’m not quite sure how long it’s been there, but this year the conference was held at the luxurious J.W. Marriott. Here’s the grand front resort entrance. It goes without saying that the hotel, its rooms, conference halls and public spaces where all luxurious and well appointed. The conference included three sumptuous meals a day with beverages, fruit and “treats” for those who got the munchies in between study courses.

.

The “swag” of the year!

As is common at such events, all attendees went home with a little “swag” to remember their participation. In past years, little technology demos were often given out. The last few years this has been replaced by a note book, polo shirt and course notes thumb drive combo. This is a little disappointing as the gadgets were always fun, but to be honest, other than some fun playing with them, not much came of them, so the cost savings is sort of understandable, even if it is a bit of a downer.

As said earlier, this is my seventh Masters. Each year I have the same problem. There are many more courses that I would like to take than there are time slots in which to take them. This year there were 36 courses offered covering a wide range of topics. That’s too many to list so instead here is the Masters 2012 Event Guide. The class list is on pages 11 through 31. As for myself, I was kept busy learning about:

  • Upcoming developments in Microcontrollers and Development Tools.
  • Learning more details of the FreeRTOS software. I was fortunate enough to win the programming challenge and got a copy of the book Microchip PIC32 Edition of the FreeRTOS user’s manual. I’ll be doing a review of that soon.
  • Using the Microchip Graphics Display Designer (GDD-X)
  • Robust I2C communications with the PIC I2C peripherals.
  • USB: Both the Generic Driver and CDC class devices.
  • Bootloading, Application Mapping and Loading Techniques on a PIC32.
  • An examination of Advanced Touch Screen Technologies: Projected Capacitance Touch.

As if that were not enough, the time slot between the end of studies and dinner was also utilized each evening.

The Keynote Address (Picture from Facebook)

 On Wednesday there was the interesting (OK not THAT interesting, but were did I have to go?) keynote address by Steve Sanghi, the CEO of Microchip. Mr Sanghi has a direct, down-to-earth approach that is most refreshing and while not edge of your seat stuff, it was still very informative to hear the corporate perspective.

On Thursday, I was delighted to see the return of Don McMillon! Don is the self-proclaimed “Funniest Engineer in the World!”. Even though this was his second time at masters, the show was mostly new material and I had a great time. With all the serious engineering work going on, some levity was welcomed.

And then there’s Friday… On Friday, there was a Casino Night. During this event, I made the earth shattering discovery that I truly suck at poker. Thank goodness the $1,000 I lost was only play money (Unlike some 2012 USA Presidential candidates, I do NOT make casual $10,000 bets!).

Finally, I have left what is possibly the best part for last. After dinner each evening, there were semi-formal discussion groups with various microchip teams in attendance to answer questions. I attended the XC16 and XC32 discussions. I learned a great deal of useful info. Here’s a sampling of some tasty tid-bits:

  • XC32++ is ready! That’s right C++, with a FULL library by Dinkumware, a highly respected library specialist vendor. XC16++ is still in the very early phases and is rather much much further off.
  • New PIC32s are coming that will support new modes that are faster and more compact than the current MIPS16 mode. Support is coming for higher speeds and much larger memory and a external memory interface. However, no target dates were given. Sigh… Marketing!
  • One surprise was getting more clarity on the Errata Issues that I have written about before. It now seems that the first issue (with the prefetch cache) has only ever been seen with highly unusual configurations, not used by Microchip tools. Most developers need not worry about it. The second issue (with double writes to I/O registers) is more widespread and needs to be taken seriously. In the mean time, new silicon is coming out very soon (weeks?) that address these issues. We should be seeing an Errata Update in a little while and I will post it here too.
  • As the session was closing, somehow the discussion went to the topic of the use of assembly language by C programmers. To make a long story short, I indicated that the ONLY time I have ever used assembly language was to provide the special interrupt prologue and epilogue required by the FreeRTOS to save memory. At this point it was suggested that this was better done by the compiler itself and the Richard Barry (of FreeRTOS fame) should be contacted to see how progress could be made on this front. We’ll see what happens, but that would be a cool addition to XC32.

There was one important thing that was missing though: There was no break out session for the XC8 compiler group. Perhaps they were too busy?

It seems that Santa works for Fedex!

Oh and I forget… The really final final, even better thing about all the masters conferences is the deep discounting of developers tools. I felt like a kid in a candy shop with all those wonderful toys to contemplate! I admit that I had to restrain myself to a few choice selections. I’m sure I will be writing about them more very soon.

Perhaps I should start doing a mail bag segment on a You-Tube channel where I open my (interesting) mail? Then again, perhaps not.

.

As always, your thoughts, comments, suggestions and encouragement are most welcome!

Peter Camilleri (aka Squidly Jones)

PS: I was giving some thought to the idea of FreeRTOS prologue/epilogue support in XC32, and it seems that it need not be complex.One idea would be to support the idea of an “Interrupt Stack” which would be used by ISRs. This option would support FreeRTOS and provide benefit to any case where multiple stacks are in use. This would be an easily set up option for compilers and the linker could allocate the space in a manner similar to the way the heap is currently allocated.

[Update] Shortly after the conference, I exchanged emails with Joe Drzewiecki of Microchip regarding this idea. This correspondence follows:

Hello Joe;

I want to thank you again for a wonderful Masters Conference and especially for the very informative break out session on the XC32 compiler. The discussions covered a lot of ground and I learned a lot of new stuff.

I was thinking about the prologue and epilogue code for ISRs in FreeRTOS, and it occurs to me that what is involved here is the use of a special “Interrupt Stack” area. A stack set aside for use by ISRs. Implementation of this concept would be of use beyond FreeRTOS and include any system that runs multiple stacks.

I have updated my web site with a review of Masters 2012 here: http://teuthida-technologies.com/ and included a bit about Interrupt Stack support in XC32.

 I look forward to future developments;

 Best regards; Peter Camilleri

 and here was Joe’s reply:

Hi Peter!

Thanks for the props and the suggestions. We’ve had a very spirited discussion about your prologue/epilogue suggestion (go figure! :).

We’ll continue to discuss this, but may not act on it right away. There are many subtleties to it.

 Hope to see you next MASTERs,

Joe

Thanks Joe; It’s good to know I can still stir things up! 😉

Magnus Errata Update

I am glad to report that Microchip has updated its PIC32 errata to add a little more clarity to the situation. These issues were discussed in previous posts Magnus Errata 1 and Magnus Errata 2. The specific clarifications are:


As always, I advise that you download the latest errata data for your particular PIC from the Microchip website.

Peter Camilleri (aka Squidly Jones)

Magnus Errata Part 2

In the first part of this series, Magnus Errata Part 1, we looked at the problems caused by reading data from flash memory while interrupts are in use. In this second part we examine the more serious issue of double writes to sensitive I/O registers. Here is the issue as presented in the errata:

Double Write Issue

In this scenario, a write operation is duplicated when it is interrupted at just the wrong moment. Now, in most cases, this poses no problem. A = 3; would simply assign 3 to A twice. However, some I/O registers are sensitive to multiple writes. The data registers for the SPI, UART, I2C, PMP, and GPIO Toggle will not perform correctly if double write occur.

The answer given, was to use the DMA controller to do the writing to these registers. This is a most draconian and unworkable “fix” for the problem. It replaces a simple write to a register with an enormous amount of code to set up the DMA to transfer the data byte. And further since DMA controllers don’t like to be shared, a whole extra layer of mutual exclusion logic is required.

To make matters worse, I just don’t trust this report! If this issue were as bad as the docs make it out to be, you would expect a lot of problems. I mean the issue is I/O and interrupts! Where is the out cry? Why does my own code work without any trace of error? Here’s what I saw in the forums; rpg7 wrote:

“I am running a project the has 4 SPIs clocking in framed mode at 2.048Mbit and a bitbashed uart (No USART pins left if all SPI in use) running at 57600 baud. The bitbashing runs interrupts at 172800 interrupts per second and the SPIs shift out 128 bytes at a time 8000 times persecond. The BB UART has highest priorty so it is interrupting the SPI interrupt continuously. Also have not had any errors so far.. Got my fingers crossed. “

Marc Coussement wrote

“Problem solved !!!

Confirmed by Microchip

Read errata Issue 44

First read the errata and look [at the] work around.

Conclusion: …………… stop using PIC32″

Mikael wrote:

“No, it’s a mayor issue, CPU double writes (by mistake) to peripheral, think about it.. uart, spi i2c….

And the workaround is really ugly.

bsder wrote:

“Do I have to disable *all* interrupts? Can they just be masked out? At peripheral level or global level? What about software interrupts? (always occur at a particular pipeline stage and may dodge the bullet) What about timer-based interrupts? (probably always occur relative to a clock edge and probably *don’t* dodge the bullet–they can float through different pipeline stages).

If I put on my microprocessor designer hat, it’s probably that the peripheral commits a pipeline stage before the MIPS32 actually commits. If that’s the case, simply masking off externally driven interrupts (either directly per unit or globally) should be sufficient and won’t require a massive draining of the pipeline.

This severe an errata needs a lot more *public* information and precision.”

and

“[snark] So … I can shut off interrupts for a cycle or two, or I can completely re-architect my application to use a poorly documented peripheral which has driven some quite competent people on this board absolutely mad. And that’s if I’m not actually using the DMA engine. Uh, yeah, I’ll get right on that Microchip… [/snark]”

Finally the moderator added:

“Microchip understands importance of having this issue fixed and is actively working on it. Please check with your local Microchip representative on availability dates and obtaining early samples (if desired). “

I know that Microchip will track down the cause of these silicon bugs and fix them. In spite of this, I know that we can’t just bury our heads in the sand and wait for the problem to go away. It won’t. Ever! For quite some time we will be living with a PIC32 population that includes a lot of defective chips. We need useful, feasible work-arounds, not wishful insanity, because these corrective fixes will be needed for some time.

That’s why I was pleased to see this from Stampede:

“Errata #44: This issue is very similar to errata #43, but in this case interrupt has to happen at exact time as you are writing to a peripheral. Depending on the application (how often peripheral is getting written and how often interrupts are occurring in the system), user may not see this issue very frequently. It also depends if their system can handle double write case, if it happens.

While workaround maybe an “overkill” for some applications, it is a valid workaround and it will prevent double write to a peripheral.

Disabling interrupts while performing write to peripheral is another valid workaround and we will update errata to state this.

So the errata seems not to be too severe as it might seem on the first sight…

Cheers Stefan”

Well, I’m not cheering yet, but controlling interrupts around writes to sensitive registers is a lot more feasible than hauling out the nastiest peripheral on the block to copy over  just one byte.

I was planning on waiting for Microchip to update its errata docs, but that has still not happened. So, I am publishing now and will update these postings as more information becomes available. As always, your comments and observations are welcomed!

Peter Camilleri (aka Squidly Jones)

Magnus Errata Part 1

Most of the time, microcontroller errata detail some minor problem with an obscure corner of the chip that only affects a few people. Sometimes though it’s much more serious. Recently, Microchip released errata documentation, covering pretty much the entire PIC32 line, with not one but two major CPU issues. The scope of these issues affects the vast majority of PIC32 projects planned, under development and in the field. This is serious stuff. This article covers the first major issue: Reading data from flash while interrupts are in use.

Flash Data Read Errata

In a nutshell this issue states that when reading data from flash memory (as opposed to fetching instructions from flash) there is a chance of a serious error (data bus exception) if interrupts occur at inconvenient times. Let’s see if this is serious. To have a problem, an application would have to read data from flash and it would have to use interrupts. Without any data to back this up, but based on my years of experience, I would estimate that this issue could affect almost all PIC32 applications!

Given how serious this problem seemed to me, I was perplexed that there was not a lot more being said about it on the discussion forms. So I raised the issue in a posting. This generated a fair bit of interest. For starters, I was NOT the first on the block for this issue. In my defense the original thread was called “PIC32 SPI fail only at PBclk= 40 Silicon Problem??” which is not exactly shouting “memory errata”. I was correct that many others were concerned:

kalpak wrote:

“For a new project the scary and vague errata drove me into the arms of NXP”

bsder wrote:

“…

Errata 44 (for the 5/6/7 series) lacks a *LOT* of information. Why can’t we just shut the interrupts off? Is the handler the issue? Is the specific mask bit the issue? Is the overall interrupt an issue? The fact that we *don’t* see these every single time says that it’s not *just* an interrupt issue going on here.

In addition, why should their workaround be any more reliable? Maybe it is, but there is a whole bunch of arbitration issues that come in, and I’ve sometimes seen quirky DMA behavior. The fact that they couldn’t interface SPI to the MIPS core certainly doesn’t give me confidence in their DMA engine.

This one is bad. 🙁

crosland wrote:

“Does anyone form Microchip monitor these forums? What’s the plan to fix the most serious CPU errata? It’s simply not acceptable to have to disable interrupts when reading flash nor use DMA to access peripherals. Imagine the task to go through and sanitise the application libraries…”

Finally after nearly a week, the moderators took notice and made the following statement:

“One explanation why most people do not see DBE errata in their applications is that it can only appear if both cache and prefetch are enabled. By default (on chip reset), both features are disabled, and out of the box start-up code from Microchip doesn’t enable them. So, one has to understand these features and initialize them to enable them (or use provided PLib functions).

When both features are enabled, application performance will increase, as much as double (average execution time will be half, vs the same app without cache and prefetch turned on). However, if only one of them is enabled (as workaround suggests), performance increase will be slightly less (on average 90% instead of 100%).

Very minimum impact.

Microchip understands importance of having these issues fixed and is actively working on it. Please check with your local Microchip representative on availability dates and obtaining early samples (if desired).

Well I guess that helps, except I have always fully enable all the speed-ups available, so why have I not had any problems? Still, it got me thinking; there are two possible courses of action: A) Disable the Prefetch or B) Disable the Cache. Which choice would do less damage to system performance? To help understand this I wrote a test program that drew 100,000 circles on a graphical display. I then tried four sets of options:

Test Execution Time % Slower
None Disabled 79.1
Cache Off 84.3 6.5%
Prefetch Off 82.3 4.0%
Both Off 120.2 52.0%

My data seems to support the official line. It looks like performance is slightly less affected by turning off the prefetch, but not by much. Just turn (or leave) both off. The only remaining sticking point (in this case a point shaped 800 pound gorilla) here is my inability to make this issue happen at all! If it is so serious why do I never see it? I still am no closer to an answer. I don’t know what to say. Clearly there are other conditions/setting/configurations that play a role in this issue that are not called out in the errata. Without more complete information, informed choices are hard to come by. However, safe ones are not. Given the slight impact, it’s safe to say that the instruction prefetch can be turned off with only a minor ding in performance, and for now, that is what I shall do.

Due to the dynamic nature of the situation, I have NOT included links to errata files. For up-to-date information, please go to the Microchip website and look up the PIC32 of interest.

As always, comments and observations are welcomed.

Peter Camilleri (aka Squidly Jones)

Errata errata!

To paraphrase (poorly): A funny thing happened on the way to the blog! This article was to have been about the interesting (really!) topic of calibrating a touch screen and some of the unusual twists and subtleties involved with that process. Along the way though, something came up: Errata!

In working on my code, it occurred to me to check to see if there were any errata outstanding on the PIC32MX460F512L processor I was using. I was a little alarmed to find no less than 68 errata items for this chip. I really should not have been. Given the incredible complexity of the part, it should be off no surprise that 68 defects could be found, and most of them were very obscure. One point did catch my eye however. Here it is from the Microchip docs:

Not to get too detailed at this point, but my code fell exactly into the above scenario. I constantly switch between 2 pins to output to generate a voltage slope while the other 2 pins are analog inputs to read the voltage. Since the issue and its fix were from the maker of the chip, I felt safe adding it to my code, even though it seemed to be working fine already. As instructed, I added code to set the pins to “0” before setting them as inputs and patted myself on the back and went on to other parts of the code.

Until it came time for testing… Suddenly, my well behaved code was totally flaky! While touching the screen solidly, the code was reporting numerous make and break events that were not real. To make matters worse, I had made a lot of changes and due to a re-install of MPLAB-X, I had lost my backup history. Debugging did reveal real bugs in the logic which were soon fixed, but the phantom makes and breaks still persisted.

I eventually tracked it down to a puzzling observation. Most of the time, everything worked fine, but sometimes, the sense input pins were jammed in output mode with a value of “0”. The results of my analysis was that the recommended fix for issue 62 actually causes a problem! I removed the errata #62 fix and the problems went away. What a relief; And that’s why my blog post was delayed 😉 Some lessons (re)learned:

  1. Errata recommendations can be wrong too.
  2. Test often and test fully. Repeat old tests! Especially after unusual changes.
  3. Use a version control system separate from your IDE and keep backups.
  4. If it ain’t broke, be really careful before you “fix” it!

Peter Camilleri (aka Squidly Jones)