TI PurePath Audio Sender/mixer

[Quiggers]

I'm new enough here, but i thought it'd be fun to share my uni FYP
and having watch Dave's tear down of a zoom recorder and seen the same codec.

the central component is Texas Instruments PurePath cc8531, its a 40 pin QFN but comes on a break out board when you grab the development kit.
http://tinyurl.com/d9v6g74

This is controlled via SPI from a PIC18F2455 which also generates a GUI on a gLCD again over SPI.
All running at 3.3v regulated from a pp3 9v battery. A 4button keypad drives the interface. Incidently, the pic was programmed using FlowCode but i had to do some boost C as the graphics library for my screen wasn't supported. It's the second project i've used flowcode for and i like its speed but at times find it too far removed from the chip, luckily it supports a C variant and also allows assembly commands if you're into that kinda thing.

Now while that was a bit of work, i've been having quite a bit of pain getting an audio codec going, obviously its a vital component. PurePath supports a few and I've plumbed for one off the compatible list an TLV320AIC3101, which Dave found inside his Zoom recorder.

The problem i've been having is the 0.4mm gauge of the damn thing.
So I've ordered a break out kit, with solder paste and stencil. How hard can it be?
Well here's the dinger, you need an oven you can trust, i'm the guinea pig for the oven here at uni.
I'm the dog being rocketed into space. and guess what? It hasnt worked out for me.

After a week off tinkering with the oven to get it to melt my leaded solder paste, i got it to melt, but at a whopping 235^o so i stenciled pasted and place my chip, poped the board in the oven and ............. set off the fire alarm, this place will smell of burnt pcb for some time.



So I was stuck but a nice engineer is letting me call round to his factory on monday, so hopefully that'll see me right

[Quiggers]

this is the gLCD i'm using, quite pleased with it, it doesnt have a library onboard so you have bit bang the graphics but the SPI bit and the backlight range swung me in their favour.
http://www.lcd-module.com/products/dog.html

i'm using the eadogm128e

one thing to note is the capacitors for the charge pump built in, the data sheet asks for tantelum caps but with them being polar i had varying success setting them up, so i searched for some ceramics of the same value 1uF, which is quite big for ceramic but oh did they make life easier.

[daedalus]

Hi,

You have 3 options:

a) stencil the pcb, place the chip and reflow with a hot air reflow system, this is fine for prototyping, just preheat the pcb with the nozzle far away, then bring it close for 30s or so until you see the paste reflow. Whilst the paste is reflowed tap the ic with a pair of tweesers, it should move, but snap back under solder tension. tapping down on the top at this stage helps clear any voids / ncs on pins. This gives a lot more manual control then the oven affords.

b) if you have extended the pads out from under the IC it is possible to hand solder under a scope at this pitch, using surface tension to draw solder under the IC. Its fiddly but quite doable, tacky flux and a few practice runs are needed though.

c) reflow with oven.


if you want to get C right, then there are a few things to test.

1) put the oven on a fixed temperature, say 200C. Leave it to reach that temp for a few mins, then use an IR thermometer to verify its at 200C. This is to check that its regulating correctly, and that its calibration doesn't suck (some of our unis cheap Chinese ovens are easily 50C out).

2) put a junk pcb in with your paste and some jellybean parts. Bring the oven temp up *slowly*, and watch the board, note the temp when it reflows at. Remember that the parts will take time to reach a common temperature.

It sounds to me like you didn't preheat for long enough, so everything wasn't at the same temperature, then you ramped things up quickly to get it to reflow. Problem is by the time the solder paste reaches reflow temp, the rest of the board is burning.

The solution is either to preheat for longer, or raise the preheat temp to closer to the reflow temp (so less thermal differential across board during reflow stage).

[Quiggers]

the oven has a 120 sec pre heat but i reakon its thermo couple is goosed, anyway i got the chips mounted using the hot air gun method at a local firm, they were excellent and wouldnt accept any cash plus they gave me a full tour of their assembly lines.
They're a cleverly named company in shannon industrial estate,  and i'm very thankful for their help, they even x-rayed it to check everything was honky dorey.

since then i've been programming my pic chips and finding errors in both the pic's data sheets and the purepath data sheet.

the worst offender being two pins labeled as bi-directions tri-states on the pinout diagram but upon them not working and delving into the data sheet, i found they were infact inputs only, as luck would have it , i had pcb'd the circuit already which was using them to control resets, luckily i had two other pins free and a bodge jumper wire or two later and i was back in action.

[Quiggers]

So i kept getting an error code from the purepath device over SPI, the error when decoded read as follows "SPI error"

further reading show that the TI purepath is very picky about when to start the SCL, it's the slave device on the SPI bus so of course it should be picky.... right??

well contacting TI offered a solution, they have an interrupt system, great! so how do i use it? It's not described in the documentation, so I hook a scope up to the interrupt pin, sits there high and noisy , regardless of operation mode, a guess leads me to try a pull down resistor, ok it's toggling now, so i pull CS low and the interrupt sits low, hmmm.

By my understanding this pin was supposed to tell me when i could start the SCL but the line dies as soon as i try to start SPI coms.

Further reading = lots of people in the same boat.

TI suggest their own range of MCU's instead of a PIC, but that is hardly the issue, the SPI on the PIC is driving the gLCD without a bother.

As things stand:
The project is capable of transmitting audio across a Purepath network, so the devices work once paired and the audio codecs work.
The GUI and gLCD are complete, there was an issue with running the keypad from the +ve supply , but using a spare PIC o/p to enable the keypad solved this, basically applying +ve supply to PIC pin A4 shorted out the capacitors on the charge pump for the screen, so now the keypad is only enabled as it is being scanned for an input, leaving the rest of the time for the capacitors to charge to their required voltages for the gLCD.

So software is all that remains to be tidied, the non existent info on the interrupt opperation has me guessing in the dark, as the purepath device needs to finish any I2S, I2C and Wireless action before an SPI command can be read, I've assumed the device will interrupt the PIC, as a "Hello, I'm ready", but watching it on a DSO and setting my pic to trigger on the -ve edge of an interrupt did not resolve the problem. So this is still to do.

Time is up and the project was submitted, landed me a high grade for it so i'm pleased with the outcome. But it is still bugging me that i didnt get it 100% functional, to the point where i'm contemplating buying a Purepath Dev kit for nearly €300. I hate leaving things not finished, maybe TI know this and have baited me to boost sales? At the moment I'm in a dilemma, the project i built is the property of my Uni, as is the Dev kit i was using. So in order to complete this project for no increase in grade, do i spend on the Kit, and then recreate my PCB privately with no access to Uni PCB facilities, order some codecs, a screen more break out boards etc or do i just chalk it down to experience and move on?

[T4P]

Design your own with other processors, i'm not a fanboy of ARM or something but really AVR and PIC is pretty expensive for what they do

[Quiggers]

I was reading a spec sheet for another TI wireless cc3000 chip, it said it works as an SPI slave but only at 16MHz, wonder was it the same for the cc85xx range, i'd never have gotten that data rate with the PIC which was running at 19.66MHz, SPIdiv4 gives a data rate of ~5MHz. No way of knowing now but it seems like too large a bandwidth for control messages, understandably the cc3000 range use SPI for data transfer so require the bandwidth.

I'm asking the uni can i purchase my project minus the radios, if yes i can tinker further using an Anaren cc8520 radio module, if not i'll draw a line under the whole thing.
Next on my list of things to do / learn is the arm cortex m4 chips and embedded linux, i've ordered a dev board and lots of reading material. Wish me luck