What do you use for burn bootloader on 3v boards?

[tekka]

@sergio-rius By default CE=9, CSN=10

[Sergio Rius]

@tekka But it's mandatory, like this for the FOTA to work?

Well, obviously yes, if it's incorporated to the code. So I suppose that I would have to compile my own version.
It's there any description for the fuses being different than the stock ones?

[tekka]

@sergio-rius see the correct fuse settings in the included boards.txt file

[Sergio Rius]

@tekka
My pin settings for the radio are:

#define MY_RF24_CE_PIN 4 //<-- NOTE!!! changed, the default is 9
#define MY_RF24_CS_PIN 10 // default is 10

What should I change in BL code for making it to work?

Fuses yes, I also have them wrong. I read them from a brand new board and they are

  Low Fuse      0xFF
  High Fuse     0xDA
  Extended Fuse 0×05
  LB            0x3F

And mines are:

  Low Fuse      0xE2
  High Fuse     0xD2
  Extended Fuse 0×06
  LB            0x0F

What I'm trying to learn is whay mysbl ones are also different from the stock ones.

[tekka]

@sergio-rius Is there a particular reason why you are using pin 4 for CE - if you can change it back to CE=9 w/o much effort I'd go for that before trying to recompile mysbootloader. The fuses also define the bootloader section size: If the stock bootloader is optiboot the BL section size will be 512 bytes - mysbootloader uses 2048 bytes, hence different fuse settings. More on AVR fuses here: http://www.engbedded.com/fusecalc/

[Sergio Rius]

@tekka I'm using the RGBW Controller by LastSamurai, and it rearranges the pins. So I can't change anything there.
Yes, I'm already on that page comparing the two settings and the size was the only one thing left to discover. Thank you.

I suppose I'll have to drop mysbootloader for all those nodes :sob:

[tekka]

@sergio-rius Today is (if it works) your lucky day ;)

MYSBootloader_1_3_0rc1_8Mhz_CE4_CSN10.hex

[Sergio Rius]

@tekka WOOOOOOWWWW! THANNKYUUU!!!! :ok_hand:

[Sergio Rius]

Just a flash question, I suppose I must clone the 8Mhz RC settings for fuses... but even being a pro mini board with an external xtal?

[tekka]

@sergio-rius Yes, if I find time I'll compile a 16Mhz version

[Sergio Rius]

@tekka I have some news.
After burning this version, the board doesn't accept loading a sketch through FTDI.

Sketch uses 7666 bytes (24%) of program storage space. Maximum is 30720 bytes.
Global variables use 348 bytes (16%) of dynamic memory, leaving 1700 bytes for local variables. Maximum is 2048 bytes.
C:\Users\sergio\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino9/bin/avrdude -CC:\Users\sergio\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino9/etc/avrdude.conf -v -patmega328p -carduino -PCOM8 -b57600 -D -Uflash:w:C:\Users\sergio\AppData\Local\Temp\arduino_build_767496/DimmableLEDActuator.ino.hex:i 

avrdude: Version 6.3, compiled on Jan 17 2017 at 12:00:53
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\sergio\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino9/etc/avrdude.conf"

         Using Port                    : COM8
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0xaf
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xaf

avrdude done.  Thank you.

Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.

But it shows a new "Booting" node in MYSController and seems FW can be uploaded, but at an absord slow speed.

May this speed be a problem of mine with the rPI gateway. The part of the service that handles radio hangs in periodically and I have to SSH into the rPi and restart the service. During this, MYSC talks with the service but nothing is sent or received.

10 minutes already passed and it's still writing the 30B sketch.

[Sergio Rius]

Playing with another node I realized that burning bl+sketch through avrdude gives a node with MYSBL that boots asking for sketch but immediately goes on with the sketch. So far is a good solution. :+1:

The firsts still uploading the 30B sketch :flushed:
Are you sure that it's normal?

Edit: It has been uploading (i think several times) for the last 50mins and now is stuck in "Booting: 50.1 (BL1.3)"

[Sergio Rius]

About the issue of my gateway I talked before. I found that the problem must be induced by domoticz.
As I was tired of reseting the GW during those tests (and not being able to open my door garaje), I built a new esp gateway. I ran a 2.4Ghz scanner that covers all the channels and decided for a clean 100+ channel.
The gateway passed the tests and I connected it to domoticz.
I re-configured two nodes for working with it, but they weren't registering. I then realized that my rPi gw was in it's "halt" status... but also the wifi one.
So I've restarted Domoticz and bingo, the nodes started registering on the wifi gw.
Seems that my Domoticz installation may be sending something that makes gw freeze. I thought that could be my mains consumption counter as it was a big number, but I resetted to zero two days ago for this sake.
If devels want to make me dump logs or anything I'll be putting my installation on quarantine.

It's halted again. When that occurs this is the only registered on MYSC:

[gohan]

How did you build the gateway? What are the arduino boards versions are you using?

[Sergio Rius]

@gohan What do you mean? The rPi or the Esp?
For the rPi I first used a NRF24 pa lna getting power from the 5v line with a voltage regulator (ams1117 based)
Then I thought could be problems with this radio or supply and ditched it for a normal NRF24. With identical behavior. Sometimes works for a week or a couple of them or I have to restart the whole Pi several times a day only for being able to go out of home.
When I first implemented the rPiGw worked for weeks. Then the problem appeared. then vanished and was working for months until some point that became worse.
I even thought that my wifi hotspot could be dying and changed it for a unify-pro (nice gadget)
I live in a house far from others, so wifi interference seems not an issue.

I run the Pi from a readonly sd for boot partition and then uses an usb drive for the system+controller. logs on tmpfs.

I was fastly implementing it in my home, but as this problems arose, I only have the power monitor node, the garaje door node and a doorbell that is offline because suspiciously started to eat batteries two months ago.

I'm in Domoticz beta.

For the esp gw it's just a nodemcu board on a breadboard paired to a normal nrf24.

Edit: Ups! mysensors versions are all 2.2.0. The arduinos are all 3v3 8mhz boards and one 5v (power)