For the past few days my log is not working anymore. When I try to pull the log it will shown the bellow:

ArduCopter V2.5.5] logs logs enabled:  ATTITUDE_MED GPS PM CTUN NTUN CMD

96 logs

Log -1791,    start 1,   end 1

Log -1790,    start 1,   end 1



ys negative, and there is no informations.

My hardware is APM2. I tried erase logs, erase eeprom, reset factory default, upload new firmware, upload fw using arduino. Tried latest code from GIT with new dataflash erase method, pul the dataflash and put it back.

My hexa flew well, it just I need the log to help me with analyze my copter.

Any idea what else I should do?





Views: 779

Reply to This

Replies to This Discussion

Hi Yovi

I noticed the erattum last week and we implemented the correction on Tuesday.  I had to get a couple of the dev team members to test the fix yesterday as I actually have yet to find a dataflash that fails the chip erase but I did know that 2 of the devs did have them.  They verified the fix works on known bad devices.

The erase function will now execute the chip erase and test to see if it worked.  If it worked great, all is good.  If not it will revert to the block erase.

The fix is in the master branch 


for you to download and compile.


I tested this on my board and it did not detect the problem (I stuck a Serial.printf inside the check to make sure).  Going back to the old way of erasing (page at a time) did fix my issue though.  It seems like my board fails in a slightly different way.  Is there any more info I can provide to help get a more robust fix?  Is there an issue tracking this somewhere?

Alternatively, a simple command line option to do the slow erase would be good enough for me.


Just so I understand

Using the patch at


Are you saying the check that the check erase failed? i.e. it gave a false positive that the chip erase worked?

Did you force the block erase?

According to the datasheet that is the recommended solution.


Using the patch at


I used the code from the master branch.

Are you saying the check that the check erase failed? i.e. it gave a false positive that the chip erase worked?


Did you force the block erase?

Yes, I just commented out line 204 of DataFlash.cpp: if (format == DF_LOGGING_FORMAT_INVALID) {)

After I ran that erase, my logs started working normally again.  

After some more testing, it seems that ChipErase is working OK for me now.  Previously (on the 2.6 firmware) I was getting a problem where I could only dump the first log successfully, it would always tell me I had 3 logs, one of length 455 and two of length 1, though the "Number of logs" would increment continuously.  When I did an "erase" it would not list any logs but the number of logs did not change.

Now, with your updated code, once I forced a block erase once, everything seems to be working ok, even using ChipErase.

I will go back to 2.6 and do a couple more tests to see if I can reproduce it.  Maybe it was just a fluke.

Ok, thanks for checking. Let me know what else you find out

Bob, I just pushed a change to master that forces the block erase command to be executed.

Ok. I put 2.6 back on and still haven't been able to reproduce my original problem. Maybe a new, uninitialized chip needs to have a block erase done at least once?

Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service