We have been testing Zigbit900 modules for a while and sometime see them losing their settings or code. We don't know exactly what happens but the result is that thay don't transmit data anymore. After re-flashing them via the bootloader, they are working fine again.
The stack used is 1.14.0 with SerialNet
The impression is that the frequent use of the ATZ command to store settings persistantly could cause this.
Anyone seeing similar issues?
Can you confirm if it is settings or code? ATZ does not affect flash.
Writing EEPROM while power voltage is low might corrupt contents of the EEPROM,
It is definitely the code. Serialnet did not respond to any commands any more. Ans it is not the ATZ command, we removed that and set all parameters at startup again.
I don't think that power supply is the issue, we usually run a UMTS modem off it and it's designed for >2A peak current.
Re-flashing via the bootloader did help again.
And I might have some more modules with the same issue ...
Is there any chance that the bootloader gets set-up and starts erasing the flash? I should probably get around the bootloader and load the serialnet image straight into flash (and change fuses)...
There is always chance like this. I'd find a real programmer and read corrupted firmware first.
You mean, to compare it with what should be in?
Yes, just to check what sectors are corrupted and how exactly they are corrupted.
I compared 2 modules which did not connect any more after a while and compared the read-out image with one freshly programmed.
I found a few erased sectors on each, but in different areas:
xFF areas in module 1040:
x2400 to x2500
x2D00 to x2E00
x12D00 to x12E00
xFF areas in module 1046:
xF500 to xF600
I also found an empty area in higher regions (x1BF00 to x1D910) but the look to me but that looks to me like a left-over from some other image I tried at some stage as it is surrounded by other empty sectors.
Any idea what could cause the loss of sectors?
Could that be the bootloader, might it get upset by something at startup? Is it worth trying to put the SerialNet stack/app in via ISP or JTAG without the bootloader?
Thanks, BC
Code can only be erased from the bootloader section, so it is worthwhile to test it without a bootloader. On the other hand, it is weird that it even gets to the bootloader.
So if code without bootloader still gets erased, then it is a hardware issue.
I have some (~8 ) running with the same image but without the bootloader and I don't see those code losses.
The system is running for a week now which is the timeframe where I usually see at least one dropping out.
I agree, it can only be the bootloader that can change/erase the code. The only reason I can imagine why that would happen is that the UART lines are grabbing some signals or noise from the host system. But I am using another Atmega for node systems and an embedded Linux on an AT91SAM for the coordinator system. So, very unlikely that they both do the same "mistake" in a similar way. And I definitely had Zigbits loosing their code on both systems
Will keep you updated if something changes.
I have seen this problem and posted about it here
https://www.avrfreaks.net/index.p...
The bootloader needs modifying so that it doesn't have the means to erase sectors without some outside influence ( say some keys passed by the PC app ).
At the moment if the program counter is corrupted there is a chance that the erase code in the bootloader will be executed.
That would really explain what we see on our systems.
How did you "harden" the bootloader to not accidentally erase application blocks?
