Mysbootloader, problem after reboting.

[pacovi]

Hi, I'm using mysbootloader with MYScontroller to upload firmware OTA
I've been able to upload several FW's (repeater, temperatures relay, etc.) Everything works fine for several days, but when I switch off the node for some minutes, and then switch on again, the node start requesting firmware in a loop, I'm not able to upload any FW or to reboot the node from MYSController.

These are the messages received in MYSController from the node
[2016-01-18 13:24:01.076 Info] TX 33;0;4;0;1;0C0003002805F8C5
[2016-01-18 13:24:01.076 Info] RX 33;255;4;0;0;0C0003002805F8C50101
[2016-01-18 13:24:13.274 Info] TX 33;0;4;0;1;0C0003002805F8C5
[2016-01-18 13:24:13.274 Info] RX 33;255;4;0;0;0C0003002805F8C50101
[2016-01-18 13:24:38.325 Info] TX 33;0;4;0;1;0C0003002805F8C5
[2016-01-18 13:24:38.325 Info] RX 33;255;4;0;0;0C0003002805F8C50101
I'm using;
MYScontroller 0.1.2.282
Mysensors v 1.5
Arduino mini ATmega 328 5v.

These are the lines added to my boards.txt file:
proMYSBL.name=ATmega328 16Mhz MYSBootloader
proMYSBL.upload.tool=avrdude
proMYSBL.upload.protocol=arduino
proMYSBL.upload.maximum_size=30720
proMYSBL.upload.maximum_data_size=2048
proMYSBL.upload.speed=115200
proMYSBL.bootloader.tool=avrdude
proMYSBL.bootloader.low_fuses=0xF7
proMYSBL.bootloader.high_fuses=0xDA
proMYSBL.bootloader.extended_fuses=0x06
proMYSBL.bootloader.unlock_bits=0x3F
proMYSBL.bootloader.lock_bits=0x0F
proMYSBL.bootloader.file=MySensors/MYSBootloader.hex
proMYSBL.build.mcu=atmega328p
proMYSBL.build.f_cpu=16000000L
proMYSBL.build.board=AVR_UNO
proMYSBL.build.core=arduino
proMYSBL.build.variant=standard

[robosensor]

Subscribing to the topic, seems like I have the same problems with one of my nodes. If I power off and power on again my node after few days of online, node just start flooding gateway with messages like this:

1451044164;1;255;4;0;0;32000B00F004D4A80101
1451044166;1;255;4;0;0;32000B00F004D4A80101
1451044168;1;255;4;0;0;32000B00F004D4A80101

I'm not able upload any FW or reboot node too. Only reflash of bootloader using ISP 6-pin connector helps me.

[pacovi]

I have reset the arduino several times(20 or more), one of them the module started transmiting and now is working again.
I tried with some other modules, switching them off for several minutes, and the problem is the same.

[robosensor]

@pacovi said in Mysbootloader, problem after reboting.:

I've been able to upload several FW's (repeater, temperatures relay, etc.) Everything works fine for several days, but when I switch off the node for some minutes, and then switch on again, the node start requesting firmware in a loop, I'm not able to upload any FW or to reboot the node from MYSController.

Sorry for reply in 'expired' topic. Just found what is happening. One of my nodes (Chinese Arduino Nano board, 5V atmega328p) always starts to flood controller with firmware request messages after few minutes (sometimes hours or days) of uptime.

I used "avrdude.exe" -C"avrdude.conf" -v -patmega328p -cusbasp -Pusb -b19200 -Uflash:r:firmware.hex:i command to download firmware from atmega chip back to my computer and found that every few boots firmware loosing 128-byte blocks of data in random places. Broken blocks are filled with 0xFFs (like erased flash area).
Few examples of memory positions of bad blocks: 0x0180, 0x1500, 0x2C80. I've never seen broken blocks in bootloader code.

I'm using MYSBootloader V1.1 by @tekka

I do not know who is to blame for this, most likely fake Chinese atmega328p chips. Or bootloader/firmware can corrupt flash memory?

[tekka]

@robosensor That's interesting - the bootloader does a FW CRC check at the end of the OTA update process, so at some point the firmware was ok if the sketch started. What do you mean by "every few boots firmware loosing 128-byte blocks of data" - there are always new or different blocks missing? Can you upload/post the .hex files showing what you described?

[robosensor]

@tekka

1. I have uploaded firmware using OTA (MYSController 1.0 build 3314, MYSBootloader 1.1).
2. After this I powered off and powered on several times my node.
3. I downloaded firmware from atmega328p back to my computer into file1.hex
4. After this I powered off and powered on several times my node.
5. I downloaded firmware from atmega328p back to my computer into file2.hex
6. After this I powered off and powered on several times my node.
7. I downloaded firmware from atmega328p back to my computer into file3.hex
8. After this I powered off and powered on several times my node.
9. I downloaded firmware from atmega328p back to my computer into file4.hex
10. After this I powered off and powered on several times my node.
11. I downloaded firmware from atmega328p back to my computer into file5.hex

After this I compared all files. I use TortoiseMerge. I'm aware of format of Intel hex files (length, address, type, data, checksum).

Differences between file1 and file2: 128 bytes of memory (4 lines in hex file, each line 20 bytes (data bytes) long, I mean raw data without headers, address, type and checksum fields) starting at 0x1500 memory position are different. First file contain valid (looks like valid) data, second file contain 128 bytes of 0xFF at the same memory position.

Differences between file2 and file3: 128 bytes of memory starting from 0x0180 memory position. file2 contain valid data, file3 contain 128 bytes of 0xFF.

Files file3 and file4 is the same, no differences at all.

Differences between file4 and file5: 128 bytes of memory starting from 0x2C80 memory position. file4 contain valid data, file5 contain 128 bytes of 0xFF.

So file5 (relative to file1) contain three bad blocks filled with 0xFF, each block is 128 bytes long.

So almost each start new 128-byte bad block appears in random place (in addition to already existing bad blocks).

Bad blocks looks like this:

:20018000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7F
:2001A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5F
:2001C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3F
:2001E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1F

I hope that I explain this issue without uploading files.

[tekka]

@robosensor and you see the same with different HW? Can you also post the log from MYSController - I'm curious to see what happens on that level.

[robosensor]

@tekka haven't yet tried other hardware (but I want to try). I'm using five nodes at this moment with the same arduino nano boards (the same supplier, seems like the same batch). As far as I remember there was another node with the same behavior, but I somehow fixed the problem and I do not remember what I did for this, maybe I just replaced that nano board. So now I have the only node with such behavior.

I have nano boards from another supplier (with usb-micro instead of usb-mini), I can try them. But most likely that I just have fake chips.

Also about power. Node in it's usual place using high-quality MeanWell NFM-10-5 power supply (5V connected directly to Nano pins + capacitor (220 or 330 uF, don't remember). Today I used Korad KA3005D power supply (12V, connected to RAW pin, Nano contains AMS1117-5.0 regulator).

As for logs from MYSController, node starts sending firmware config messages every 2 seconds:

135	12.03.2017 17:36:32	RX	1 - LCD Node	INTERNAL	C_STREAM	NO	ST_FIRMWARE_CONFIG_REQUEST	32000E00B005C92B0101
136	12.03.2017 17:36:34	RX	1 - LCD Node	INTERNAL	C_STREAM	NO	ST_FIRMWARE_CONFIG_REQUEST	32000E00B005C92B0101
137	12.03.2017 17:36:36	RX	1 - LCD Node	INTERNAL	C_STREAM	NO	ST_FIRMWARE_CONFIG_REQUEST	32000E00B005C92B0101
138	12.03.2017 17:36:38	RX	1 - LCD Node	INTERNAL	C_STREAM	NO	ST_FIRMWARE_CONFIG_REQUEST	32000E00B005C92B0101


1393	12.03.2017 18:35:09	RX	4 - AirServo	INTERNAL	C_STREAM	NO	ST_FIRMWARE_CONFIG_REQUEST	46000200B00394200101
1394	12.03.2017 18:35:11	RX	4 - AirServo	INTERNAL	C_STREAM	NO	ST_FIRMWARE_CONFIG_REQUEST	46000200B00394200101
1395	12.03.2017 18:35:13	RX	4 - AirServo	INTERNAL	C_STREAM	NO	ST_FIRMWARE_CONFIG_REQUEST	46000200B00394200101

P.S. After firmware update node changed it's ID from 1 to 4 and I could not change this using MYSController (node ID is defined in source code, I'm using static node IDs). I have tried to change ID and to erase eeprom, without success.

[tekka]

@robosensor well, that sounds like a HW issue - maybe fake chips or chips that didn't pass QC.