In wall light switch node - Custom PCB

[Samuel235]

With a little open-heart surgery, the board becomes alive! While I'm yet to actually burn any bootloader to the uC itself, I have no got the circuitry working.

The known issues:

• Capacitor on the SPI Header was incorrectly connected. I had wired it like a resistor/diode.
• The VCC line from the SPI was connected to the uC through the resistor of the RESET circuit.
• Battery holder is connected in reverse.

I have attached images for anyone interested in following this project with actual pictures of the progression through the revisions of this node. I have now made some alterations in my documentations regarding Rev1, listed the known issues and made some possible improvements:

• Remove one 47uF capacitor.
• Move the 47uF capacitor closer to battery terminal, and have all power traces coming through that capacitor, reducing the chance of the battery being drained through large spikes in draw.
• Add capacitor to FTDI VCC to stop spikes when connecting programming board.
• Increase silkscreen labels for document data such as pinouts and node info.
• Remove the 100uF capacitor on the nRF24l01+, add a 4.7uF footprint and 0.1uF footprint. Only populate if needed.
• Turn around the switch terminals, room should allow this.
• Bring the 0.1uF capacitors closer to the VCC inputs on the uC.

This week I will be aiming to get the designs and re-routes for Rev2 sorted out, and then get them ordered, with express shipping this time hopefully. The 3 weeks of waiting killed me!

Please give your feedback, if you have any.

[Samuel235]

I would like to ask if someone could just double check my Schematic and Board layout for me, just as a second pair of eyes before i send the gerber files over to ITead.cc in the morning. I'm pretty sure everything is as it should be, but would like a second pair of eyes to give it a scan over.

Can't wait to get Rev2 up and running to deliver the upgrades that have been made!

Thank you in advance

[m26872]

@samuel235 Look again at your Reset-Dtr net wiring compared to example and reference. Also C8 is probably ment to be in parallell with the battery.

[Samuel235]

@m26872 - I'll get that checked over tonight then. It was late last night when i finished it up. Thank you.

Just a quick bit of information released from about ITead.cc this morning:

[Samuel235]

@m26872 - I just have to connect the right side (positive connection) to the batt + right?

Then for the reset line, i've been having some horrible issues with understanding the connection for this and i genuinly thought i had it here with this Rev. I will study that and take a look soon as i get home today.

[Samuel235]

@m26872 said:

@samuel235 Look again at your Reset-Dtr net wiring compared to example and reference.

I'm sorry @m26872, however i feel that my reset line is connected correctly. I have used Atmel's recommendation to verify this and everything is exactly the same as they suggest to use apart from the fact i do not have a diode in there, which they recommend.

Also C8 is probably meant to be in parallel with the battery.

I have the negative connection made to the GND plane, then the positive receives its power from the BATT and then out to the various components now.

Below is 3 images, one for the modified BATT & C8 connection, one for the recommended reset circuit from Atmel, and the other is my actual reset circuit.

C8 & BATT

Atmel's recommendation for reset circuit

My Actual reset circuit

Please could you inform me where I am going wrong with the reset pin because I simply can't see anything to my knowledge.

[scalz]

I think you may add some net labels at RST, DTR. So it is less ambiguous to read
Here a basic sparkfun arduino mini schematic so you can check
https://cdn.sparkfun.com/assets/0/7/5/5/1/51eec304ce395f104c000000.png

[Samuel235]

@scalz - Labels have been added to make it easier to understand.

However, this is exactly how I wired Rev1, it didn't work until I hacked together the reset pin. I'm getting even more confused at to why my Rev1 didn't work now, I thought that by bypassing/altering the connections with some wires and it working would indicate that I had wired Rev1 incorrectly, I used the link you sent to me as reference while I was making Rev1.

However, i have done as you have suggested and attached images below. I've also attached my eagle files in case you wanted to trace any routes you can't see clearly on the images.

0_1453481212181_HominiSwitchNode.zip

[m26872]

Looks good now except that AVR ISP (JP1) pin 5 should connect straight to RESET and not to DTR.

[Samuel235]

@m26872 - Does the FTDI need to go to RESET or DTR? I'm feeling DTR because all the FTDI programmers i'm using is labeled with DTR and not RESET, am i correct in assuming this?

[m26872]

@samuel235 Yes.

[Samuel235]

@m26872 - Perfect. Thank you for your assistance, I really appreciate it! I'll get these ordered tonight hopefully and then keep looking at the circuitry for my RESET and DTR line to memorize it and work out why its so hard to get into my brain xD.

Just one last confirm, since I'm not that confident with myself at the moment regarding this RESET line, if you don't mind.

[m26872]

@samuel235 Reset and Dtr routing looks correct, but you still have DTR silkscreen label next to AVR ISP.

[Samuel235]

@m26872 said:

@samuel235 Reset and Dtr routing looks correct, but you still have DTR silkscreen label next to AVR ISP.

Indeed I do, the board itself isn't finished yet, I just wanted you to clarify the wiring was correct. Time to tidy it up, finish the annotating and get it finalized. However, thank you for pointing it out to me (Shows you're actually paying some attention to this). Thank you, yet again. The level of support and time you dedicate to helping others on here is outstanding. It is most certainly noticed!

[m26872]

@samuel235 You're very welcome. We'll all benefit when you succeed.

[Samuel235]

UPDATE!

Revision 2 boards have now been submitted for manufacturing. Standard shipping used, so expecting within the next 23 days. This is going to pain me!

On the side note, I've enrolled for Open University and will be studying now for around 4 years. I'm doing a Computing and IT degree to follow on from my existing IT Qualifications (Microsoft and CompTIA). I do hope to incorperate this community and the projects i take on with you guys into my studying. I also do not expect this to effect the time and effort I'm able to spend with you guys here and developing our projects together.

I will update you ASAP, when these boards get here

[scalz]

great

[Samuel235]

I will upload this device to Openhardware.io as soon as i have it built up and the basic functionality working. Hopefully then it will become much easier for the starting MySensor budding builders to understand and follow. I may do a 'basic build instructions' that can be followed on how to get this working, including putting the hardware together.

[Samuel235]

Board Revision2 got delivered today and obviously i set about populating the board instantly!

I have the board all completed and now I'm attempting to burn the bootloader on. Before i go ahead and screw my IC up (I read if you use the wrong fuse reading for the timing of the clock you can't Re-burn anything else to it) i would like some advice. I've detected the current/pre-set fuse readings through AVRDUDESS using a clock speed of 93.75KHz, so i know the connection between my computer and the board is working. The readings for the fuses are below:

I'm currently using the fuse calculator here to workout the fuses needed. I'm also looking at Maniac's blog post here as he made a very low power module. The only thing i would question about his version/board is that his brownout is set to 2.7v. I've checked the nRF module and the lowest voltage it can go is 1.9, so maybe i should bring the BoD reading down even more or even disable it all together (I plan on reading the battery voltage from this module anyway).

The below settings for the fuses are my own workings out with the fuse calculator linked above, I'm doubting myself here, i'm in territory that i'm not comfortable with so I'm more than likely making a mistake here but what do you think? The BoD is set to 1.8 here:

Low: 0x62 | High: 0xD9 | Extended: 0xFE

Once i have confirmed a fuse setting, Do I edit them into the board.txt config of Maniac's blog post or do I use that of @tekka's?

[m26872]

I have a very brief guide here, under 'Software'. There are some links to other guides as well. I think you use (42, DE, 07/FF) together with that linked bootloader (important).

I also think Maniacs guide is a little old. You should get a a lot lower power by using MySensors lib and other some other tricks and settings.

[Samuel235]

@m26872 From having a quick look at your guide, you bring your clock speed right down to 1MHz, am i correct in thinking this? Do you have any timing issues at all, is the node still quick enough to respond to switching and sensor detecting or is there a delay in the signal sending?

[m26872]

@samuel235 Yes, it's working. But you can't use some things like DS18B20s and DHTs at these low frequencies. Si7021 etc are used instead. Button switches and other simple things are exellent applications.

[Samuel235]

@m26872 - Well, I was planning on maybe having a temp sensor in there at some point, but not this revision. So if i went without that function at the moment it wouldn't be the end of the world, i would just revise even more for the next revision. I'm presuming that you have taken it to 1MHz for power saving or?

This is the configuration i'm thinking:

######## settings for 8Mhz internal clock

proMYSBL8.name=ATmega328 internal 8Mhz with MYSBootloader
proMYSBL8.upload.tool=avrdude
proMYSBL8.upload.protocol=arduino
proMYSBL8.upload.maximum_size=30720
proMYSBL8.upload.maximum_data_size=2048
proMYSBL8.upload.speed=57600
proMYSBL8.bootloader.tool=avrdude
proMYSBL8.bootloader.low_fuses=0x42
proMYSBL8.bootloader.high_fuses=0xDE
proMYSBL8.bootloader.extended_fuses=0xFF
proMYSBL8.bootloader.unlock_bits=0x3F
proMYSBL8.bootloader.lock_bits=0x3F
proMYSBL8.bootloader.file=MySensors/MYSBootloader.hex
proMYSBL8.build.mcu=atmega328p
proMYSBL8.build.f_cpu=8000000L
proMYSBL8.build.board=AVR_UNO
proMYSBL8.build.core=arduino
proMYSBL8.build.variant=standard

That would remove the brownout, enable SPI, and put the clock to 8MHz. What is your thoughts on this config?

[m26872]

@samuel235

• You'll need low MHz for ot to work when battery runs out and voltage decreases.
• Those fuses are for 1MHz, not for 8MHz.
• I've never used MYSBootloader. Someone else has to confirm the settings if you use this.

[Samuel235]

@m26872

Lower clock speed would last through the low power phase of the battery. Obviously, thank you for pointing that out! However, I'm looking at Maniacs battery testing graph and the battery is stable down to around 2.4v for around 150 hours, then it will rapidly drop off to 0v, so I'm thinking "is the lower clock speed really worth the extra 10 hours of use?".

The fuses, although I am going off of what you suggested, i entered them into my fuse calculator and its showing up at 8MHz, with no modification needed to the speed.... I'm a little confused at this part as you have now said that those fuses are for 1MHz.

I'm now wondering if its worth using MYSBootloader or the one you used, I can see that you used this and programmed through the Arduino IDE, from your post you said you're more comfortable with using the Arduino IDE (Which i am too, but can adapt if needed).

[scalz]

@samuel235: don't worry about 1mhz...there is no big difference 1Mhz vs 8Mhz at 3V in deepsleep mode. In deepsleep mode, at 3V 8Mhz internal rc, you can get 140nA. So you can't have such interesting diff.
In other hand, if node is wake up, you are in mA range, and here it can be interesting to play between clock and voltage you can do it on the fly in sketch and it's good to know that for timing things, atmel clock and voltage are linked.
So i would suggest you to stay with internal rc 8Mhz, BOD 1.8V and MYSBootloader. If I remember right it should be ok. Other thing good to know, you can disable BOD=0V when in deepsleepmode (this is done like this in lib I think), but it's not a good practice to disable it when wake up. Keep 1.8V limit, it can prevent some bugs..All is described in datasheet

Another thing good to know, as I see lot of peope estimation for coincell...there are lot of chance that you can't get the full coincell capacity, depending on the application, the use. A common "prevision is to plan 80% of its capacity. It's due to the rate of discharge of battery and coincell's one is small..
There are lot of others resources on the subjects but here few links :
https://www.dmcinfo.com/Portals/0/Blog Files/High pulse drain impact on CR2032 coin cell battery capacity.pdf
http://www.embedded.com/electronics-blogs/break-points/4429960/How-much-energy-can-you-really-get-from-a-coin-cell-
http://www.ti.com/lit/wp/swra349/swra349.pdf

[Samuel235]

@scalz This is the information that was much needed. Right, so my settings are going to be:

######## settings for 8Mhz internal clock

proMYSBL8.name=ATmega328 internal 8Mhz with MYSBootloader
proMYSBL8.upload.tool=avrdude
proMYSBL8.upload.protocol=arduino
proMYSBL8.upload.maximum_size=30720
proMYSBL8.upload.maximum_data_size=2048
proMYSBL8.upload.speed=57600
proMYSBL8.bootloader.tool=avrdude
proMYSBL8.bootloader.low_fuses=0x62
proMYSBL8.bootloader.high_fuses=0xD9
proMYSBL8.bootloader.extended_fuses=0xFE
proMYSBL8.bootloader.unlock_bits=0x3F
proMYSBL8.bootloader.lock_bits=0x3F
proMYSBL8.bootloader.file=MySensors/MYSBootloader.hex
proMYSBL8.build.mcu=atmega328p
proMYSBL8.build.f_cpu=8000000L
proMYSBL8.build.board=AVR_UNO
proMYSBL8.build.core=arduino
proMYSBL8.build.variant=standard

At the moment the fuses are set using Hexadecimal notation, I'm sure that I read somewhere that to burn this using a Arduino IDE you need to use normal binary rather than Hex. Do you know if Hex is okay for Arduino IDE?

I've got those fuses set to enable 1.8v BoD, 8MHz clock with a 65ms delay on startup. This will use MYSBootloader too. Does this sound okay to now edit my boards.txt, and burn the MYSBootloader.hex file to the chip? I'm using a USBASP device connected to my ISP connection. Am i forgetting anything at all here? As far as I'm aware of, i now plug the board and USBASP into my computer, load the .hex file into arduino IDE and burn using the board config i have put into my boards.txt file. Then i can use my FTDI adapter to then burn sketches to the board through the arduino IDE?

I know that to some people I may be asking what seems like the same questions over and over but I'm starting to feel very confident with embedded chips now. Thank you!

[scalz]

no problem yes, it sounds ok...that's how I do too. But I don't use mysbootloader, i use dualoptiboot (sensebender bootloader). for the hex/bin fuse notation, I use hexa.

[m26872]

@samuel235

• You could be rigth regarding the battery. I've no coin cell experience.
• You noticed the check mark by the 'divide clock by 8' ?
• If you by 'program' normal ftdi flash, then yes. I didn't program bootloader with Arduino.

[Samuel235]

@scalz

Is there a reason to use dualoptiboot over MYSBootloader or is that just something you did for no reason?

Did you use Arduino IDE to burn your bootloader, if so then i can confirm its okay to use Hexa for my board with arduino IDE, if you didn't i will have to convert it to normal binary.

@m26872

I have just realised that you burn your bootloader with the check mark of 8MHz but then the board.txt is configured to set it to 1MHz, is that what you're trying to tell me? I'm not too sure on your last point, i don't get what you're trying to say if i'm honest, could you elaborate a little? Sorry.

[scalz]

@samuel235: yes, always good reasons I have tried both. both works well. I like the "buffer style" of dualoptiboot. plus no mysensors lib in bootloader, few others reasons...but mysbootloader is very cool too and simple. So don't worry about this it's a matter of taste, each have their pros&cons.
Yes, use arduino ide to burn bootloader + hexa is ok.

[Samuel235]

@scalz - Perfect. I will see how i get on with the MYSBootloader style. Soon as i get back i will burn these settings to my uC and see how i get on. I will come back with the results when i'm done.

[m26872]

@scalz

• Don't know if good practice or not, but I run 328p + nRF down to 1.6V very stable. Could depend on a lot things and conditions of course. You said "some bugs" - do you know more what risks there are? Permanent damages etc?
• Do you know if the 'Divide clock by 8" (8MHz or 1MHz) also can be changed on-fly-with code? If so, does it matter which speed set by fuse and thus used at start-up?
• Great thanks for the coin cell info!

[m26872]

@samuel235 I meant that you should untick this to use 8MHz. Provided that you don't change it on-the-fly somehow.

[m26872]

@samuel235 Sorry for not elaborating. I've been mobile all day until now. And my phone also seems to have a few issues with the forum.

[Samuel235]

@m26872 Ahh right okay, good job i caught your reply before burning it haha! So if i set it to 8MHz internal with 64ms delay and untick that divide by 8 option, that'll be good?

[m26872]

Yes. but don't forget to enable the boot reset vector.

[m26872]

@samuel235 I have not checked if the bootloader size and baud rate matches fuse settings.

[scalz]

@m26872:

• for bod=0v, problems could be flash corruption for instance..so it's good to know (it's explained in datasheet that for instance it ensures that a flash write is completely done before reset, I think it makes sense, plus I imagine that there are some internal things with voltage levels related stuff. but I'm not a guru on this....). So my interpretation is sometimes we don't care about it for sleepmode, for instance, and sometimes in wakeup, it's important or not, depending of tasks involved...
  maybe I should have said a good practice is to know what you do, lol!
• for prescaler, are you asking for something like this : http://www.gammon.com.au/forum/?id=11497&reply=7#reply7
• glad to share what I learn

[m26872]

@scalz .

maybe I should have said a good practice is to know what you do, lol!

l don't fulfil that either, lol!

Thanks for the prescaler info. Seems like a yes - it can be changed on-the-fly, but for me it's a No. I won't even dare to think of consequences for the rest of the software.

[Samuel235]

@m26872 said:

@samuel235 I have not checked if the bootloader size and baud rate matches fuse settings.

I'm not 100% sure of what you mean here, on the fuse calculator there is not an option to specify the baud rate.... As for the bootloader size, the calculator is set to "Boot Flash section size=2048 words Boot start address=$3800; [BOOTSZ=00]". As this is the highest it can be I'm assuming it is correct, however i will try and check the size of the MYSBootloader.hex size and see if it is below 2048 words (Is this what this setting means?).

[m26872]

@samuel235 No, but bootloader and boards.txt must have same buad rate. I think you already have the correct though since 8MHz is pretty much standard clock speed. Slower clock would require lower buad rate.

[Samuel235]

@m26872 Is there a way to read the .hex file to see the specified baud rate before i go and brick the chip? Also, just to confirm, i have to burn the fuse settings in AVRDUDE then burn the bootloader with arduino IDE. Is there anything I'm failing to understand, i only have one more uC here at the moment and i don't want to brick several of them

[m26872]

@samuel235 Sorry, I can't help you further. I don't know for sure about these things.

[Samuel235]

@m26872 - That is okay, I think I'm pretty safe to assume that it is correct as it is what is provided on Tekka's guide. So I'm going to attempt to burn the fuses at E2 D8 FE. Once I've done that (and it works fine), Arduino IDE should burn the bootloader onto the uC without an issue and then i can just upload a arduino sketch, right? o.O

[Samuel235]

I've just written the fuse settings and got this log report:

avrdude.exe: set SCK frequency to 187500 Hz
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% -0.00s

avrdude.exe: Device signature = 0x1e950f
avrdude.exe: reading input file "0xE2"
avrdude.exe: writing lfuse (1 bytes):

Writing | ################################################## | 100% -0.00s

avrdude.exe: 1 bytes of lfuse written
avrdude.exe: verifying lfuse memory against 0xE2:
avrdude.exe: load data lfuse data from input file 0xE2:
avrdude.exe: input file 0xE2 contains 1 bytes
avrdude.exe: reading on-chip lfuse data:

Reading | ################################################## | 100% -0.00s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lfuse verified
avrdude.exe: reading input file "0xD8"
avrdude.exe: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude.exe: 1 bytes of hfuse written
avrdude.exe: verifying hfuse memory against 0xD8:
avrdude.exe: load data hfuse data from input file 0xD8:
avrdude.exe: input file 0xD8 contains 1 bytes
avrdude.exe: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of hfuse verified
avrdude.exe: reading input file "0xFE"
avrdude.exe: writing efuse (1 bytes):

Writing |  ***failed;  
################################################## | 100% 0.09s

avrdude.exe: 1 bytes of efuse written
avrdude.exe: verifying efuse memory against 0xFE:
avrdude.exe: load data efuse data from input file 0xFE:
avrdude.exe: input file 0xFE contains 1 bytes
avrdude.exe: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x06 != 0xfe
avrdude.exe: verification error; content mismatch

avrdude.exe done.  Thank you.

I then checked the fuses by reading them. I can confirm it has written the Low and the High fuse but as the log says, it failed to write the extended. So I went to the calculator site and read the following (This is what i was asking about hex vs binary for):

"Note that some numerical values refer to fuses containing undefined bits (set to '1' here). Depending on the target device these fuse bits will be read either as '0' or '1'. Verification errors will occur if the values are read back with undefined bits set to '0'. Everything is fine if the values read from the device are either the same as programmed, or the following values (undefined set to '0'): Extended: 0x06."

I then attempted to burn the bootloader, assuming the error is fine to skip (as the fuse calculator said), but it gave me the same error of:

avrdude: verification error, first mismatch at byte 0x0000
         0x06 != 0xfe
avrdude: verification error; content mismatch

So basically, telling me that my boards.txt is telling the IDE that the fuse should be FE, but its 06.

[m26872]

Looks like ext fuse is already 0x06 and you only need to change your board.txt to the same. I've never heard before that the 0xFE type of writing should work in avrdude/Arduino IDE.

[Samuel235]

I went ahead and changed my board.txt to reflect 0x06, to check. It passed through and burnt the bootloader. However, if i try to upload a sketch (using the FTDI adapter that i have, this) I get a timing error. How do i upload a sketch to the chip with the ISP connection (just to test if my FTDI pins are wired incorrectly). This is my log from arduino IDE:

Sketch uses 12,610 bytes (41%) of program storage space. Maximum is 30,720 bytes.
Global variables use 398 bytes (19%) of dynamic memory, leaving 1,650 bytes for local variables. Maximum is 2,048 bytes.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x7c
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x7c
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x7c
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x7c
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x7c
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x7c
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x7c
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x7c
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x7c
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x7c
Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.

"programmer is not responding" - I was asking myself "Would this mean that arduino IDE can't use avrdude for some reason?" but then i figured that it used it to burn the bootloader so that isnt right. Is it trying to find the ISP programmer and cant because i'm connected through FTDI maybe?

[Samuel235]

I have just remembered that if you go to the file menu in Arduino IDE you get the option to upload using programmer. I have just done this through my SPI programmer, it has uploaded correctly. I will now solder the nRF module onto the board and i will report back with my results. Crosses fingers

[Samuel235]

BINGO!!

We have a working coin cell powered light switch.

I will upload some decent images later on tonight or tomorrow.

I'de just like to talk everyone that has contributed to this thread/post and enabled me to create my first of many embedded projects. I'm applying for a University course in september for Computer Science (Smart Technologies), all about embedded systems, drones, home automation etc etc. This is just the beginning!

I'll get this project up on OpenHardware.io asap as Version 1 and we can build on this as a base plate for futher projects.

[Samuel235]

Now, the next two steps I'm interested in taking is to get this working with 2 switches (Software modification, should be simple) and then to have it report its remaining power every 30 minutes to allow me to set up notifications through openhab to alert me to change the batteries so I'm not left with no light switch.

[Samuel235]

It would appear that I'm having a timing issue with uploading via the FTDI adapter. Would this be down to the speed of the uC effecting the RX and TX connections?

[m26872]

This post is deleted!

[m26872]

@samuel235 Are you trying to upload with Ftdi serial to MYSbootloader? I think it's only for OTA uploads, if you read here.

[Samuel235]

@m26872 - Thank you for pointing this out to me. I'm unsure why I haven't stumbled across that thread/topic today of all days, been searching and reading about MYSBootloader all day >.<

From personal experience, would you advise any other bootloader, I'm guessing you're going to tell me about the one you are using. Could you link any information for me to check out regarding your choice of bootloader?

Am I correct in recalling you're using DualOptiBoot?
Does DualOptiBoot need external memory/flash?

[m26872]

@samuel235 No, I use plain optiboot, but I couldn't find a suiteable precompiled one for you. DualOptiboot requires external flash as you say.
It's been a while since I played with bootloaders, but I think normal 8MHz Arduino Pro Mini bootloader would work for you with internal clock as well. It's this [ATmegaBOOT_168_atmega328_pro_8MHz.hex ] and I can find it in my "C:\Program Files\Arduino\hardware\arduino\avr\bootloaders\atmega" -folder, should be about the same for you I think. Try fuse settings E2-DA-06 (Lo-Hi-Ex) and rest of the boards.txt-settings from ArduinoProMini 3.3V 8MHz.

[Samuel235]

@m26872 - Ahh the generic arduino bootloader... I will have a look into using that tomorrow. As the MYSController gets more feature rich and support i will use that setup, however i love OpenHAB way too much to switch over right now.

[Samuel235]

@m26872 - I've just spent a few minutes looking through my boards.txt and i came across:

######## Settings for 

ATmega328 8MHz Internal clock
atmega328bb.name=ATmega328 on a breadboard (8MHz internal clock)
atmega328bb.upload.protocol=stk500
atmega328bb.upload.maximum_size=30720
atmega328bb.upload.speed=57600
atmega328bb.bootloader.low_fuses=0xE2
atmega328bb.bootloader.high_fuses=0xDA
atmega328bb.bootloader.extended_fuses=0x05
atmega328bb.bootloader.path=arduino:atmega
atmega328bb.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb.bootloader.unlock_bits=0x3F
atmega328bb.bootloader.lock_bits=0x0F
atmega328bb.build.mcu=atmega328p
atmega328bb.build.f_cpu=8000000L
atmega328bb.build.core=arduino:arduino
atmega328bb.build.variant=arduino:standard

Then out of interest I thought I would look at the bootloader that you suggested, to see what difference there would be. Turns out I was actually looking at it without knowing. I have a feeling that if I change the fuse settings to those that i am using now with MYSBootloader, I will be set to go.

The High Fuse setting you provided enables 1024 words in the boot flash section, a couple of questions about this:

• Is this defining the size of the area needed for the bootloader section on the built in memory (So smaller this is set to, as long as the bootloader will fit, the more room I will have for a sketch)?
• How do i find out the 'word size' of the bootloader (if the first question is correct method) so I can determine if the 1024 is big enough? I would rather know how to work this out rather than just assuming that it is because it is specified as that as default.

I was going to leave my fuses where they were at (E2, D8, 06 as LO:HI:EX) but if I can change the boot size setting, that would allow a bigger room for my sketches = Win Win!

I'm still slightly confused as to not being able to burn my extended fuse. I have read somewhere (lost the page) about not being possible to burn an EX fuse on a ATmega328p, which i find very hard to believe.

[m26872]

@samuel235 said:

• Is this defining the size of the area needed for the bootloader section on the built in memory (So smaller this is set to, as long as the bootloader will fit, the more room I will have for a sketch)?

Yes.

• How do i find out the 'word size' of the bootloader (if the first question is correct method) so I can determine if the 1024 is big enough? I would rather know how to work this out rather than just assuming that it is because it is specified as that as default.

I don't have the tool or knowledge for that. Should be doable by removing indices and count the bytes in hex-file. But for me it's not a big deal to just use the size settings recommended for a particular bootloader. And in this case it´s stock Arduino, so why question it.

I'm still slightly confused as to not being able to burn my extended fuse. I have read somewhere (lost the page) about not being possible to burn an EX fuse on a ATmega328p, which i find very hard to believe.

So the '0x06'-kind of notation didn't work either? Strange.

[Samuel235]

@m26872 said:

And in this case it´s stock Arduino, so why question it.

I'm not questioning it, I just wanted to learn how to do it for if i ever came across a need to modify a bootloader i would then know how to record its size for the fuse burning.

So the '0x06'-kind of notation didn't work either? Strange.

When i set the boards.txt file to read 0x06 it worked perfect, which insinuates that it couldn't burn the chosen BoD, even though the fuse calculator says to ignore the error of the extended fuse, it should burn it even though it gives the error. I'm interested in trying to burn the extended fuse in normal binary rather than hexa. But i doubt it would work anyway.

[Samuel235]

It has just clicked inside my busy mind that 0x06 in binary is the same as 0xFE in Hexa. How embarrassed am I now after many questions and hours thinking about the extended fuse value. I'm now assuming that it returns the error because it is already set at that fuse

[Samuel235]

So, i have it working using the following board.txt config:

######## Settings for 

ATmega328 8MHz Internal clock Brown-out detection 1.8v
atmega328bb.name=ATmega328 on a breadboard (8MHz internal clock) BoD1.8
atmega328bb.upload.tool=avrdude
atmega328bb.upload.protocol=stk500
atmega328bb.upload.maximum_size=30720
atmega328bb.upload.speed=57600
atmega328bb.bootloader.tool=avrdude
atmega328bb.bootloader.low_fuses=0xE2
atmega328bb.bootloader.high_fuses=0xDA
atmega328bb.bootloader.extended_fuses=0x06
atmega328bb.bootloader.path=arduino:atmega
atmega328bb.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb.bootloader.unlock_bits=0x3F
atmega328bb.bootloader.lock_bits=0x3F
atmega328bb.build.mcu=atmega328p
atmega328bb.build.f_cpu=8000000L
atmega328bb.build.core=arduino:arduino
atmega328bb.build.variant=arduino:standard

However, no matter what I did I couldn't get it to upload via FTDI. I've tried looking at the Arduino Pro Mini settings in boards.txt to see what 'upload.tool' it uses, AVRDUDE, same as i specified. I also then went to the google docs for the boards.txt reference file, that advises everything i did too. I'm a little stumped. All that i can think of is that i have wired it incorrectly on the pcb. Whats your thoughts on this?

[m26872]

@samuel235 said:

I'm not questioning it,

I'm not saying you do, I just told how I think of it.

I'm interested in trying to burn the extended fuse in normal binary rather than hexa.

Why, when the result is exactly the same?
Also, I'm not familiar with from where the "binary or hexa" comes from? They're both hexadecimal notation as far as I can see.

[scalz]

I'm not sure what is your problem with ftdi.maybe wirings...do you have cts to gnd, and of course dtr to dtr, only one vcc active...??? Maybe you should try to burn original arduino ide bootloader and then ftdi upload attempts. If it still doesn't work, it could be the wirings...
for hexa vs binary..in some case binary notation can be useful, but for fuses, I prefer hexa: shorter, no possibility of mistakes by missing/miscounting one "1" or "0" bit

[Samuel235]

@m26872 - I wanted to try it because i'm sure i read somewhere that the ATmega328 can't accept Hexa as fuses. But i doubt that information is valid if i'm honest with you.

@scalz - I have dtr to dtr and cts linked to ground. I also only have one VCC pin (which obviously goes to VCC). I'll be perfectly honest with you; the boart.txt setting i posted above, i thought that was using the arduino .hex bootloader, please inform me if i'm in correct in that.

[Samuel235]

This is the board layout, if you guys can see any issues with my FTDI connections/pinout please advice me that you do, I will get that sorted for revison 3 of the board. If i'm honest, I don't mind burning the sketches with the ISP programmer everytime, so I'm very tempted to remove the FTDI, allowing a smaller board still.

[m26872]

@samuel235 How do you debug through ISP ?
Have you tested your FTDI USB-serial converter with ArduinoProMini or something?

[Samuel235]

@m26872 - I haven't tried it out with a arduino pro mini, because i don't have one. However, tomorrow, I will get a Arduino nano out and sort some testing of my FTDI converter on that. I'm hoping that works and its just a simple wiring issue on my board.

From your statement of "How do you debug through ISP?" I'm guessing that it isn't possible too, or was that a genuine question? If its not possible then I will keep the FTDI connectors on the board.

[m26872]

@samuel235
I think you should get yourself a APM (ArduinoProMini) as a reference device. While waiting I think you could wire a DTR circuit to your Uno or Nano and see if you can get your FTDI to talk through rx/tx there.

The "debug through ISP" is a genuine question. My guess is that it's possible if your bootloader, programmer and IDE support it.

[sundberg84]

Yea, we talked about this as well @m26872 the other night... and to make it easy I also suggest having the fdti connector - if your node is about other to use it (new members to mysensors) thats they easiest way to be able to debug.

Its possible to debug through SPI, [1, 2 , 3] but requiers extra code in your sketch. With fdti you can just user serial.println();Also it looks like you need an second arduino acting with some code... to read and print on that second device serial.... have not read everything through... but its a bit of work it seems.

[Samuel235]

@m26872 - I'm going to get a APM sorted asap. Then i'll get to try my FTDI converter checked.

@sundberg84 - Way too much hassle for what its worth, I will trouble shoot and sort out my existing connection for FTDI.

[Samuel235]

Current Situation Update

The board is completely populated with correct hardware, tested for 24 hours functioning, working completely fine. There is a slight delay now and then between the switching state and the light illuminating, only sometimes, but nothing major (1/1.5 seconds). The fuse setting and the bootloader burning went unbelievably smooth, very easy once i got my head around all the different settings needed and why they were needed in certain situations. I'm currently using the default arduino bootloader (ATmegaBOOT_168_atmega328_pro_8MHz.hex), burnt with a ISP connection using AVRdudess for the software. I'm unsure if the device is sleeping between readings of the switch but that will be easily noticed soon as i get my FTDI situation fixed.

Talking about FTDI Issues, I'm currently stuck with not being able to upload a sketch through FTDI, its hanging on the "upload" status in Arduino's IDE. I don't think it is a driver issue as my computer has always been configured to never update a driver through windows update (Just confirmed this through the advanced computer settings). The driver that I'm currently using is version 3.3.2011.11. However, if there is no issue with my wiring (shown in a recent previous post/comment above here) i'm struggling to see what else the issue could be other than soldering issues, which i can't notice from a few look over attempts using a 25x magnifier, I will give it another look over to make sure though.

Which attempting to troubleshoot this, I have noticed that if I have the MYSbootloader on the chip and then attempt to upload a sketch (which i know wont work anyway due to MYSbootloader settings/usage rules) I get the generic message of memory allocation:

Sketch uses 13,678 bytes (44%) of program storage space. Maximum is 30,720 bytes.
Global variables use 438 bytes (21%) of dynamic memory, leaving 1,610 bytes for local variables. Maximum is 2,048 bytes.

Where as if I use the default arduino bootloader I only get:

Sketch uses 13,678 bytes (44%) of program storage space. Maximum is 30,720 bytes.
Global variables use 438 bytes of dynamic memory.

It completely misses out showing what space is left for the local variables. Could this shine any light onto the issue? The actual error that I am getting for the MYSbootloader version (after waiting literally over 1 minute from pressing upload), again that is expected, however the default bootloader version just hangs in the uploading state, its been there for well over 5 minutes without giving me an error now. Just to add, they both have the same 'upload.speed=57600' in their respected boards.txt config.

The FTDI Issue is my only major issue on this board now, revision 3 will be just minor fixes, such as adding pull-up resistors between the switch and VCC, a more detailed list will be announced when revision 3's designing process starts.

[Samuel235]

Just to let everyone that is reading this thread know that it is possible to brick your uC with the simplest of mistakes. It would seem that i have bricked my uC by burning the Arduino Pro Mini bootloader to it. The file that i burnt was 'ATmegaBOOT_168_atmega328_pro_8MHz.hex' designed for the Arduino Pro or Pro Mini (3.3v, 8MHz). I will be perfectly honest and admit that i genuinely don't know why it bricked it. I just thought that as long as the uC signature matched that of the bootloader you was burning it can be any .hex file, as long as it matched that uC. Seems that for some reason this didn't like it. If someone would like to give some more in-depth information regarding this to just allow people here a little more knowledge on this subject to aid in them not making the same mistake, that would be appreciated by all.

[mfalkvidd]

I think this is why it doesn't work: The standard Pro Mini bootloader assumes a 8MHz external oscillator. This board hasn't got one, so the mcu gets no ticks.

I'm not sure but I think it is possible to re-orogram it.

[Samuel235]

@mfalkvidd - Oh C**P! An external OC, I completely forgot about it being a external one. Damn it! I'll get a 8MHz OC ordered and then just temp wire it into the circuit and hope it works by a huge bodge job. Do you have any thoughts on why I could upload via FTDI (as per the post above detailing everything regarding this issue)?

@sundberg84 - From our private messages, this is one of those very simple mistakes, made here by myself. Now, see how easy this mistake is? Don't be a fool like me and do the same haha!

[mfalkvidd]

Sorry, I have never tried rolling my own. But there's lots of clever people here, someone should have some advice.

[m26872]

@samuel235 I only see two possible causes. Either you changed the fuses unintentionally or you hw-bricked it with supply voltage, ESD or somehing. In the first case you'll just have to connect the external xtal ( likely 8MHz if you burned the standard APM 8MHz fuses).

[Samuel235]

@mfalkvidd - Alrighty

Just to let people know, i think that where i went wrong here is the fuses. Even though i burnt my fuses before the bootloader to the correct fuses that i want, I think that i didn't restart Arduino IDE after i saved the boards.txt file. Just make sure you don't do this! Always restart the IDE after altering any info in boards.txt.

[Samuel235]

@m26872 - Well to be honest, the way that i was throwing around possible solutions i'm guessing that its just a silly mistake with fuses in the boards.txt file. But would this just not burn the bootloader, i wouldn't have incorrectly burnt the fuses, i took 100% care over that, i came back here to double/triple check the fuses that i wanted from a previous comment i made. I burnt those and i changed the boards.txt and didn't restart the arduino IDE i dont think. But wouldn't this just not burn the bootloader?

Maybe if that is correct of me thinking this, then i could have bricked it with power/esd like you mentioned. Either way i have ordered some crystals to troubleshoot this.

[Samuel235]

The Arduino Pro Minis and another FTDI adapter has arrived today along with my crystals. We have news...

• Firstly, I got the fuses and bootloaders back to the correct ones (E2 DA 06) and the arduino bootloader, no issues here.
  I then tried the new FTDI adapter - Still nothing.
• Then it was the turn of trying an arduino pro mini with FTDI. Nothing there either. So i started to get puzzled at this point...
• I turn my mac on, tried it on there. I installed the drivers and allowed them to be used by running 'csrutil enable --without kext' in a terminal inside of recovery mode. Logged in, it recognized the FTDI chip, but couldn't upload to the APM. It is throwing out the same error of "avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xee"

I'm yet to start googling the error code, that will be my next step to take. Its very much looking like the adapter is not able to chat to the board and since its happening on both boards i'm thinking that i may be doing something silly.

[Samuel235]

The arduino nano that i have uses the same serial chip that the FTDI adapter does, CH340G. Please correct me if i'm wrong in saying this, if i had a broken/incorrect driver for that CH340G then i wouldn't be able to upload via USB to my arduino nano?

[mfalkvidd]

Ch340g is not able to auto-reset the Arduino. You need to press reset manually, just after the Arduino IDE prints "Uploading". Maybe that's the problem? More information is available at http://www.avrfreaks.net/forum/how-do-i-program-arduino-pro-mini-ch340g-usb

[Samuel235]

@mfalkvidd - I was attempting this last night. I spent 20 minutes doing this, i will attempt again tonight to see if i was doing it at the correct time.

[Samuel235]

That article is regarding the CH340's that do not have the DTR pin, however mine does. Either way i have just spend another 10 minutes trying to get it to load a sketch to two APM's and nothing, I've tried pressing the reset on the adapter and the arduino when it prints "uploading..." and i've also tried holding the reset down and releasing it when it prints the updating... message too. Nothing still

[Samuel235]

So with a few wiring alterations of connecting the adapter's pin GND to the GND of the APM, rather than the CTS on the adapter to the GND of the APM it works. However, it won't work going to my board, it gives me 'avrdude: error reading signature data for part "ATmega328P", rc=-3' and if i switch the gnd and the cts around on my board (which on my board design is connected together) it can't even connect to the device. I will be troubleshooting this tonight and tomorrow now. At least we're slightly further forward!

[Samuel235]

Just a quick mini update:

I'm still having issues after several days of FTDI troubleshooting. I think I can safely assume there is an issue with my FTDI section, on my board itself. I have uploaded a binaryswitch sketch to the uC with the ISP 'upload through programmer' option, uploaded perfect like normal. I then plugged the board in with my FTDI serial adapter, i couldn't monitor the serial port, nothing in the monitor. I had enabled the debug too. So, the basic things i have done at the moment are:

• Switching the gnd and cts pins to find a combination that works, nothing.
• Switch Rx and Tx around, nothing.

Once i get home from work today i will be troubleshooting to see if there are any other things that i should have included into my FTDI section that maybe i didn't do. If anyone has any input on this section, I would love to hear it.

[jeylites]

@samuel235

Nice work so far. I had a similar idea to use Binary Switch to turn ON/OFF my relays and lights but I had to discard the idea after going through several issues. Occasionally my serial gateway would fail to connect to the Vera and it would paralyze all my lightings. Essentially the Binary switches talk's to the Relays by going through the gateway. So decided to redesign the electronics to accommodate Relay with Button Actuator Sketch. If you lose the gateway, you could still bet that it would work though I wouldn't say it's 100% reliable but it gets the job done. Lately, I'm also exploring other avenues to somehow use www.Souliss.net concepts on MySensor and I was informed that My sensor Ver 2.0 Beta has got something similar by using ESP8266. I don't know how much of this is true but I'm pretty sure @hek will be able to explain.

[Samuel235]

@jeylites - I'm well aware about it crashing and just stopping all of my system from working. I'm just going to see how it functions when its the only solution to turn my lights on to be honest.

The only thing that i can notice on my schematic/board design is that the capacitor on my DTR line is right next to the uC, not close to the FTDI header at all. Would you guys have it close to the uC or the FTDI header? I'm sure I was advised to have it close to the uC.

[m26872]

@samuel235 Just because ISP upload and everything else works, I would still try to rule out hw/assembling issue. What measures have you taken apart from inspection? Do you have more than one board built? Resoldered the uC? Programmed same fuses/bootloader to APM?

Also, I didn't get the CTS thing. Did you just need to disconnect CTS to make it work on APM? Isn't CTS shorted to GND on your APM as well?

[Samuel235]

@m26872

Do you have more than one board built?

This is the second one of this Revision, the first had the same issue, but there was no difference between the two boards, just did this to lower the chances of any soldering problems causing issues.

Resoldered the uC?

I have gone around the uC with the soldering iron 'tinned' to make sure each of the pins are connected to its pads properly without too much solder there, I might go around once more just incase i didn't get enough solder to connect on some of the pins. However, i don't believe this to be an issue, but anything is possible

Programmed same fuses/bootloader to APM?

I have programmed the APM to match this board, and it worked fine, fuses and bootloader included.

Also, I didn't get the CTS thing. Did you just need to disconnect CTS to make it work on APM? Isn't CTS shorted to GND on your APM as well?

Both of the boards have CTS shorted to GND. I didn't explain it correctly, i meant that if i use GND (on the USB adapter) -> GND on board, nothing happens. But if i do CTS (on the USB adapter) -> GND or CTS on board, it works for the APM.

Now i have some progress. I made the fundamental error of not powering the board with the battery while it was connect to FTDI. I can now monitor the serial output and see my debugging messages. However, i still can't upload a sketch. To me this all points down to the DTR circuit. The ISP uses the RESET line rather than DTR, and the ISP is working fine (from what i can tell). Would you agree with me in thinking that the issue is somewhere on the RESET section/line? My initial thought was my fuses, but my E2 DA 06 settings allows boot reset vector so therefor i don't think that my fuses are to blame.

[Samuel235]

Arduino IDE has just uploaded a sketch perfectly fine with no errors to my board, for some reason. Just out of the blue (I did nothing different to what i've been doing the last week). However, i then tried it again and got errors. So just out of curiousity i uploaded the BareMinimum sketch, and got errors. I opened the Serial monitor and got nothing printed. So therefor i know that something has happened to the uC because it was running my switch sketch (through 'upload via programmer'). So i then uploaded my switch sketch and got errors again about the programmer not being in sync:

avrdude: stk500_paged_load(): (a) protocol error, expect=0x10, resp=0x81
avrdude: stk500_cmd(): programmer is out of sync

I then opened the serial monitor, the sketch is uploaded!

Why am i getting errors? From my limited knowledge, my two thoughts are:

• The board is not reseting after the sketch has been uploaded and therefor the programmer is out of sync to the board.
• The programmer is running/uploading too quickly for the uC to know or keep in time with.

[m26872]

@samuel235 said:

Both of the boards have CTS shorted to GND. I didn't explain it correctly, i meant that if i use GND (on the USB adapter) -> GND on board, nothing happens. But if i do CTS (on the USB adapter) -> GND or CTS on board, it works for the APM.

Sorry, I still don't get it. Don't you always connect all 6 pins?

Now i have some progress. I made the fundamental error of not powering the board with the battery while it was connect to FTDI.

Great, but you should not need a battery if you have power from the FTDI-adapter and don't have any big power consumers or shorts on the board. Do you use 5 or 3.3V ? Have you measured the current (e.g. from a battery)?

[Samuel235]

@m26872 - Both of the adapters that i purchased only came with 5 wires in a ribbon cable fashion, and me being mr gullible decided to assume that it only needed the 5. I just assumed that i only need to connect GND OR CTS. I'm now assuming that i need to connect both of them as they don't short together on the adapter itself? I have watched numerous videos on FTDI and ISP to troubleshoot this and I can honestly admit that i didn't realise if any of them had used 6 connections

I did at one point test the current, i can't remember exactly what it was. Give me an hour and I will be able to test that - I'm using 3.3v for the VCC line, my adapter is set to 3.3v too. Does it matter what the current is or would you be checking to just see if there is any current at all? I have tested the voltages when i'm hooked up to the serial connection just to let you know, and they were fine across all of the vcc connections on the board, so there is no connections missing and the uC is definably receiving power

[Samuel235]

So i have just dropped my multimeter over the coin cell and various other positions on the board, it would seem that there isn't much of a current change anywhere across the board. It reads 2.6mA across the board. This shows that there isn't really any current draw across the board and therefor like @m26872 mentioned in the previous post, there is no reason to why it shouldn't work being powered from the serial adapter.

When i have the board connected through the serial adapter without the battery, the current is the same across the board, the reset pin is receiving the 3v to keep it high and i get an error of:

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0xfc

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0xfc

avrdude: arduino_read_sig_bytes(): (a) protocol error, expect=0x10, resp=0xfc
avrdude: error reading signature data for part "ATmega328P", rc=-3
Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.
avrdude: error reading signature data, rc=-1

I don't think there errors are very helpful as they keep changing every time i try to upload it without touching the board. I think its just having general issues with getting a transmit signal. I can still view the serial monitor perfectly fine which to me indicates that i have the Rx and the Tx line correct for a start. Am I correct in assuming this?

What is your general thoughts, would you think it has anything to do with the reset procedure or do you feel there is an issue elsewhere on the board/power?

EDIT: I measured the current incorrectly, changed the figure in this post to reflect the correct measurement.

[Samuel235]

I can also confirm that my RESET pin is high with the same voltage as the coin cell is providing so there is no issue from the start of the process, the only thing I'm wondering is if the DTR pin is pulling the pin low when needed. This process would be much easier to see if i had an oscilloscope.

[Samuel235]

I can now rule out my previous thoughts of the capacitor on the DTR line being too far away from the FTDI connector, i just moved its placement and it doesn't change a thing. Still getting the protocol error.

[m26872]

@samuel235 I looked again at your board and saw that your DTR trace was routed very near Rx. Did your "move" of C7 had it's own wire from serial adapter, i.e. bypassed and unconnected to DTR trace on board?
I also pressume you've double checked value and functionality of C7.

[Samuel235]

@m26872

I completely moved C7 and infact i attached it to the under side of the DTR pin on the FTDI header, then ran a wire to the pad that C7 WAS attached to (the uC side). I made sure it was not shorting on anything else in its vicinity.

I do understand the functionality and the value needed for this cap. The need for this cap is to essensially pull the RESET line low for a split second by discharging the cap and then the vcc line with the pullup resistor charges the cap back to full then pulls the reset pin high. This process then tell the uC to restart itself.

The only thing left for me to try is increasing the size of that cap. I have a 4.7uF cap in my inventory that i will attempt to change out. But i have read that everyone uses a 0.1uF and its very very unlikely that it needs to be higher. My case might just be that 0.1% that does.

[m26872]

@samuel235 If you mean the Ftdi header on the board, then it was still connected to that trace. Try bypass it completely and connect straigth from your serial adapter to cap to resetpin.

[Samuel235]

@m26872 Of course it would, silly me. I have now ammended that and still nothing. I'm about to swap out that cap for a 4.7 to see if that does it. This is how i have it setup to test what you pointed out:

Photographing my board under x25 magnification makes it look very amateurish and dirty