PIC24 with External Flash Memory

[aurmer]

This is my first time utilizing external flash memory chips (like these) in my design. Any tips or 'known resource/knowledgebase' before I get started?

Specifically, my widget plays music files which will be stored on external flash. I am keeping it simple, raw WAV data will be stored on the flash chip and read by my PIC24f and sent out of the PWM module. The flash won't be written to during operation; this sound data never changes once the widget is made.

I need to write instructions on how to assemble my widget (many units will be hand-soldered by students). What is the best/easiest way to get the sound data onto the flash chip during the assembly process?

(Also, I am trying to avoid more chips/parts due to production cost constraints.)

[Ian.M]

You have a few choices:
- Hold the PIC in reset to force its I/Os to tristate and connect the SPI bus to a programmer that supports the FLASH chip in question.
- Include a programming mode in the firmware with USB (if the PIC supports it) or logic level serial interface to a PC to download the SPI FLASH data.  Add a jumper to enable/disable programming mode.
- Use a separate SPI FLASH programmer firmware, interfaced as above, loaded and run before loading the main firmware.

In all cases, you can save parts by using a PCB footprint for the programming 'headers' that uses the PCB itself as the contacts.  e.g. Sparkfun's offset hole SIL footprint or Tag-Connect.

[JPortici]

Simplest thing would be to communicate with the PIC via the UART. Send the data with a usb/ttl adapter and let the micro program the flash. It takes a matter of seconds to write an application in VBasic/QT to handle the formatting/transfering

[mikeselectricstuff]

Add an SD card interface - just need an extra CS line, others can be shared with flash.  Copy sound data from SD to flash. Microchip has a SD library for the 24F, but needs some minor tweaks to get decent speed.

Preprogram the flash in a standalone programmer

Use Microchip/SST flash chips and use their programming service to get them preprogrammed.

Use UART download, and choose a baudrate lower than the effective flash write time, so you don't need handshaking (as long as you have enough buffer to cover the write time and transfer the next page). You would need to pre-erase if reprogramming as erase time is >>> program time for SPI flash, can be minutes for larger devices.
 

[Ian.M]

Add an SD card interface - just need an extra CS line, others can be shared with flash.  Copy sound data from SD to flash. Microchip has a SD library for the 24F, but needs some minor tweaks to get decent speed.

Why not ditch the FLASH and just play audio from the SD card.

[mikeselectricstuff]

Add an SD card interface - just need an extra CS line, others can be shared with flash.  Copy sound data from SD to flash. Microchip has a SD library for the 24F, but needs some minor tweaks to get decent speed.

Why not ditch the FLASH and just play audio from the SD card.

May be a good option in some cases, but many potential reasons not to, especially where you don't need the high capacity of SD.

Data rate from SD is less predictable due to internal processor doing stuff like bad block mapping. Also varies from card to card.
Higher power consumption
Higher cost  - SPI flash is extremely cheap at lower memory capacities ( up to a few megabytes).
Possible long-term reliability issues of SD connector.
Read disturb errors - NAND flash suffers from a mechanism that degrades data over time under heavy read cycles.
Simplicity - SPI flash is much, much easier to deal with if all you want is a single stream of data.
Smaller size - a DFN8 is rather smaller than a MicroSD+connector.

In the past I've used both, outputting data to an external DAC -

SD card streaming CD quality on a PIC24FJ002 at 16MHz- this was quite a squeeze bandwidth-wise, and needed quite a lot of buffering to cover SD latencies.

SPI flash on a PIC16F818  - in this case the data out from the flash was fed straight into the DAC & wasn't touched by the MCU at all - it just provided the clock to both devices.
 

[aurmer]

Thanks for the responses! I really like the idea of a separate programmer. This will allow us to load the data without needing to buy a USB/UART chip for every board.

[JPortici]

still pushing the USB route... it doesn't have to be a USB TTL per board. it can be a FTDI or MCP2200 on board so you only need a usb cable (using a micro B socket would mean to use the same as their phones)
then you can make your students add functionalities that would be controlled by the supposed application software

[mikeselectricstuff]

Thanks for the responses! I really like the idea of a separate programmer. This will allow us to load the data without needing to buy a USB/UART chip for every board.

The 6 pin header on the FTDI TTL232 cable is a sort-of standard for this type of thing.

Or you could use  the PIC24FJ64GBxxx and have USB device built in. Microchip have a library that makes it act as a mass-storage device so you can just drop a file on, without having to write any code at the host end.

There is some fiddliness in that you need to write a SPI flash layer, and use a SPI flash with a 4K uniform erase block size ( from memory Spansion S25F2xx), as the file system wants to write 512 byte blocks, so you need to do a read/erase/write to update non-blank blocks.  PM me if you want to persue this seriously as I've already done it.

Obviously this takes quite a lot of code space for the USB support, but if all the rest of the thing is doing is playing audio there won't be much else.

[Ian.M]

You can really cheap-skate the USB down to zero extra parts without having to make up a custom USB to pogo pin cable by using an type A (M) to type A (F) cable and implementing the board's USB connector as an edge connector, notched into the board edge.  It will probably need a plastic shim to get the thickness right.