Posts made by fac13

@sindrome73 You say you don't think the problem is with MYSbootloader, and you think the problem is with the .HEX files that write the new Bootloader.

Those .HEX files are MYSbootloader. Channel 76 is hard-coded in them.

You can’t get round this by changing anything in your controller.

If you want to create and load MYSbootloader .HEX files for a different channel then you need to modify the configuration files you mention, then compile new .HEX files.

That is not a simple task, it involves multiple steps including the installation of various tools.

My advice would be to get FOTA working using the default channel 76 before trying anything else.

The use of channel 76 for OTA updates is hard-coded in MYSBootloader. You can’t get round this by changing anything in your controller.

You can either take the easy route and change your MySensors network back to that channel, or you can learn how to compile MYSBootloader from source, which would allow you to create and burn version for your chosen channel.

There are pointers in these forums to how to set about doing that. It’s not particularly hard but how long it would take you and whether you’ll find it worthwhile depends on your current level of knowledge.

fac13 about 2 hours ago

I realized I should have added a wait after the initialization, like this: -

void preHwInit()
{
MY_DEBUGDEVICE.begin(115200);
while(!MY_DEBUGDEVICE){};
}

With that included, my sketch works without needing the architecture code mod.

Putting the same code in before() doesn't work.

Thanks for your help.

@mfalkvidd I tried both and neither worked - the node still failed to start.

My workaround is to add MY_DEBUGDEVICE initialization in hwInit() in MyHwSAMD.cpp , immediately after the initialization of MY_SERIALDEVICE,

i.e. insert these lines after line #76: -

MY_DEBUGDEVICE.begin(MY_BAUD_RATE);
#if defined(MY_GATEWAY_SERIAL)
while (!MY_DEBUGDEVICE) {}
#endif

Of course if the two devices are the same then MY_SERIALDEVICE gets initialized twice, but doesn't seem to cause a problem.

I've been testing a Genuino Zero as a serial gateway. Everything works fine except for the redirection of debug output to the Programming port.

I saw a thread and a pull request which added MY_DEBUGDEVICE to the architecture files, but if I #define MY_DEBUGDEVICE SERIAL my gateway crashes, silently.

I believe this is because there is no 'begin' for MY_DEBUGDEVICE.

When I add one to to relevant architecture file it works fine, with debug output sent as expected to the Programming port.

I'm a bit puzzled how anybody has got this to work without that mod, have I missed something?

Note that adding MY_DEBUGDEVICE.begin into Setup in the sketch is too late - the node crashes before it gets to that point.

I had the problem you describe, an ip address which was not the one it should be, usually a different one after each reset, sometimes with parts of the address recognisable as parts of the one I was expecting.

I too tried a different W5100 module, different arduino, different connecting wires. No better.

Then I found the answer, which was to supply the W5100 with 3.3v rather than the 5v I had been using. This fixed the problem completely.

It is very odd that supplying the module with 5v stops it working properly, I can't explain it. It has an onboard AMS117 to convert the supply voltage to the 3.3v the chip needs.

Whatever the reason though, it does fix the problem. I have two W5100 modules and neither will work properly if supplied with 5v. Both work perfectly on 3.3v.

I see the instructions for the Mysensors ethernet gateway show the module supplied with 3.3v so I guess when I thought I knew better I was wrong!

Hope this helps.