TRAXMOD

Developer's Area (schematics, firmware, etc.) Parts List FAQ Support Forum Project Background YouTube Demonstration DAC Selection 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 lossless, portable digital audio player using the Microchip PIC32 high speed microcontroller chip (an older version used the NXP LPC2103 ARM7TDMI). Currently, TRAXMOD-PIC32 can play raw and FLAC wave audio streaming off of a FAT formatted MMC/SD Card at 44100Hz, 16 bits, stereo using a Burr-Brown PCM1770 DAC with integrated headphone amp. The old breadboarded TRAXMOD-ARM can play raw wave audio and 4 channel MOD files streamed off of a FAT formatted MMC/SD Card. Multichannel MOD playback is a future goal for the TRAXMOD-PIC32 player.

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.

News

07-16-2010

Firmware version 1.0.3 posted in the Developer's Area:


• Added Peripheral Bus clock scaling to the FLAC player. Power consumption is now down to around 80-90mA average at the battery terminal.
• Imported a few MAD optimizations from the Rockbox project. Still struggling with this though. I may need to switch to the low level MAD API to get IDLE and clock scaling stuff to work right. Down to about 170-190mA average power consumption at the battery terminal right now.

One more power optimization I'm considering implementing is the idea of executing code from RAM instead of FLASH. According to the PIC32 datasheet, executing from FLASH costs 37mA vs 25mA executing from RAM (at 3.3V, 25MHz). Previously, I didn't really consider this idea because I had so little RAM to work with and I wanted to avoid starving the DMA for RAM bandwidth. But now, it might be possible to have the player copy the FLAC decoder code into RAM and execute from there to save some extra power.

Unfortunately, trying to get all the C code and compiler working with this idea will take some effort. And I'm not sure it will be feasible for the MAD player, since the MAD decoder code is quite big in comparison.

07-11-2010

Firmware version 1.0.2 posted in the Developer's Area. Lots of changes in this release:
• All 128KB of PIC32 RAM is now used for extra buffering, MOD samples, etc. FLAC files encoded with the larger 4096 block size should be playable now.
• All DMA routines have been updated to use the extra byte count bits available on the new PIC32. Previously, each DMA transfer was limited to a 256 byte count limit, which complicated the code and forced the microcontroller to wake from IDLE mode more often than we really wanted.
• Power consumption of the FLAC play back code has been improved. I measure about 100mA total player power consumption from the 1.2V battery terminals during FLAC playback using my lowest power Toshiba 2GB SD Card.
• The MAD code for PIC32 has been ported in. Power consumption has not been optimized for this play mode yet, but at least it works. Measuring about 180mA to 210mA at the battery terminals right now.

07-08-2010

The new surface mount buttons look good. I also did some testing last weekend of various SD Cards to see if they would hold initialization state when the voltage on the SD Card is lowered. No cards would remain fully operational below 2.7V, which is the minimum voltage spec. However, most cards did hold state at low voltages, some even as a low as 1.05V. So it does look like this second MCP1640 circuit could be a good idea for some extra power savings.

Put an order in at Mouser for a bunch of components. I ordered 100 MCP1640T-I/CHY chips -- this is the high efficiency PWM/PFM version. I didn't buy the MCP1640B PWM only version because it wasn't in stock. And the PFM mode really doesn't make enough noise to be noticable. Any little extra efficiency gains we can get out of PFM mode will be a plus.

I'm still not entirely certain whether I want to keep using the chip scale SI8429DB P-Channel MOSFET to turn the SD Card on and off. It's kind of expensive at $0.87 each. Being chip scale makes it impossible to solder with a normal soldering iron. I can probably make decent yield in manufacturing using my toaster oven and a little more practice, but it is still risky. I'm not entirely sure powering down the SD Card is going to work while playing raw audio and FLAC files. The initialization sequence to get the card back up and running can take a long time, and varies from card to card. It might only be workable on certain SD Cards and high compression lossy formats like MP3 where we can keep decompressing and playing audio from RAM for longer periods of time.

One idea that might be worth investigating is adding an extra MCP1640 power supply dedicated to powering the SD Card. The MCP1640 is so cheap that it really wouldn't cost much more than the SI8429DB P-Channel MOSFET. The MCP1640 in SOT-23 package is extremely easy to solder down. If we can add the right combination of voltage divider pull down resistors connected to open-drain microcontroller output pins, we might be able to dynamically control the SD Card's regulated voltage. If we could lower the SD Card down to a nice low voltage, just high enough to avoid re-initializing when powering back up, we might avoid the slow initialization problem while still reducing power consumption. With dynamic voltage adjustment, we could detect the minimum operating voltage that the SD Card will work at, and possibly use that to reduce operating power consumption. I need to do some testing of various SD Cards at low voltage to see if these ideas will really pan out.

Right now, the SD Card is always stuck running at the same voltage as the rest of the board, which has to be at or above 3.0V to keep the PIC32 chip capable of self programming its internal FLASH for remembering volume settings. By specification, SD Cards are supposed to operate down to 2.7V. There is no specification for minimum voltage to maintain state, so I don't know if we can go lower during non-use without testing on my own.

The MCP1640 has a shutdown pin, allowing us to completely turn off the SD Card's power. However, the MCP1640 requires at least 10uF output capacitance. That output cap will drain and recharge when powering off/on. Therefore, the amount of power savings achievable when powering off for short periods of time, such as during playback, may not be as good as the MOSFET design.

The inductor required will need a lot of board space that we don't have available on the current design. I ordered some TL3315NF100Q surface mount push buttons in my Mouser order. Being surface mount, a lot of space on the backside of the PCB will become freed up. The through hole buttons I'm currently using are too tall. The LCD will need to be the tallest item on the front side so that pressure can be applied to it to keep the zebra connectors making good contact. The new surface mount buttons are very low profile, which will help here too. It will require adding slugs to extend the button surface up to the outside of the enclosure, but I wanted to do that anyway.

Got a couple new LCD screens from SparkFun. These are even cheaper at $3 a piece, but there is no way to connect the signals up to them without getting an elastomeric zebra strip to sandwich in between the glass contacts and the PCB contacts. Nobody knows where you can buy elastomeric zebra strips, so this will be hard to use in quantity. For testing purposes, I stole an elastomeric zebra strip from an old LCD thermostat. Haven't tried firing one up yet, but looks like it could be workable.

06-16-2010

Well, trying to use SLEEP mode turned out to be a wild goose chase. SLEEP mode not only stops the system clock, but it puts the internal core regulator into a low power mode. When you wake up, there is a delay to allow the core regulator to go back into running mode. The delay is too long and the SPI FIFO buffer is too small. You can't get back to running codeto re-fill the FIFO buffer in time, so this idea is dead.

In other news, I'm now using the SPI's Slave Select (SS#) input pin to synchronize the SPI word shift to the DAC's left/right word clock (LRCK). The old design only routed LRCK to the SPI SDI input, thus you had to manually synchronize the SPI word shift using firmware. The new synchronization method is much simpler and works right away every time.

06-12-2010

I've started playing with some of the new features of the PIC32MX695F512H chip we're now using. DMA driven reads from the SD Card seemed to be working concurrently with program code execution now! I haven't put it into strenuous use yet, but removing my previous IDLE mode workaround and forcing the processor to go into a busy loop during DMA driven SD Card reads is working.

The interrupt handling is different on this new PIC32. It feels like they moved from what I would call "edge sensitive" interrupt handling to "level sensitive" interrupt handling. Previously, you had to have your interrupt handler enabled when an interrupt event fires. If not, the event would not later trigger when you finally enable the interrupt handler. Now, a pre-existing interrupt flag will immediately trigger the interrupt handler when enabled long after the event had originally fired.

This new scheme simplifies some of my code. Even better, I suspect this level sensitive interrupt handling may be keeping the DMA engine attempting to process an SPI read, even when the data bus isn't available to the DMA module when the event first occurs.

The new PIC32 brings us four times more SRAM, but there's a cost: IDLE mode current has increased from 1.4mA to 4.5mA (at 4MHz). IDLE mode turns off the processor core, but still continues to clock the SRAM and peripherals. SLEEP mode turns off clocking to the processor core, peripherals, and the SRAM. Because there's more SRAM to clock, the IDLE current has increased while SLEEP mode current has hardly changed at all (39uA to 41uA according to the datasheet).

SLEEP mode is difficult to make use of, since everything is basically shut down. However, there is a little note suggesting that SPI modules in Slave Mode may continue working in SLEEP mode using the external SPI clock source. Maybe we can stop using DMA and IDLE mode to output audio data to the DAC via SPI. Maybe we can use the processor to periodically fill the new 16 byte deep SPI FIFO buffer, put the microcontroller in SLEEP mode, let the DAC's BCK pull the data out of the SPI during SLEEP, and then wake up from SLEEP using a SPI FIFO empty interrupt. If we can get that working, we can probably get the microcontroller's power consumption down below the old player.

06-06-2010

All of the old code is ported over to the new hardware design and it sings! I've not done anything to take advantage of the new hardware features, just the bare minimum to get playback working like the old PIC32MX340F512H player. Firmware v1.0.0 is posted in the Developer's Area.

The MCP1640 with PFM mode did make a teeny tiny buzzing noise when I held the inductor right up to my ear, at a particular angle, with the PIC32 in its lowest power SLEEP state before soldering down any of the other circuits. Probably not enough of an issue to make any difference during normal use. The MCP1640 stays cool to the touch and seems to be excellent so far.

06-03-2010

The Post Office left my boards sitting around at the Phoenix sorting center for an extra day, so we only just got the boards today.

So far, so good! The boards weren't cut flush to the copper edge like I wanted, so they were a little too wide to fit in the plastic enclosure. I spent half an hour slowly sanding away the excess fiberglass to make it less wide. It's still a little too tight, but it'll work for now.

Started soldering down components. First component to get put on was the chip scale packaged P-Channel MOSFET for the SD Card power off feature. I applied flux to the PCB pads and then gingerly placed the component where I thought its solderballs might make contact with the pads. Then I stuck the board in an old toaster oven set at maximum temperature for about 30 minutes. I saw the flux bubble a little bit, but wasn't sure if the CSP solder balls were melting or not. I took the board out and put it on top of the toaster oven. I applied extra heat using my soldering iron to the traces going to the pads underneath.

I still wasn't convinced it worked, but when I hooked up power and checked it out with my voltmeter, it seemed to be actually working! So far, so good...

Next, I soldered down the components required to get the DC/DC power supply running. The MCP1640 in SOT23-6 package soldered down real easy and is clearly making good connections. The rest of the power supply components soldered down easy. I applied power using a mostly dead, single cell NiMH AAA battery outputting no more than 1.16V (unloaded). The MCP1640 boosted it right up to 3.1V, exactly like it was supposed to. Awesome! I don't have any load connected to it yet, but happy to see it running.

Unloaded, I did not notice any PFM hissing or vibration noises so far. This is the PFM/PWM high efficiency version of the chip. I'm going to try it out for a while to see if will be quiet enough to be preferred over the PWM only MCP1640B.

I just finished soldering the PIC32. Applied power and hooked up REAL ICE. It detects the right device and seems to be communicating. Sweet!

05-30-2010

Unfortunately, the new PCB shipped on Friday 5/28, so it didn't arrive in time for the three day Memorial Day weekend. But, at least it shipped and should be in our hands as soon as Tuesday night.

05-22-2010

Got a software bit-bang DAC control communication routine working on my old TRAXMOD-PIC32 today. I had tried doing this earlier, but I was working blind and failed. This time, I used the Saleae Logic logic analyzer to see exactly how my bit-banged data compared to the working SPI data. That made it much easier to get everything right this time.

One hurdle down for the new design, w00t! The new design no longer shares the same SPI bus to communicate with the SD Card and DAC control interface. This made it easier to route traces for smaller board size and it will allow for volume changes without waiting for the SD Card to go idle (which won't happen often during MOD playback).

Unfortunately, the board house still hasn't shipped the prototype PCB yet. Hopefully it'll ship during the next week or two.

Going over the parts list, it looks like everything, including the new SD Card socket, is still in production right now. That bodes well for a future run of production TRAXMOD's if the new design works. While most parts cost the same or have come down, the PCM1770 DAC has gone up. Bastards. I already bought a pile at the beginning of the recession when they were priced better because I was afraid they could turn into a show stopper like the old SD Card socket did when it went out of production.

05-03-2010

I dropped my trusty old TRAXMOD-PIC32 and I fear it may be on its way to a death sometime in the forseeable future. I etched, drilled, and soldered that one at home on a cheap paper phenolic prototyping PCB -- amazing it's held up this long. Plus all the fancy new IC's released have helped push me to finish the new TRAXMOD design that was mocked up and started over a year ago (see 3-24-2009 blog entry).

Yes! Tonight, I've finally finished the new board design! It's been submitted for prototype manufacture, now we just gotta wait a month for panelization, manufacturing, and shipping. I might also need to order a few more new components in the mean time too.

The new PIC32MX695F512H chip has a 3rd SPI port, but you have to give up all your UARTs if you want to use all the SPI ports. I absolutely need at least one UART for debugging messages, so unfortunately, the extra SPI didn't help me. The board space on the new design is so tight that I really didn't have any choice but to wire up the DAC control interface to bare GPIO pins. I also had to do the same for the LCD interface. It's going to take a lot of firmware effort to get this board up and running initially because now we're going to have to bit bang these SPI interfaces.

If we can get it working, making the board fit into a tiny AA battery holder enclosure is going to be really quite nice I think. I'm really looking forward to switching to a single AA battery design. AA offers better power density. Plus, no more worries about trying to find matched pairs of AAA batteries.

03-18-2010

I missed this when it first came out, but it's still very good news: MCP1640 Boost Regulator. Finally, a single cell DC/DC boost converter that we can use to eliminate the TPS61025 that we love+hate.

While TPS61025 could technically operate from a single cell, in practice it doesn't work once you add basic reverse polarity protection necessary for almost any user swappable battery powered application. Consider the 0.48V drop from adding a reverse protection schottky diode: you get a typical single cell start up voltage of 1.2V - 0.48V = 0.72V. The TPS61025 has a start up voltage requirement of 0.9V (fail)...

The new MCP1640 claims to start from as little as 0.65V, which should truly enable single battery operation. MCP1640 is going to be available in a wonderful little 6 pin SOT23 package. The TPS61025 only came in a horrid 10-pin QFN package that made our prototype boards sometimes fail due to bad solder connections from trying to hand solder that leadless package. The price of TPS61025 used to be $1.96 in 100 qty, and it looks like that has gone up. MCP1640 is priced at a mere $0.44 in 100 qty. Pure awesome.

I hope the MCP1640 will work as good as it looks. It does provide a slightly lower maximum output current capability, but still probably plenty for our purposes. I wish it came with fixed output voltage variants (2.9V or 3.0V please), but I guess two external resistors isn't too big of a deal.

This project has kind of stalled out for almost a year now... There are a couple good reasons why it made sense to put it on hold. Here's one of them:

Microchip is now producing their new PIC32 chips! The PIC32MX695F512H has 512+12KB of FLASH, 128KB of RAM, 3 SPI modules with 16 byte FIFOs, and 8 DMA channels. All of that still fits inside the same 64-pin TQFP package that we've successfully hand soldered before. Pricing is $7.01 in 100 unit quantity, which is unbeatable for a part with these goodies.

Today I got a shipment tracking number for a few samples to play with. I'm very excited about the possibilities of this new part. 128KB of RAM is so much more than what we've had to work with in the past. MP3 playback could become a snap. The 16 byte SPI FIFOs might help reduce bus contention between the DMA and CPU when trying to do SD Card data transfers in the background. If that works out, the streaming MOD player implementation could become a lot easier too.

Even the power efficient FLAC/WAV playing we've already got working could become far better with very little effort. Currently, power consumption is dominated by the SD Card. With more RAM inside the microcontroller, we could buffer more data from the SD Card, allowing the SD Card to power off for longer periods of time.

The only bad thing is that they don't offer one without integrated USB and 10/100Mbps Ethernet. That means the pinout might be different from what I was using before. I will need to find some time to work on finishing the next PCB revision so that we can start playing with this new chip.

Firmware v0.7.15 released. A few minor bug fixes here and there. Nothing major.

Spent a whole week trying to route a new PCB for the next hardware revision, but still not done. This new hardware revision will have a new power supply that is software controlled (hopefully it doesn't blow up on me). Using a manufactured double layer PCB, it will have a really tiny form factor so that the player can fit inside a AA battery enclosure. And it may finally have a little LCD to navigate and view song comments. Currently missing are surface mount LEDs for backlighting the LCD, physical clearance testing, copper fills, and of course, trying to pass DRC. And maybe some software testing on the existing hardware to verify that we can really bit-bang the DAC/LCD SPI this time instead of having to multiplex and route the MMC/SD Card SPI signals all over the board.

Firmware v0.7.14 released.
• Fixed bug in MOD player code that would let a Note Delay effect attempt to play a sample number that does not exist in the MOD file. This was causing the player to crash on certain MOD files.
  
  
• Fixed bug in MOD player that was overwriting sample finetune settings with 0. This caused notes in some MOD files to play at the wrong frequency.
  
  
• Moved all statically allocated MOD player variables to heap memory. This allows the other players (FLAC, etc) to use all available RAM like they had back in v0.7.12.
  
  
• Modified the FLAC decoder to generate decoded sample data in interleaved channel format instead of two separate output buffers for left and right channels. Eventually, this may allow us to improve the FLAC player by using the audio playback ring buffer directly in the decoder. Still need to add support for ring buffering in the decoder before that can happen though.

Firmware v0.7.13 released. This release adds some working, but poor MOD playback functionality to the PIC32 firmware. This firmware is basically a port of the old C only code from TRAXMOD-ARM v0.5, which does not do any streaming of sample data off of the SD Card. As a result, it can only play small MOD files where sample data fully fits inside the small 30KB of free RAM inside the PIC32. It has lots of bugs, but at least it makes sounds now.

Firmware v0.7.12 released.
• Reverted some of the DMA code back to v0.7.8 code. For some reason, 16-bit audio transfers to the DAC cost about 2.5mA more current than using 32-bit audio transfers, even though that reduces the audio buffer size by 50%.
  
  
• Gapless playback when playing across raw wave audio files is sometimes working now. We can still get hosed by EFSL slowness, but often times it does work. Only works when transistioning between files of the same type (switching between raw audio and FLAC compressed audio does not work gaplessly). Since FLAC leaves so little memory for the audio buffer, gapless playback across FLAC files probably does not work very often right now (if at all).
  
  
• Total power consumption for the whole device, excluding power supply losses, using my best Dane-Elec 2GB SD Card is: 15.5mA at 3.3V for raw audio and somewhere around 31mA for FLAC compressed audio. Using these numbers, my calculations indicate that a pair of 1000mAH AAA NiMH batteries could theoretically last up to 24 hours playing FLAC files, and up to 46.9 hours playing raw audio. Of course, real life is probably less than this, due to losses in the switching power supply (which I haven't measured) and due to most SD Cards drawing far more power than the Dane-Elec 2GB and Toshiba 2GB SD cards.
  
  There is lots of room for improvement in the FLAC power consumption, but even at this point we've got pretty good performance in my opinion. I measured the power consumption of a cheap $9 Emprex MP3 SD card player I've got, and my calculations indicate it would only last about 8 hours on a single AAA (it only accepts one AAA battery). Even if you doubled that for two batteries, 16 hours is still worse than our 24. I wonder how power efficient more expensive players are. Anyone know?

Firmware v0.7.11 released:
• Play/Pause works when playing FLAC files.
• Repeat mode works when playing FLAC files.
• Switching files early while playing FLAC files no longer stutters.
• Power management code added to FLAC playback loop. Still draws a lot of power (around 25mA), but its a start.

Firmware v0.7.10 released in the Developer's Area. This release adds support for FLAC files encoded with "-blocksize 2048" (or less). Some restructuring of the FLAC decoder software was begun for the goal of reducing memory requirements low enough for possible 4096 block size support at some point in the future. Not there yet, still a long way to go.

This release brings forward all of the old MOD player source code from the TRAXMOD-ARM firmware. While the code does compile, MOD playing is not working yet as there is still some missing MMC/SD Card streaming routines that haven't been written for the PIC32 port yet. And the inline assembly language mixer code of course needs to be re-written for MIPS architecture.

Firmware v0.7.9 released in the Developer's Area for TRAXMOD-PIC32. This release adds the first working FLAC playback support! Totally unoptimized and plenty buggy controls, but it's great to have it up and running. Currently, only supports 44.1KHz/16-bit FLAC files encoded using the "-blocksize" setting of 1024 or lower. Larger block sizes consume too much RAM to work right now. Since FLAC is lossless, you can easily transcode your existing files to 1024 blocksize without any loss of quality, you just get a slightly lower compression factor.

This release features a new SPI DAC left/right clock synchronization routine that modulates the SPI CKE clock edge setting, forcing the SPI shift buffer over until we read a perfectly aligned left/right clock signal on the SDI input pin. Previously, we didn't attempt any forced synchronization to the DAC left/right signal -- instead we relied on the DAC and SPI to stay in sync from power on reset. Unfortunately, that always left the SPI off by one bit, which we compenstated for by shifting audio data over one bit before sending it to the SPIBUF. To accomodate that shift, we had to use a 32-bit audio buffer, even though we really only have 16-bits of actual data. Now that the SPI is perfectly aligned with the DAC, we can use a 16-bit audio buffer, effectively doubling the apparent amount of RAM for audio buffering.

I spent a lot of time trying to make this version play raw audio gaplessly when switching files, but ultimately gave up. Its better than last verison, but still has an occassional pop when switching files. EFSL takes too much time between files for it to work right now. We either need to re-write parts of EFSL for greater speed or start loading information about the next song while the current song is still in the middle of playing. Both are big projects that aren't worth the effort right now.

Older news...