What system are you using, etc?Southfork wrote:Yes not working for me with upload via programmer, I'll post the error message tomorrow see if anyone can decode it for me.ArguZ wrote:Yes, you need to click on Upload via Programmer
Announce Thread: Magpie Modular - uBraids - Braids in 8 HP.
windows 7. arduino ide. AVR pocket programmer.ZZ Ardoz wrote:What system are you using, etc?Southfork wrote:Yes not working for me with upload via programmer, I'll post the error message tomorrow see if anyone can decode it for me.ArguZ wrote:Yes, you need to click on Upload via Programmer
Its seems to be failing to compile the code with this error message.
stray \302 in program
<title>microBraids/mbraidsv3.ino at master · MagpieModular/microBraids · GitHub</title>
Nice one - Would love to know if there is a solution to the line issue, as it has been repeated. Not urgent, but more curious to learn what would make it happen, and if it is hardware or software relatedSouthfork wrote:Ok got to the bottom of it, was the way I was pulling the sketch from GitHub, simple copy n paste fixed it. All flashed now. One character line seems out of place on 1st letter but completwly useable, seems a few of us are getting this. Won't bother re-flowing pads, mucho happy
Int. RC Osc. 8MHz doesn't seem right. According to fusecalc you probably want something that contains Ext. Crystal Osc.;.... Googling "atmega328p arduino fuses" turns up low_fuses=0xff, high_fuses=0xde, extended_fuses=0x05 which looks better. But I haven't used an AVR in eons or ever flashed one with Arduino, so it's probably just be a matter of picking the right board in the IDE?ArguZ wrote:Here are my Fuses...does that look ok ?
Just don't try random fuse combinations, that's a recipe for disaster
I have seen builds where the corruption of the display is in a different place so guessing it's down to the construction. Does anyone have a perfect display? the pads on CD74HC4067 are too small but not sure if it's anything to do with the display problems, can anyone clear this up? Board could deffo do with a revision if there is any free space (cramped I know). I have another 2 of these so will solder that ic 1st while I have space to concentrate on it and see if that makes a differenceZZ Ardoz wrote:Nice one - Would love to know if there is a solution to the line issue, as it has been repeated. Not urgent, but more curious to learn what would make it happen, and if it is hardware or software relatedSouthfork wrote:Ok got to the bottom of it, was the way I was pulling the sketch from GitHub, simple copy n paste fixed it. All flashed now. One character line seems out of place on 1st letter but completwly useable, seems a few of us are getting this. Won't bother re-flowing pads, mucho happy
Well, as you can see on my displays, they have all lines...
But they jump around...ever 5 seconds one line switches position with an arbitrary one.
Maybe from the word next to it.
To me it almost looks like the error you get on Elements when the muxer is getting some astray voltage.
I installed Atmel studio and have access to the fuses now..
If you are saying my chip runs at 8mhz, that might be the problem.
According to the Adafruit instructions it should either run 12 or 16
https://github.com/adafruit/Adafruit_SSD1306
I will try Fusecalc and see what happens.
No risk no fun
Danke
But they jump around...ever 5 seconds one line switches position with an arbitrary one.
Maybe from the word next to it.
To me it almost looks like the error you get on Elements when the muxer is getting some astray voltage.
I installed Atmel studio and have access to the fuses now..
If you are saying my chip runs at 8mhz, that might be the problem.
According to the Adafruit instructions it should either run 12 or 16
https://github.com/adafruit/Adafruit_SSD1306
I will try Fusecalc and see what happens.
No risk no fun
Danke
The 4067 is definitely a key part in the chain. The F103 uses the 2x595 + 4 GPIOs to drive what it assumes are 4 segmented displays. Except the outputs of the 595s are muxed through the 4067 and scanned by the AVR, so if any of the mux lines or the software timing is off, the AVR will probably misinterpret the scanned data and display weird segments.Southfork wrote:I have seen builds where the corruption of the display is in a different place so guessing it's down to the construction. Does anyone have a perfect display? the pads on CD74HC4067 are too small but not sure if it's anything to do with the display problems, can anyone clear this up?
If the goal remains to keep the Braids firmware unchanged, it might be possible to improve the scan or maybe do it without the 595s/mux which would save space...Board could deffo do with a revision if there is any free space (cramped I know). I have another 2 of these so will solder that ic 1st while I have space to concentrate on it and see if that makes a difference
Thanks for clearing that up! And possibly shifts some of the display problem diagnostics to checking the connection of a difficult to sit icpld wrote:The 4067 is definitely a key part in the chain. The F103 uses the 2x595 + 4 GPIOs to drive what it assumes are 4 segmented displays. Except the outputs of the 595s are muxed through the 4067 and scanned by the AVR, so if any of the mux lines or the software timing is off, the AVR will probably misinterpret the scanned data and display weird segments.Southfork wrote:I have seen builds where the corruption of the display is in a different place so guessing it's down to the construction. Does anyone have a perfect display? the pads on CD74HC4067 are too small but not sure if it's anything to do with the display problems, can anyone clear this up?
If the goal remains to keep the Braids firmware unchanged, it might be possible to improve the scan or maybe do it without the 595s/mux which would save space...Board could deffo do with a revision if there is any free space (cramped I know). I have another 2 of these so will solder that ic 1st while I have space to concentrate on it and see if that makes a difference
The board still needs a revision and it its just because of the pad size.
My technic is to add tin to all pads, flux to the chip and heat both with hot air.
Then fuse them and hold the chip down until it settles...
if the pads would stand out one mm on each side one could easily use an iron.
There is enough space too.
My technic is to add tin to all pads, flux to the chip and heat both with hot air.
Then fuse them and hold the chip down until it settles...
if the pads would stand out one mm on each side one could easily use an iron.
There is enough space too.
That probably means the fuses haven't been written. The defaults are likely incorrect in this case since they use the internal oscillator at 8MHz.ArguZ wrote:Ok, the Fusecalc defaults for the 328P are the exact same fuse settings that are in there
Sorry, I don't have a platform to test it with but yeah, some who's programmed an AVR correctly from scratch with an Arduino sketch would be helpful. The boards.txt shows 0xff, 0xde, 0x05 fuses for Arduino/Genuino Uno (328p) so I assume that's right, but the IDE might only set them if you burn the bootloader.And selecting another board in the IDE does not change anything.
i don;t think i should mess with that without anyone with more experience/knowledge chimes in.
Man! I have 3 boards totally stuffed except that damn STMicro ARM chip. That thing is TINY! What tech iques are you guys using to solder it? No matter what I do, i get little bridges. Currently using .02" solder and a fine tip. Been looking for a well/cup type tip for a weller iron, tricky to find but still not sure if this would do the trick. Are you guys using solder paste? Heat gun? Oven? Interested to see your techniques since this one chip is the only thing holding me from completing this thing and I've been at it for hours and ruined at least one chip 
GryphonP3 wrote:Man! I have 3 boards totally stuffed except that damn STMicro ARM chip. That thing is TINY! What tech iques are you guys using to solder it? No matter what I do, i get little bridges. Currently using .02" solder and a fine tip. Been looking for a well/cup type tip for a weller iron, tricky to find but still not sure if this would do the trick. Are you guys using solder paste? Heat gun? Oven? Interested to see your techniques since this one chip is the only thing holding me from completing this thing and I've been at it for hours and ruined at least one chip
Use flux and drag solder. Put the solder, but not too much, on your tip. This tip has been good for me - Hakko T18-S7 - T18 Series Soldering Tip for Hakko FX-888/FX-8801 - Bevel - 1.2 mm/60? x 14.5 mm
Last edited by ZZ Ardoz on Tue Sep 27, 2016 1:44 am, edited 1 time in total.
That tip looks great, but will it work with my weller iron? I tried this technique and it worked for other chips, but this one tiny chip seems like any time i apply the tiniest bit of solder after flux, it clings imediately to the first 3 legs all together all the way up rather than allowing itself to be dragged. Seriously seems like it happens within milliseconds then is no longer on my tip.ZZ Ardoz wrote:GryphonP3 wrote:Man! I have 3 boards totally stuffed except that damn STMicro ARM chip. That thing is TINY! What tech iques are you guys using to solder it? No matter what I do, i get little bridges. Currently using .02" solder and a fine tip. Been looking for a well/cup type tip for a weller iron, tricky to find but still not sure if this would do the trick. Are you guys using solder paste? Heat gun? Oven? Interested to see your techniques since this one chip is the only thing holding me from completing this thing and I've been at it for hours and ruined at least one chip
Use flux and drag solder. Put the solder, but not too much, on your tip. This tip has been good for me - Hakko T18-S7 - T18 Series Soldering Tip for Hakko FX-888/FX-8801 - Bevel - 1.2 mm/60? x 14.5 mm
Sorry to derail thread with my own soldering issues! I guess its nice to know that its at least possible with the method I am trying
Switched to my heavy duty chisel tip. Now we're in businessdiablojoy wrote:with drag soldering you actually don't care too much about solder bridging the pins thats why you go back over it with solder braid and yes a larger tip actually helps in this case a flux pen is also a good idea
well, that killed the chip..Sorry, I don't have a platform to test it with but yeah, some who's programmed an AVR correctly from scratch with an Arduino sketch would be helpful. The boards.txt shows 0xff, 0xde, 0x05 fuses for Arduino/Genuino Uno (328p) so I assume that's right, but the IDE might only set them if you burn the bootloader.
Or at least made it impossible to program again
Narf. I did see a 16MHz crystal in the BOM? Because that's required then.ArguZ wrote:well, that killed the chip..Sorry, I don't have a platform to test it with but yeah, some who's programmed an AVR correctly from scratch with an Arduino sketch would be helpful. The boards.txt shows 0xff, 0xde, 0x05 fuses for Arduino/Genuino Uno (328p) so I assume that's right, but the IDE might only set them if you burn the bootloader.
Or at least made it impossible to program again
I'd double-check before doing that, IIRC the 12V is on the reset line only but it might go beyond the MCU (I think I only ever did that with DIP and outside the circuit).ArguZ wrote:Everything in the BOM is on the board...all from Mouser.
I have an AVR Dragon too, someone said i can HVreset the fuse bits with that one.
Not sure where the thinking error is, but if the fuses tell it to use the external crystal, it relies on that. Best course before further experiments might be to ask the designers.
- diablojoy
- Super Deluxe Wiggler
- Posts: 1624
- Joined: Fri Jan 22, 2010 9:03 pm
- Location: kiewa valley victorian alpine shire
Everything in the BOM is on the board...all from Mouser.
there is a 16mhz resonator and an 8mhz crystal in the mouser bom
the 8 MHz crystal is for the STM32
the 16mhz resonator is for the atmega328
check the 3 longish vertical pads just below the FTDI header in the boxed section
It probably wont happen today but if it does it definitely wont go smoothly.


