(1) Sheet 2 needs a frame

(2) 7 4-way jumpers in sheet 2

(3) Dashed lines in SCH are on "Symbols" instead of "Info"

(4) LM1117 had wrong prefix

(5) Board "Dimension" outline is 10mil instead of 8mil

(6) I updated my Eagle_rules repo and loaded it into the design, it seemed to fix the via sizing issue. I'm think the DRU in the project is just outdated

(7) When the vias changed it threw a Clearance error/issue

(8) Need measures in BRD

(9) 1.8V vreg needs silk for footprint

that's it!

We have around 1000 units of the MP3 Trigger in our products however since last year we've noticed a repeated issue across a selected few units, so this is a request fro someone with a fair amount of knowledge regarding their functionality. I've tried to succinctly get the points across below:

• There seems to be no pattern how the units fail but they hang with the green status light illuminated and are unresponsive to the manual stop start/track up/down switch.
• The only way to restart the MP3 players in this condition is to restart them with a power down.
• Once a unit fails it will fail on the same track at the same place each time. However if the SD card is analysed in any way the fault will disappear or move to another track.
• For some time we thought this problem could only be a attributable to faulty blocks on the SD cards, however when we use Partition Pro to analyse the cards, no problems are found.
• We have then removed the MicroSD card from one of these “faulty” products and transferred it to one of our new ones and the same problem occurs in the exact same place on the exact same track, yet this MicroSD card has performed perfectly for perhaps 12 weeks before the error occurred and the file when viewed on a PC has no discernible issues.
• Replacing the MicroSD card with a new, formatted card solves the problem as far as we can tell and reformatting the problem card means it is then reusable in another MP3 player, and the player as yet has not experienced another fault.

What we would like to know, is whether there is anything anyone is aware of that could cause this error perhaps in corrupting the cards or in the actual decoder chip etc.? We recently noticed we had an MP3 track with a lot of MetaData on it at the start, which meant that the track began as normal, but it was about 1 minute before the audio kicked in – presumably because it had to parse the data before the audio stream began decoding. Does MetaData affect the MP3 player? Perhaps it stumbles over a mis-read block of data or similar?

Any ideas on the matter will be greatly received.

ISSUES:
(1) The TRIG17 and TRIG18 nets need flag labels

(2) DPDT and Nav switches both have "U" as the prefix, should be "S"

(3) This might be the same issue that I mentioned on the proto checklist, if so, please omit: There is a clearance issue thrown on one of the vias under the PSoC. I have my DRC clearances set to 6 mil min.

(4) Looks like NAV switch and barrel need tNames and tValues elements in the BRD

Concerns/comments:
(1) Might be worth noting AC and DC coupled on the jumper key on the back of the board

(2) There are a couple instances throughout the design of traces exiting pads at an angle. While I don't think any of the examples would cause functional issues with the design, I think they are worth fixing before we order REDs quantities. IMO

(3) According to the checklist, BLUE is the standard color we want to use for "STAT" LEDs. The stat LED in the design is green. I know there is a lot of documentation and support stuff on both Jamie's side and our's that reference the GREEN stat LED in the design. On that note, I think changing the LED to BLUE would be more trouble than it is worth. This is more of a CYA to show it was thought of.

(4) Looks like the design contains mostly 10 mil traces, but there are some 8 mil traces sprinkled around. I understand using smaller traces if a smaller pad necessitates it, but I can't see the reasoning for some of the 8 mil traces in the design. eg. See the "T" intersection on the "3.3V" trace near the R12 resistor. Again, I don't think function will be affected if the design stays as is, but I think it would make the design better to eliminate un-necessarily small trace widths. IMO

That's it.

I Would like to play a sound after every interrupt on a system, but I need that the playing of each instance of every sound continue until finish each file, Is it possible with this device or exists a firmware wich could afford this?