TRAXMOD

Developer's Area (schematics, firmware, etc.) FAQ Support Forum Project Background YouTube Demonstration Resistor/PWM Hybrid DAC SD Card Benchmarks SD Cache Methodology SD Theoretical Limits SD Card Interface MOD Effects BBMICRO Protoboard LPC2103 ARM7TDMI-S

Nectarine Demoscene Radio United Trackers MODs in Memorium The Mod Archive Amiga Music Preservation

TRAXMOD is a small digital audio player using the Microchip PIC32 high speed microcontroller chip (previous versions used NXP LPC2103 ARM7TDMI microcontrollers). Currently, TRAXMOD-PIC32 can play raw wave audio streaming off of a FAT formatted MMC/SD Card at 44100Hz, 16 bits, stereo (with FLAC and multichannel MOD playback being future goals). The older TRAXMOD-ARM can play raw wave audio and 4 channel MOD files streamed off of a FAT formatted MMC/SD Card.

For more information about TRAXMOD, please read the FAQ. To see the TRAXMOD-ARM player in action, check out our YouTube demonstration video. Firmware source code, schematic diagrams, and board layout files can be found in the Developer's Area.

Archived News

12-27-2008

Firmware v0.7.8 released in the Developer's Area for TRAXMOD-PIC32. Huge number of changes in this release, hopefully its not too buggy. Using my best SD Card (Dane-Elec 2GB), total power consumption of the device is under ~16mA at 3.0VDC (1.5mA for SD Card, 6.5mA for PIC32, and 7mA for PCM1770 DAC)! This is the best case scenario; almost all other SD Cards produce far more power consumption than this.

Other items of interest for this release:
• UART output is now interrupt driven, allowing text to be printing in the background while other code is running in the foreground. Added a current playback time display to the serial output.
  
  
• MMC/SD Card SPI DMA read code has been refactored to allow for putting the CPU in IDLE mode while the MMC/SD Card is being read by the DMA engine, reducing power consumption of the PIC32 below 7mA while playing. Syncronization between the MMC/SD Card DMA read and the DAC DMA audio interrupt service routine is now achieved to avoid bus contention that could oridinarily crash the MMC/SD Card DMA read. A big chunk of timing critical code is now written in 100% MIPS assembly language to insure tight timings.
  
  Still not totally happy with this code because it only supports reading single 512 byte block aligned chunks at a time, but it's really hard to get it to work reliably at all with how touchy the timing is when trying to achieve ultra low power consumption.
  
  
• A new low memory, fast file access layer has been added. Now a player codec can completely bypass the clunky EFSL file system during playback and just use the bare MMC/SD Card directly, while still maintaining compatibility with FAT file systems and fragmented files. Basically, this layer temporarily uses the EFSL before beginning playback to figure out the actual disk address of the file being played, and generates a small map of fragment blocks to disk addresses for fast lookups later on. Being able to access the disk directly with known access latencies is essential for future MOD and FLAC codec work, which needs to minimize RAM usage as much as possible while still requiring FAT compatibility and really fast reads.
  
  Someday, maybe this layer can completely eliminate the use of EFSL to save even more memory, but that's a big project.
  
  
• Improved memory management code. The audio buffer is now dynamically allocated using all remaining memory after player codec memory has been allocated. This is a pre-requisite item for future support of multiple playback codecs that will need to allocate memory differently from each other (RAW, FLAC, and MOD's). The audio buffer is also always allocated at the end of the dynamic memory heap, with the tail end landing in the same location in memory everytime, allowing for future gapless and cross fade playback capability while switching songs.
  
  
• The RAW player's playback loop has been re-written from scratch. The new code is much tighter and cleaner, making use of the above architecture improvements. Unfortunately, there is a little junk audio being played between songs due to 512 byte block mis-alignment at the end of audio files. Eventually, that will be fixed when we finish writing gapless playback support for this new player architecture.

Okay, maybe PIC32 is not -quite- as awesome as I was thinking last month. For the Christmas break, I've been re-writing the raw audio player code so that I could try to do something useful with the CPU while the SPI DMA transfers more data off of the MMC/SD Card. I got it working, sort of, but the SPI DMA transfer occasionally goes into SPI receive overflow state and everything comes to a grinding halt. Ugh.

After playing with it for days, it seems that there is no way to guarantee the receive DMA channel will always have bus access when it needs to read from the SPI. When code runnning in the processor core accesses RAM, it blocks the DMA receiver from using RAM, and sometimes there just isn't enough time available between SPI reads if the processor is constantly blocking access to the bus for RAM access.

I've tried messing with the bus arbitration modes to give the DMA controller more bus priority. Unfortunately, none of the modes available give the DMA controller top priority to the bus 100% of the time, so that doesn't completely solve the problem. I've tried setting the processor core to the highest setting of 7 FLASH wait states, slowing down code enough to leave the bus free once in a while for the DMA controller. That helped, but it is still possible to write code that crashes the DMA transfer by doing back-to-back RAM accesses for several instruction cycles.

Unfortunately, when writing code in C, the compiler will often generate back-to-back RAM accesses under the hood and there's nothing you can do about it. The only sure way to avoid crashing the SPI DMA read transfer is to simply do nothing with the processor while the transfer is in progress (busy spin loop), or manually schedule RAM instructions far apart by writing code in 100% assembly language. Lame.

On the plus side, my new code is still getting more and more efficient than any of the previous code. I'm now thinking I could be able to break the 7mA mark while playing raw audio.

PIC32 is really, really, awesome. I finally delved into the bus matrix control registers and some more of the prefetch cache features in more detail, and now I've got the microcontroller playing raw audio while only consuming 10mA of current at 3VDC. Wow!!

Firmware v0.7.7 with these low power improvements is available in the Developer's Area. I was having some trouble with the SD Card DMA read code in v0.7.6 occassionally crashing because the receiver DMA channel occassionally failed to read the incoming data register (SPI2BUF) in time, causing a lost byte to lock up the SPI, and killing playback entirely. It was a big mystery how to solve the problem until I started thinking that maybe the DMA engine was being starved of bus time slices by the processor core.

Looking into the bus matrix registers, we were using bus arbitration mode 1, the default mode where processor RAM access requests -always- pre-emp DMA access requests. That's bad news when trying to use DMA to fling data into RAM at the highest SPI baud rate with the microcontroller down clocked to 28MHz for low power consumption. This configuration doesn't make many clock cycles available between SPI reads, and the DMA engine -must- get a few clock cycles in to save each byte of SPI data between. If the processor core accidentally keeps the bus busy during the entire period between SPI reads, the DMA engine won't be able to save the data and boom! Data lost, SPI goes into overflowed error state, and everything stops.

Switching to bus arbitration mode 2 provides a rotating priority sequence, which periodically allows the DMA engine to pre-emp the processor core for bus access. This mode seemed to improve DMA reliability the most.

At 28MHz, the PIC32 should be able to execute code straight out of FLASH without any wait states because the PIC32 FLASH is spec'ed at 30MHz. But when reading data using DMA, I'm currently just going into a busy loop waiting for the DMA engine to complete, which wastes power and also takes away bus cycles from the DMA engine. Instead, I now configure the PIC32 for the maximum of 7 FLASH wait states, slowing down the processor's execution, which in turn gives the DMA engine more bus cycles to access RAM. After the DMA block read is done, we return to 0 wait states to give the processor core full speed execution for the audio processing loop (converts 16-bit unsigned/signed to 32-bit signed for the DAC).

While I was in there, I also noticed that previously I wasn't marking my program memory as cachable. Marking kseg0 as cacheable seemed to give a performance boost and saved power at the same time.

There is also a bit in the cache configuration registers to set RAM accesses to 0 wait states. It was set to 1 wait state by default previously. Changing this seemed to improve things slightly, but not nearly as much as the FLASH caching and FLASH wait states did.

In other news, I noticed that there is quite a bit of variation between SD Cards' power consumption. Previously, I was just looking at my Kingston Patriotic Multipack 2GB SD Cards, which draw a huge 23mA while playing in my TRAXMOD. Ouch. On the other end of the spectrum, my sweet Dane-Elec 2GB card draws just under 1mA while doing the same thing! That card is really great, it has the lowest power consumption, lowest block seek access time, and it even successfully overclocks to 28.224MHz SPI baud rates. The other really good card is a Toshiba 2GB SD Card that has very similiar power consumption, seek access time, and overclocking abilities.

Firmware v0.7.6 posted. This release provides a fully interrupt driven, DMA based MMC/SD Card sector reader. Previously, waiting for the SD Card to return the start of data token was done fully CPU bound. Now, this release uses the PIC32's DMA pattern match mode to let the DMA engine do most of the waiting around for the start of data token.

Power consumption is mostly the same, maybe lowered by 1mA at most. The code still doesn't do anything useful in the foreground while the DMA transfer is going on. But making the whole transfer interrupt driven and DMA driven opens the door to improved efficiency soon. It should especially help with MOD playback down the road, as the data transfers can occur in parallel with the processor doing the audio mixing.

Firmware v0.7.5 available in the Developer's Area. This release adds some crude DMA based MMC/SD Card sector read code. Power consumption of the PIC32 is now down to ~18mA at 3.0VDC, that's even less than the SD Card is using!

Unfortunately, this DMA sector read code is not very advanced yet. It is currently blocking and just waiting in a busy loop for the transfer to complete rather than trying to do something useful while the transfer is in flight. It's still more efficient than the old code though, and that's why the power consumption went down. MMC/SD Cards have a variable length response period where they send back 0xFF for a while until they've retrieved the sector requested, then they send back 0xFE as a start token, and then you are finally allowed to start reading real data. I'm currently having a hard time trying to get the DMA hardware to take over handling this variable length response period thing. It has a pattern match feature that seems like it ought to be useful for this sort of thing, but so far I haven't been able to get it to do what I want. Might need to make some schematic changes to get it working most efficiently, or just give up and use the CPU for handling that part of the protocol.

Spent some time playing with the switch mode voltage boost circuit. This time, my version of the circuit uses a Si8424DB N-Channel MOSFET instead of a transistor, and this seems to provide better performance. It can easily double the input voltage, and go even higher, depending upon how much load current is being drawn at the output. A 3.3V zener diode on the output ensures that the output will not run away to voltages high enough to damage the ICs, a problem that could occur if too small of a load is being drawn from the output.

The Si8424DB MOSFET comes in a chip scale package with four solder balls on the bottom. It was a little tricky to solder sucessfully, but I think it will still be better than the TPS61024 QFN package because there are only four pins with lots of space in between them (plus two of those four pins are actually the same signal). The TPS61024 has too many pins spaced too close together, requiring traces too small and making it too easy to solder bridge pins together. The TPS61024 doesn't come with any solder on its pads, which also makes it difficult to solder without buying solder paste.

The next step after bootstrapping the microcontroller with this voltage doubler is to have firmware output a PWM signal to fully regulate the power supply to an exact voltage (say 3.0VDC). Our PIC32 has a built in 1.8VDC regulator for providing core voltage. We could probably use that 1.8V as a voltage reference for the DC-DC converter firmware so that the output voltage can be regulated to a specific voltage.

Instead of using a NC7WV14 RC oscillator to bootstrap the voltage for starting the microcontroller, another idea would be to add a small, cheap, lithium button cell battery to the board. It would be used just long enough to get the DC-DC power supply up to 3.0VDC. Using the button cell only for start up could let it last for a long long time before needing to be replaced. Button cells can be purchased extremely cheaply in 100 unit quantities, even more cheaply than the NC7WV14 chip. However, I'm not sure where to get a super cheap button cell holder yet.

The button cell idea would have the benefit of not wasting any running current into the NC7WV14, which is unnecessary once the microcontroller is providing it's own PWM signal for driving the DC-DC converter.

The new parts arrived. The 3M SD Card socket isn't too shabby. The card insertion and ejection is certainly smoother than the old Alps socket, which I like. It doesn't have much space underneath it, but there is a small rectangular cut out where surface mount resistors might fit. If we were to float the socket up above the circuit board a little bit with excess solder, it -might- be possible to sneak the PIC32 chip under there still.

Quickly hacked in some code for block addressing mode and tried out the SDHC card. It doesn't even run at 28.224MHz, let alone the 50MHz SDHC spec. Disappointing. Oh well, clock speed isn't everything. The block seek wait time is what seemed to affect MOD playing performance most on the ARM player, so we'll still have to wait and see on the SDHC card. I moved the SD Card testing table to its own page now. I also found a couple of my older cards worked somewhat at 30.1056MHz, which was interesting.

Firmware v0.7.4 released. Features:
• Master volume setting is saved to on-chip FLASH memory instead of the SD Card. (avoids blasting my ears when using headphones and switching to an SD Card that was last played on my stereo).
• malloc/free dynamic memory allocation is beginning to work. Heap size has to be manually configured unfortunately.
• UART2 is now outputting debug text at 115.2Kbps.
• Battery voltage is monitored via ADC and displayed to the serial port. Low battery is indicated by red LED. Low battery on power up will stop the player from attempting to play, hopefully avoiding blasting my ears with garbage.
• High speed/low speed clock switching no longer messes with the PLL settings. Instead, we use the internal 8MHz FRC clock for low speed, and leave the PLL for high speed mode. Hopefully this fixes power on audio pops and syncronization noises (difficult to test since it happens infrequently).

Worked at 28.224MHz
32MB	Kingston	Japan
128MB	Kingston	Taiwan
256MB	SanDisk	China
1GB	Crucial (Micro SD)	Taiwan
1GB	Lexar	Korea
1GB	Kingmax Platinum 50X	Unknown
2GB	Dane-Elec	Japan
2GB	Kingston Patriotic Multipack	Korea
2GB	A-Data 150X Turbo	Unknown
Failed to initialize at 28.224MHz
1GB	Kingston 50X Elite Pro	Taiwan

Been goofing around with clock speed switching. The PIC32MX340F512H SPI is really good, the best SPI I've used so far. I tried clocking at 28.224MHz and ALL of my SD Cards are working fine, except for one (25MHz is the spec'ed max for SD Cards). Pushing to 30.106MHz didn't work so great. Haven't tried my SDHC card since I don't have firmware to drive that yet (SDHC is spec'ed to 50MHz max).

UART TX is working now. Battery voltage monitoring using the ADC is also working nicely. Now that the UART is working, maybe I can debug my malloc routines to get dynamic memory allocation going again. It'll also help with getting DMA SD Card reads working. I stopped using dual DMA channels with chaining for the audio output so that I'll have more DMA channels available for maximizing performance of SD Card DMA transfers. The audio output stream is slow enough that DMA channel chaining doesn't seem to be needed to get seamless audio transfers.

Been looking at the FLAC decoder code inside the latest Rockbox firmware source code. It looks really small and simple, the Rockbox guys did a nice job cleaning up the codec for embedded systems. I tried compiling the code into my TRAXMOD PIC32 project and it seems to compile! Once the malloc and SD Card DMA reads are working, maybe I can try writing code to stream FLAC audio data into this codec. It would be totally sweet if it works.

Put in an order for 100 PCM1770 audio DAC chips, 11.2896MHz audio crystals, and 220uF audio capacitors. Audio specific parts like these probably aren't as high volume as more general purpose parts. With the economic downturn, there might be some risk that manufacturers of these parts could eventually halt production to reduce inventories. Things on the PIC32 board are looking so good at this point, I don't want to get stuck without the parts necessary for making more TRAXMOD boards in the future. I also ordered 10 of the new SD Card sockets to replace the obsoleted but preferred Alps SD Card socket I'm currently using. Was tempted to buy more, but the high price and untried new design kept me back.

Firmware version 0.7.3 posted in the Developer's Area. This version requires a PIC32 with DMA capability and 32KB RAM to run. It uses DMA channel 0 and 1 in chaining mode to seamlessly transfer audio data to the PCM1770 DAC through SPI1. It does not use DMA for reading from the SD Card yet. PIC32 power consumption is down to 27mA at 3.0VDC. Nice!

Desoldered the broken PIC32MX320F128H from my formerly working board and soldered in a new PIC32MX340F512H in its place, no sweat. Works, sweet! Now I'll be able to finally work on firmware to make use of sweet DMA. I also want to work on a replacement power supply circuit though... So many things to play with, so little time.

Firmware version 0.7.2 posted in the Developer's Area. This version tries to reduce some power on/off pop noises and also does some PIC32 power management tweaks to lower processor current to around 33mA average while playing a raw audio file. Still does not use DMA or full 32KB RAM yet.

Today I seem to have destroyed my formerly working PIC32MX320F128H player by trying to program it using an old PICkit2 programmer of questionable history. Doh! Not sure what went wrong yet, but even trying to program it with Real ICE doesn't work any more. So now I have one board with a working power supply but no processor, and one board with a working DMA capable processor but no power supply. Nuts. Maybe I'll have to try desoldering the TPS61024, flip it over, and dead bug style solder airwire leads to each pin to get a working power supply going on the DMA board. It'll be a lot of work and the end result will be ugly, but until I get some hardware working again, I'm kind of stuck at the moment.

Lately I've been kicking around ideas about trying to make a single cell switching power supply without the TPS61024. I breadboarded the simple step up DC-DC converter described here using a 0.9 to 3.6VDC NC7WV14 schmitt trigger inverter. This was able to start up by itself off of a single NiMH battery and produce enough output voltage to power up a microcontroller above 2V. In theory, once you can bootstrap enough voltage to get a microcontroller running, the microcontroller can take over and provide a variable duty cycle PWM output to further boost the voltage and regulate it to our desired 3.0VDC. If this idea works, it should be possible to ditch the TPS61024 and its difficult QFN package.

Arggh... Spent the whole weekend drilling and soldering my second TRAXMOD-PIC32 board (this time with the high end 512KB FLASH, 32KB RAM, DMA enabled PIC32MX340F512H). I started with the DC/DC converter circuit and it was working fine. Then I soldered practically everything else on and tested it again. Power supply no longer regulating to 3.0VDC unless I push down on the TPS61024 QFN chip hard. Doh! So I tried reflowing the solder around the TPS61024 to get a better connection. Disaster, the trace providing input power from the inductor delaminated and broke apart. Noooo!

Maybe the next hardware design needs to break the power supply circuit off into a separate circuit board that provides some nice big solder pads for attaching to the main player board later. This is lame having invested so much in the rest of the board, only to have the stinking power supply chip devalue the whole effort at the end. These TPS6102x chips are so difficult to work with... I need to be able to test the power supply boards throughly by themselves and be able to do replacements as needed. Sure wish TI would have made these chips available in a SOT23 package or laid out the pinout better.

In other bad news, the SD Card connectors I've been using (ALPS SCDA1A0801) have been marked Obsolete in Mouser's catalog. Now all they've got at Mouser are MicroSD (aka Transflash) connectors that have pins hidden underneath the connector (impossible to hand solder, solder paste reflow only) and SD Card connectors costing 2 or 3 times as much. Digi-Key has a cheap SD Card connector (3M5646CT-ND) that I'll probably have to switch to. While being a little cheaper, I still would have rather stayed with the ALPS connector because they made versions that leave enough room underneath the SD Card connector to hide low profile surface mount circuitry, which would have allowed further circuit board size reductions as we get more confident with the design working the way we want.

Firmware version 0.7.1 released in the Developer's Area. This plays raw audio on the PIC32 circuit board. It does not make use of much RAM, FLASH, nor any DMA features, so it should be able to run on any of the currently release PIC32 chips available (even the lowest end versions).

Stayed up all night long and got my first raw audio playback out of the PIC32 board! I can now confirm that the PIC32's SPI peripheral in 32-bit slave mode can directly feed the PCM1770 DAC audio data, with each word sent back-to-back, eliminating any need for generating a slave select signal like we had to do on the LPC2103. Sweet! This will also open up the possibility of playing back 24-bit audio on the DAC, which we probably couldn't do using the LPC2103's 16-bit SPI peripheral.

Well, unfortunately I haven't had much time to spend on the PIC32 firmware since the last update a month ago. I accepted a new job and spent most of the month furiously trying to finish my last project at my old job before leaving. Hopefully once I get settled in at the new job, things will start coming together on the PIC32 TRAXMOD project once again.

In other news, there have been a couple interesting releases in the microcontroller scene recently. First up is the video + chiptune microcontroller demo "Craft" by lft, a first place contribution released at Breakpoint 2008. Second, and to me a little more impressive, is the Uzebox, a DIY microcontroller video game console that has a nice Tetris clone written for it (see the YouTube video for a demo). Both projects use 8-bit ATmega microcontroller chips, which to me seem underpowered and obsolete with respect to dsPIC/PIC32 and ARM chips available today at roughly the same price... Hopefully this is just the beginning of a microcontroller scene that will further push the limits of future chips.

PIC32 firmware version 0.7.0 released in the Developer's Area. This firmware doesn't do anything useful yet, it simply initializes the EFSL library and the SD Card, then goes into an LED blinking loop. I have verified under the debugger that this firmware is getting the SD Card initialized okay and it is reading the SD Card's size correctly. So far, all of my SD Cards are working at 20MHz (including the 256MB SanDisk cards that don't work so good above 17MHz on the breadboarded ARM player).

No audio playback code yet, but seems like we'll be getting there pretty quickly at this rate.

I haven't had a chance to print new schematics yet, but I did reduce the R5 MCUVDD resistor from 8 ohms to 4.1 ohms on my test board. It was having too much voltage drop across my 10 ohm resistor that I was testing initially.

According to some posts on the Microchip PIC32 forum, a free student version of the C32 compiler is due to be released soon that removes the 64KB code size limit imposed by the provided C libraries. However, this new version will restrict compiler optimizations instead (after some 60 days of use). I would recommend downloading the existing C32 compiler v1.02 right now before it becomes hard to find. As long as you write firmware that does not link to the provided C32 libraries, I think you get no code size limitation imposed, so basically this is a full compiler for free right now (assuming you create your own libraries).

Preliminary schematics and EAGLE board layout files for the PIC32 hardware posted in the developer's area under the new "traxmod-pic32-0.7/" folder. Not everything has been tested yet, so beware if you decide to use these files to build anything... No firmware yet.

A bit of handiwork with a copper braided desoldering wire and the replacement DFN chip is installed. Unfortunately, a couple of the ground pads failed to solder back down (some nearby capacitor I was too lazy to desolder was blocking my way), so this one will have less heat dissipation capability, but enough of the important pins are soldered back down. Added a 10K resistor across VBATT and the lame POWER SAVE pin, and bam, the power supply seems to be working fine now! Sweet. I used a 3.0V TPS61024 this time, since I know the PIC32 runs at full speed even at reduced voltages. Hopefully the SD cards will work fine at this voltage.

After thinking about it a while, I'm now thinking (hoping?) maybe the reason why the TPS61025 blew up was because I was running it before soldering down one particular air-wire and writing firmware to drive the Power Save mode enable pin. It was left floating, which maybe caused the device to flip flop between PFM and PWM control modes at a high rate. It seemed to me that the device shouldn't have allowed anything bad to happen, but maybe leaving Power Save floating was a situation they didn't consider when designing the control logic. Anyway, if I can manage to unsolder the burnt out TPS61025 from my PCB without damaging things too much, maybe I can try again with a fresh chip, this time hard wiring the Power Save input to VBATT to force PWM mode at all times.

One interesting thing about the PIC32 is that it seems to be specified to operate at the full 80MHz speed while powered from a wide input voltage range of 2.3V to 3.6V (LPC2103 could only go down to 3.0V). Two AA or AAA cells will never reach 3.6V combined even freshly charged. After running the batteries down to 1.15V each, we will finally hit the 2.3V bottom range, and this is also near the end of the NiMH cells' discharge capacity. Perhaps it would make sense to power the PIC32 directly from the two NiMH cells, bypassing the DC/DC step up power supply. TPS61025 conversion efficiency of 96% is nice, but 100% (no conversion) might be even better. We'd still need a step-up power supply to provide full 3.3V to the SD Card and DAC.

In other somewhat unrelated news, Microchip has released a $99 Internet Radio demo board and associated App Note AN1128 that explains how it all works. It does not play MOD files (and never will, since it's based on a PIC18F). It requires a wired ethernet connection. Still, it's kind of cool to be able to listen to Internet radio without having the computer on. The best part has to be the really cute little OSD-2864ASWAG01 OLED display that I'm totally envious of. Unfortunately, it doesn't look like you can just buy the display from Mouser or Digi-Key, so I have no idea how much the display would cost or if it can even be bought in small quantities... Arg!

Board is etched, drilled, cut, and partially soldered. The TPS61025 switching DC/DC step-up converter seemed to work, at first. It was reading 3.29V output on my voltmeter the couple times I tested it. But when I went to plug in the ICD2 into the board, I noticed the TPS61025 was screaming hot. I turned everything off and unplugged everything, let it cool back down, but no luck. It must have popped the internal MOSFET for some reason unknown to me at the moment. Now it just gets hot and doesn't do any step up regulation on the output. Bummer!

So, I unsoldered the dual AAA battery holder since I won't be able to use that now. I hooked up an external 3.3V LDO and a pack of 4 AA batteries like usual and connected that to the board. No problem. Connected up the ICD2 and was able to use it as a programmer to flash some LED blinking firmware into the board, works! Sweet. Unfortunately, the ICD2 didn't seem to have the debugging feature working for my PIC32 chip yet because it always gave me a "ICD0031: API: Framing error" message when I tried to start my firmware in debugger mode. Bummer, but not too big a deal.

Next, I borrowed my brother's MPLAB REAL ICE and tried that with the PIC32. Wow, that sucker programs fast! I've never seen -any- microcontroller get programmed so fast before. In-circuit debugging seemed to work great on the MPLAB REAL ICE with PIC32, very fast too. Faster than the PIC32 Starter Kit, which was already pretty fast. Nice! With this much programming and debugger speed, I'm hoping we might be able to whip out some nice firmware with a lot less time wasted than we had developing the previous versions of TRAXMOD firmware.

Back to sweating over a hot soldering iron. Gotta get the rest of these parts installed and soldered down. And I need to make some sort of make-shift power regulator daughter board to replace the onboard switch mode supply that doesn't work.

BTW: The 64 pin TQFP PIC32 chip soldered down real easy. The circuit board I made has especially narrow pads for the TQFP-64. I was a little worried this might cause me trouble, but so far it has turned out great. I think it was even easier to solder down than my previous LPC2103 circuit boards. Solder bridges between pins were not frequent, and when they did occur, it was pretty easy to clear them just by wiping the solder around with the tip of my soldering iron.

Got it down to only 6 air-wires now. Transparency of the panelized PCB is printed out and looks pretty good (no smudges or hairline grain ink bridges). Tomorrow morning I'll try to clean up some of the dust in my work area to avoid possible contamination of the transparency image. Then it'll be time for lights out, UV exposure, and etching of a hopefully good circuit board. Exciting!

Been working like crazy on designing a TRAXMOD-PIC32 PCB. It's such a small, simple feature, but I totally love the PIC32's programmable internal pull-up resistor pins (LPC2103 requires external pull-ups). This has made it so much easier to route traces for each button, allowing me to do almost everything on a single layer PCB design, reducing component count and board space. I think I've got the whole thing routed now, with only 7 air-wires. Busy panelizing it now, and will hopefully spend the coming Fourth of July weekend etching the boards.

Submitted an order at Mouser for some more parts I'm going to need for this PCB, plus a few extra parts to play with for future projects. Damage done: $155.

Firmware v0.6.8 posted in the Developer's Area. This release makes some improvements to the filesystem code so that files with more than 7 characters will be picked up by the player. Previously, it was impossible due to some crappy design in the EFSL interfaces. After downloading a directory full of MOD files from Amiga Music Preservation, I added a feature where the player will now also play MOD files with the MOD extension in the front, the way Amiga used to store them. This makes it much easier to simply unzip, and then dump those Amiga MODs straight to your SD Card, without having to go through renaming each file.

While I was messing with the filesystem code, I ended up adding a feature to save current play list location and volume settings to a TRAXMOD.CFG file on the SD Card. Now when you restart the player, it will always start right up playing the file you were last listening to with the volume at your desired level. Very nice.

In other news, the PIC32 player parts are starting to come together. I now have the PIC32 Starter Kit in my hands and a bare AV32 breakout board. While I have not put a soldering iron to anything yet, I have started playing with the free C32 compiler and managed to blink an LED without any library code linked in. While I haven't done any tests to prove it, I believe this means that my simple C firmware is completely free of the 64KB FLASH memory limit that the free compiler libraries would normally impose. That was easier than I thought it might be, dunno why people would even bother complaining about it. Having full optimizations is far better than a stupid library that might bloat up your firmware with unnecessary code anyway.

The only PIC32 snag I noticed while reading this weekend was that the 64 pin version of the PIC32 does not have any pins to input an external clock to drive Timer 2 or 3, which in turn drives PWM output compare pins. In the LPC2103 based player, we currently use the DAC's bit clock as an external timer clock source so that we can precisely position our PWM output signal to activate the SPI slave select signal during the upper 16 bits of the DAC's 32 bit word transfers. Not having external timer clock inputs on the 64 pin PIC32 means we're going to need to take another approach. Because the PIC32's SPI port can output a full 32 bit word and has a buffer register (the LPC2103 SPI port has neither), we might be able to do without a slave select signal entirely by simply keeping the SPI transfering words continuously, back-to-back. I briefly tried doing this on the LPC2103 before, but it didn't work. Most likely due to the lack of a buffer on the LPC2103 and because its SPI can only do up to 16 bit word transfers.

My PIC32MX320F128 and PIC32MX320F064 low memory TQFP-64 samples have actually shipped now. Should be in my hands sometime this week. Also, the TPS61025 samples are in my hands right now, so we're good to go there too.

Made my first YouTube video. You can watch it here: TRAXMOD-ARM v0.6.7 MOD Player Demonstration. Unfortunately, the audio compression makes the high frequency chimes in the beginning raw audio demonstration sound atrocious, but you can be assured that the actual DAC output of these audio files is very good in reality. There is also a little buzzing noise apparent at the beginning of the video. I'm not quite sure why it's happening, but it goes away when I unplug the USB serial port dongle from the player, so it doesn't seem like too big a deal. However, I needed the serial port to see on the terminal when my button pushes actually registered for the video (I couldn't listen to the audio while the video was being recorded).

Firmware 0.6.7 has been posted under the traxmod-arm-0.6 folder in the Developer's Area. This version has smoother volume control while playing MOD files, and no longer locks up on any of my MOD files that I'm currently testing. This version sounds quite good, at least on my Dane-Elec 2GB SD Card, which seems to provide the lowest seek latencies of all my SD Cards. I can hear some occasional minor MOD sound glitches on my other SD Cards.

I just took some quick measurements with my multimeter for power consumption. This version seems to use about 70mA total while playing raw audio files, and about 80mA total while playing MOD files (not really any different than prior versions). The raw audio player could probably be optimized for power consumption by re-programming the PLL to operate at 50MHz instead of 70MHz, but we haven't bothered to implement such a thing yet. Not sure what could be done to improve the MOD player power consumption because we really need the full 70MHz at the moment to keep the SD Card clocked up. Maybe if there was more on board RAM for a larger output audio buffer, the mixer could sleep a little bit. Once we get the PIC32 going, we'll finally have that extra on board RAM (hopefully).

Ordered some TPS6102x samples from TI. Unfortunately, their order form is insistent on requiring a phone number. I hate getting follow up phone calls from salesmen. If I'm ordering samples of something, obviously I've already researched using their product to begin with, so why do I need a salesman wasting my phone minutes and time that I could be spending on making a final product? I put in bogus number 000-000-0001 to get past the validation code. If they cancel my order because of it, I'll either have to think about finding a different part or just buy the part from Mouser/Digikey next time I place an order there ($3.15 is worth avoiding sales phone calls).

Anyway, back to the TPS6102x parts. These are DC/DC boost converters that seem very flexible and efficient. They are a little more expensive, but might be worth it in the end. They can operate from a minimum input voltage of 0.9VDC, which means you could power the player from only one cell (but efficiency would be lower). They also have an alternate LDO mode of operation that automatically kicks in when the input voltage is above the desired output voltage, letting you use 3 or possibly more cells without fear of killing your circuit (but with even lower efficiency when operating in LDO mode). I'm thinking of 2 cell operation for maximum efficiency, although my cheap EMPREX MP3 Player from Frys Electronics is rather nicely compact with only one AAA cell.

The alternative part I was looking at this weekend was the Semtech SC4501. This DC/DC boost converter doesn't have the fancy LDO feature and requires 1.4VDC minimum input to operate. That rules out using anything but 2 cells (which is fine with me). Unfortunately, efficiency falls when the load current goes below 100mA, so this is not my #1 choice. It is much cheaper than the TI part though.

Ordered a $55 PIC32 Starter Kit Breakout Board that I ran across here: eflightworks.net. All of my TQFP-64 PIC32 samples are apparently back ordered forever, but at least I'll be able to start porting software over to the 100 pin Starter Kit in the meantime. Plus I won't have to waste any time designing a development board of my own.

Not too much to report. This weekend was spent on attending Desert Code Camp. Mostly Windows software development, but there was some interest in embedded Ethernet (unfortunately not much new content for me though). Maybe if I get a chance, I might try doing my own embedded systems presentation at a future Desert Code Camp.

PIC32MX340F256H samples still haven't shipped, and their estimated in stock date has been bumped forward another month. As a result, I put a new sample order in today for the lower memory versions of this chip in the 64 pin package, hoping they will ship. Being in the same package, I can probably use these smaller memory versions to produce a PCB and some initial firmware until the full version arrives.

While I was at it, I also requested the DSPIC33FJ128xx802-I/SP chips. Last time I used a dsPIC, they were only 30MHz, had tiny memory compared to LPC2103, needed 5V, and didn't have any DMA features. These newer dsPIC's have DMA support, 16KB of RAM, 128KB FLASH, and 40MHz operation at 3.3V. Still not as sexy as the PIC32, but since they come in a handy DIP package straight up, they still might be useful for beginning work while a TQFP 64 pin breakout board is being made.

It's been a very nice Memorial Day weekend for the TRAXMOD project. Schematics and firmware for version 0.6.6 has been posted in the Developer's Area. This version features the following:
• Externally clocked DAC and simplified word clock syncronization code.
• Many bugs fixed, far fewer audio glitches in MOD playback.
• Full 8 byte SSP FIFO usage in the SD Card reading interrupt service routines to reduce task switching overhead.
• Converted SD Card interrupt service routines to pure assembly for additional speed and code space compactness.
• Support for SD Card multi-block reads so that we can fast forward past block mis-aligned data (ISR only saves actual sample data into the 512 RAM buffer, no junk data wasting buffer space and no need to read two whole blocks).
• Music event frames no longer block the mixer code from continuing work on all channels. Music events are double buffered now, so that music processing can occur one row ahead of where the mixer is currently playing.

At this point, I'm thinking any glitches in the MOD player audio are no longer being caused by lack of data being ready in time from the SD Card. I think the remaining few glitches are from bugs in the code, and/or lack of volume ramping support in the mixer. It locks up on a few select MOD files, not sure why yet. A couple MOD files are able to play sample data that they should not be able to access. So, still plenty of work to do, but some MODs sound very close to perfect (at 44.1KHz/16-bit stereo, no less!).

Spent some time playing with different clock configurations. If I clock the LPC2103 at 40MHz or below, it doesn't communicate with the externally clocked DAC very well any more (I get crackly audio that gets worse at each lower clock speed). At 50MHz and above, communication with the DAC is okay.

If I try to clock the SSP communicating with the SD Card at 50MHz/2 = 25MHz, almost all but one of my SD cards stops working. Maybe the SD Card 25MHz specification limit means you really have to use some clock speed below 25MHz. Maybe the air wire signals on my bread board aren't good enough to support 25MHz communication? Anyway, I'm stuck running the LPC2103 at 70MHz and clocking the SD Card at 70MHz / 4 = 17.5MHz.

In other news, I've been trying to optimize the MOD player code like crazy. I now have the SSP interrupt handlers using the full 8 byte FIFO to reduce interrupt overhead. I also split the channel data structure into two separate structures so that the music event decoding can occur further in advance of the real time audio play back pointer. These two optimizations reduce the audio glitches a lot, but unfortunately, there are still some occasional problems on certain MOD files. Either something is still too slow or I may have some problems with my channel scheduling algorithms. Plus, it locks up sometimes at certain spots on certain MOD files now.

I was playing Terraforma by C.C.Catch on my TRAXMOD player when I thought it was sounding rather odd. Turned out my MOD player wasn't buggy, but the copies of terraforma.mod that I could download from AMP, Mod Archive, and ftp.ModLand.com all had bit rot in this file. At some point, two bits in the sample length fields of the MOD file had been flipped, making half of the sample data misaligned with what the sample header information was saying. After analyzing the problem for a while, I found the two bits that were wrong, whipped out a hex editor, and fixed the MOD file. You can download the fixed version here: Terraforma.mod (fixed).

In other news, I'm now clocking my DAC with an external 11.2896MHz crystal rather than using a timer output of the LPC2103. High frequency audio seems a little more sharp now than before. This is probably the maximum audio quality possible for 44.1KHz audio using this DAC. It also frees the LPC2103 to run at it's own clock rate, which we could use to drive the SD Card closer to it's maximum of 25MHz, or to run it at a speed that will allow maximum FLASH bootloader serial port baud rate.

I'm starting to hit the 32KB FLASH memory limit of the LPC2103. Still need to add lots more code to the player to support more module formats and to further optimize playback to reduce audio glitches during MOD playing. Looks like it's getting close to time to start work on switching to a larger and slightly more expensive microcontroller. I've started work on an EAGLE part library for the new PIC32MX340F256H microcontroller. With the added memory and DMA features, I'm hoping we'll be able to play multichannel module files beyond 4 channel MODs after the switch.

Booya! Figured out where all the audio crappiness is coming from. It's not an off by one bug at all. Turns out it's caused by SD Card seek time stalls of the audio mixer. I changed the code so that it will attempt to load the RAM buffers with block aligned data, even if some of that data isn't going to be used by the mixer, and that improved the audio quite a bit. I still get glitches on certain particularly poorly aligned samples, but it's way better. Sweet!

I've still got to implement my idea for improving the channel scheduler to look for block aligned channels when the mixer is starving. But it's late and I have to go to my day job tomorrow morning, so that idea will have to wait for another time.

Firmware 0.6.4 posted in the Developer's Area. It actually sounds rather decent during portions of certain MOD files now.

Firmware 0.6.3 posted in the Developer's Area. This release uses the streaming MOD player mixer, so you can play any size MOD file without worrying about fitting within the LPC2103's tiny 8KB of RAM. Only 4 channel, 31 instrument MOD files are supported at the moment. It plays MODs directly off a FAT formatted SD Card (yay!), but it will play incorrectly if the MOD file itself is fragmented by the FAT file system on the card.

There are still some very annoying bugs with this firmware which make the audio output very poor compared to the RAM only MOD player firmware in earlier releases. I did at least get it to the point were it doesn't outright lock up in the middle of most MOD files though. I'm probably off by one somewhere, but it's been impossible trying to find it.

At first, I thought maybe the poor audio was from lack of speed in the new streaming code, but lowering the DAC output sampling rate to 22050Hz did not provide any relief. Must still be bugs somewhere in the implementation.

Identifying and fixing bugs in the streaming MOD player branch of the firmware source code. It still has a lot of audio glitches, but the output is recognizable. I think I might have some firmware stable enough to post at the end of this weekend.

Been way too busy at my day job, doing taxes, battling bees in the backyard, and helping my brother move, but I managed to sneak in some tiny pieces of time on the MOD player project during the past few weeks (mostly during dinner time). I've re-written the ARM mixer code for SD Card sample streaming, which will allow playback of any sized MOD file because we don't try to load all of the samples data into RAM before beginning playback. It seems to be producing somewhat recognizable audio on a two channel MOD, but there needs to be a lot more optimizations to the code to get it going fast enough to keep up with the output audio rate. Right now, it has some very heavy reverb distortion because it can't keep up (at least, I hope that is what is going wrong).

I've got a lot of optimization ideas, some are quite involved though (hardware changes, plus new components that I'll need to order before I can do it). For example, reading data from the SPI port in master mode requires twice the number of instructions than should really be required because we have to pump the SPI data register with dummy data to get the SPI peripheral to clock in each SD Card byte. That's just plain wasteful of instruction cycles. Plus, our SPI master mode clock runs at a slower speed than the maximum 25MHz accepted by SD Cards because we have to use a multiple of the LPC2103's clock rate (I think we're currently maxed out at 16.9344MHz). If we had an external free running clock, we could run it at the full 25MHz, throw the SPI port into slave mode, and then we would not need to pump the SPI data register with dummy data to receive data from the SD Card. Unfortunately, I do not have parts necessary to create a good 25MHz clock source externally on hand right now. Plus, this change would necessitate delving into the EFSL FAT library source code to teach it how to access the SD Card while the SPI port is in slave mode. Lots of work to be done.

Meanwhile, I think I've squashed the bug that was causing some MODs to still have samples that don't play correctly in version 0.6.1. In order to print out sample names, I was writing a zero to the last byte of the sample name data, or so I thought. Instead, I was off by one and ended up zeroing the most significant byte of the sample length variable in memory. That caused larger samples to get truncated in memory. The version 0.6.2 firmware snapshot available in the Developer's Area now fixes that little bug. All of my MODs that are small enough to fit into RAM now play much better with this version. Aside from missing effects like arpeggio, I'd dare say they sound close to perfect.

New firmware snapshot posted in the Developer's Area. Version 0.6.1 fixes several bugs in the MOD player firmware. MOD playback now plays at the right frequency, the audio mixer now avoids a sign extension problem through the use of inline assembly code, but some MODs still have samples that don't play correctly to me. Still, it's much better than before.

New schematic and firmware snapshot posted in the Developer's Area under the "traxmod-arm-0.6" folder.

The raw audio player using the PCM1770 DAC is working splendidly now. I wrote some DAC word clock synchronization code last night/this morning and I haven't been able to get the player to start up unsynchronized ever since. Sound quality is excellent, volume control works nicely, the code is a bit simpler than the PWM/Resistor DAC code, and the schematic is simpler too. Go to the Developer's Area and check it out!

Well, after a quick sleep, I got right back to work on the project. I've now gotten it to work without the dsPIC30F3012! There is still some trouble with getting synchronization between the DAC's word clock (LRCK) and my LPC2103's SPI slave select signals, but when it works, it works nicely.

Stayed up all night long and got the PCM1770 DAC running in master mode! I'm still using the dsPIC30F3012 to send the control port commands that tell the PCM1770 what volume to use and to go into master mode. It's got some initial synchronization issues I'm working on too. I'm thinking I might try hooking the control port up to the SSP module shared with the SD Card next to get rid of the dsPIC.

All my efforts to bit-bang the PCM1770's control port so far have failed. Today I decided to try using the SPI port on my dsPIC30F3012 to send volume control commands to the PCM1770. Worked straight away, excellent. Now I can listen to the DAC directly with my Koss Porta Pro head phones. Great! Haven't tried enabling master mode yet, but should be easy. I'll still need to eventually get some software written to properly bit bang just like the SPI port, otherwise I'll have to share pins with the SD Card's SSP module, which I'm hoping to avoid.

Sweet! I just got some audio from the PCM1770 DAC using a dsPIC30F3012 to provide LRCK, BCK, and SSEL clock signals to the PCM1770 and LPC2103 at the appropriate times. Still can't seem to bit bang the PCM1770's control port lines correctly though. Makes it difficult to use the digital volume control features, ugh... The sound quality when piped through my stereo's volume control sounds good. Hopefully we'll be able to get this control port fixed up quickly and then I'll listen to the DAC directly with my headphones.

Spent the whole weekend trying to get the PCM1770 DAC up. Unfortunately, I can not get the thing to go into master mode. I'm providing it a 11.2896MHz input clock (256 x 44100) from one of the LPC2103's timer match output pins. I pull PD# low for a while to reset the DAC, then bring it high to release it from reset. I try writing 5 to register 3 of the DAC, which ought to switch it to master mode, but nothing comes out of the LRCK and BCK pins of the DAC. Very frustrating.

My next plan of attack is to temporarily wire up one of my dsPIC30F3012's to generate all of the clock signals I need to use the DAC in slave mode. If I could get it outputting audio in slave mode, at least I'd know my DAC is working. Then I could go back to trying to get the DAC to switch to master mode in order to avoid needing the dsPIC.

It took a long time, but the 16pin SSOP to DIP PCB's from Forest City PCB finally arrived today! They look very nice quality, better than I was expecting. I don't have time to solder things up right now, but I placed the chip on top to take a look and it looks like it lines up perfectly. Hope I get some free time to play with it soon.

Well, got tired of trying to put together a panel of PCBs just to get a SSOP-16 to DIP converter to start playing with the PCM1770 DAC samples. Ended up ordering three 16 pin SSOP to DIP PCBs from Forest City PCB for $1.49 each plus shipping. I've never ordered from them or heard of them before, so hopefully they're legit. It would be cheaper to just etch them on a single layer paper phenolic board (PP101 is $2.95 at web-tronics.com), but these days, the couple of dollars saved just doesn't seem worth it compared to the time involved in etching a PCB by hand.

Placed an order at Digikey for some crystals that operate at 16.9344MHz and 11.2896MHz. These frequencies are exact multiples of 44100 Hz, which is the standard audio CD sampling frequency. You would think that getting crystals for audio would be easy, but it wasn't. Few manufacturers make them, and they are often out of stock at Mouser/Digikey, unless you want to pay extra for an overpriced part.

When using the PWM-DAC, it wasn't too hard to play 44100 Hz audio without a perfect clock multiple because we could control in software how fast we switch to the next sample. But using the PCM1770 DAC requires us to provide an input master clock that is 256 times the playback frequency. If we have the LPC2103 clocked at 70MHz and divide it down to provide the PCM1770's master input clock, then the closest playback frequency will end up being 39KHz or 45.5KHz. That's pretty far off and would be noticeable.

Still haven't made any PCBs yet. Thinking of doing it by hand this time instead of ordering it manufactured. Not making a final board, just another prototyping board for playing with the DAC and the LPC2103 timer match schemes. Hopefully will have enough time to get something done.

Older news...