In wall light switch node - Custom PCB

[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.