Posted by: Claudio Carbone | 13 February 2012

Fighting the Compiler (MPLAB C32)

Luckily I have some relaxing newage music going on (Mono Lake from Rick Wakeman)…
Otherwise you may hear CNN talk about a sudden explosion in Rome.

Since I began working on my first big project (all the more big because I’m working solo) I learned a few things, and had to put others to use.
So I have this complex program running on a PIC32, sampling sensors, keeping the battery in check, writing to SD, and enabling SD access via MSD (Mass Storage Device class) when connected via USB.
Debugging this is sometimes cumbersome as I don’t have a serial terminal, and hooking one up is a bit of an hassle as the thing already has an UART used for the GPS.

Why not use an LCD to output relevant debug messages?

Nice idea, but my mind wasn’t done yet:

Why going parallel, it’s a mess! Let’s go serial.

There started my I2C epopea.

128x64 Serial I2C Lcd

128x64 Serial I2C Lcd

So I2C is not that much complicated you see, it’s a serial bus essentially but with a medium access control and collision detection system, allowing multi-master and multi-slave configurations (contrary to RS232 and derivatives which only allow a single master and a single slave in hardware).
There are lots of tutorials out there, go pick one on google if you’re so inclined

Since operating the I2C requires a bunch of MAC operations (start, stop, restart, collision, ack, nack, and so on), you’d expect and advanced micro had a decent peripheral able to do that.
I expected the same, only to get a big delusion when I read this passage on the I2C manual

DS61116D-page 24-33
The I2C module does not allow queueing of events

What does this mean?
It means there is no provision in the so-called Peripheral to help the programmer achieve what he wants: communicate with a device over I2C.
Everything MUST be accomplished by the programmer: he has to check the status of the bus, the ack and nack of bytes both while sending and while receiving, he has to take into account the time needed by each operation…
Either you go polling or you go interrupt-driven, you have to do it all by yourself.
How can they even call a bunch of macros a “Library” ???

So after this shot in the heart, that meant a lot of work more than already anticipated, came the real deluge: nothing worked.
Nothing at all.
No macro worked, not even the one that should turn on the module!

What this means is: low-level register coding remains the only way.
So thanks to my new printer I proceeded to print the entire I2C manual (two faces per page just to save some tree branches) and started working on writing my bare-metal code, flipping switches here and there (metaphorically but also quite materialistically as SFR bits are in essence just switches).

And what came out was a first attempt at a library that was also supposed to work but… incurred in a nice undocumented feature (from now on known as DARN BASTARD BUG): a simple jump instruction (the end of a while loop) had some mutations and transformed into an evil Reserved Instruction triggering a General Exception, but only if a start condition was issued on the I2C module!

If the Start was not issued, the while did work just as it was supposed to.

This has been driving me mad for 2 days now: not only the fact that a so called Library is in essence just a collection of configuration macros and than a useless piece of code, but the fact that I could not find any decent way of getting that darn I2C module to work as it is supposed to.

This resulted in 3 tickets (for now) filed with Microchip support.
I hope to see the light of day sometime soon…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: