Project Logs

Collapse

• OSHPark board arrived, strange flashes ensue

  John • 05/19/2019 at 11:31 • 0 comments

  So my shiny purple and gold OSHPark PCB's have arrived, and one of them has been populated, the picture of which should find its way into the gallery. Noteworthy developments between building the proto circuit and the PCB's arriving:

  -burnt out 2 arduino uno's trying to run the neopixel rope off an ATX power supply

  -burnt aforementioned power supply somehow

  -ordered new atmega328 DIP IC's 

  -discovered that aforementioned IC's were not bootloaded

  -ordered USB AVR programmer from Pololu

  -dicked around with programmer for some dozen hours. nothing works.

  -broke down, borrowed friends uno to as arduino ISP. Still not working

  -pulled out hair

  for context, I had two Arduino Uno's that both claimed to be R3's and to my knowledge were both genuine. However, they were two different shades of blue, had two completely different silk screens, and as it turns out, one of them was broken? I had been trying to program bootloaders onto these IC's by loading them into the board, wiring up the ICSP headers, and programming. After multiple failed attempts, I switched to the other board just for shits and giggles, and it suddenly worked. I have no idea why, as the two should be identical circuits, unless whatever fried my original IC's caused the onboard atmega16u2 on just one board to fail in such a way that it interfered with the ICSP wiring. I think this is fairly likely, as the verified functional bootloaded IC on the good board worked fine, but could still not be programmed over USB when placed in the 'bad' board. Anyways...

  I now have the v1 board soldered to an Uno and presumable transmitting good data, although I am having some weird issues. If you look at the updated code, every time the uno resets, it looks at three values in EEPROM which are used for the RGB of the whole rope. It SPI's three 0's (using a clock speed of 1MHz, the closest it can get to 800 kHz, but still within spec) then increments each color value if it doesn't already match the EEPROM value, waits 25 mS, then send out the new color data. Once the final color bytes have been written, it shuts down the SPI situation, starts a serial connection, and waits for three new color values to commit to EEPROM.

  Now the weird stuff:

  If I, for example, write 255 0 0 to my uno, then reset, during the fade in I get some weird flashes of blue and sometimes green on sections of the LED rope. The flashes seem consistent. The final color of the rope is always correct, except for one time, which I haven't reproduced so may have been a 1 time glitch.

  Secondly, if I write 0 0 0 or 1 1 1 to EEPROM, reset the board, the last ~25 or so LED's don't change. This can be fixed, if I write more than numpixels x 3 bytes of 0's to the SPI bus. This issue does not happen if I write 2 2 2 or greater. 

View project log