Zigbit modules losing their settings/code under SerialNet

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

Last Edited: Fri. Oct 16, 2015 - 02:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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,

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is always chance like this. I'd find a real programmer and read corrupted firmware first.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You mean, to compare it with what should be in?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, just to check what sectors are corrupted and how exactly they are corrupted.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That would really explain what we see on our systems.

How did you "harden" the bootloader to not accidentally erase application blocks?