Inconsistent results (aka failures) burning Repetier 92.9 firmware

YP3002T

Hi. I'm in the process of attempting to replace the manufacturer provided Repetier .91 (on a P802M type printer) with 92.9. I'm seeing inconsistent results (to say the least).

First, I used avrdude to read out the current firmware as a hex file protection copy. No problems there. 

I obtained a Configuration.h that is purported to be correct for this unit and board (and appears correct on inspection) -- ran it through the Repetier Configurator, downloaded the result, compiled with latest Arduino and exported hex OK (both with and without bootloader versions).

I used avrdude to try write the new version (without bootloader). It appeared successful -- wrote and verified without errors. However, it doesn't boot -- the display just shows the two blank lines on the four line display that is typical at the start of the booting procedure.

I then tried to write back the original downloaded firmware (.91). The write went OK, but avrdude exited before verifying. However, the firmware appears intact and the unit is booting and (in quick tests) seems functional -- with the original .91 firmware again.

I tried uploading the new version once again, but this is when things got stranger. Avrdude goes through its write cycle, the verify cycle, and then complains of a verify error. This is now consistent, and I stopped for now.

So at this time, I'm apparently back with the original .91 firmware and momentarily stuck.

I've seen some discussions suggesting a bootloader issue relating to .92 and I do have the new 92.9 hex file with the bootloader -- but I'm reluctant to burn that one without really understanding what's going on since I don't want to brick the unit completely.

Any suggestions appreciated. Thanks very much!

 

YP3002T

More info on this. I can (apparently) successfully upload AND get a good verification on the original firmware dump that I downloaded from the printer originally. However, when I try to upload the newer firmware (about 20K smaller, which is a bit suspicious but we'll let that pass for now) it always gets a verify error on 0x0002.

In some instances, I've had to power cycle printer to get the upload phase to work, that is, before pressing reset on the board and starting avrdude.

So to review, the original firmware (.91) uploads and verify succeeds. The new firmware (.92.9) uploads and the verify fails.

Thanks.

YP3002T

One possibility: It's not really erasing or uploading at all. In fact, I have evidence that it actually hasn't erased (though signature checks are good, and the fuses read back as good). But if no erase or flash is really taking place, then that would explain why when I "uploaded" the original firmware back the verify succeeds -- because it's been there all along! Attempts to upload the new firmware verify against the original firmware still in there, and so the verify fails. Feasible? But this doesn't really point at a solution yet.

Repetier

First thing you said you uploaded to config tool. So does that mean your original file was created with config tool as well? Otherwise settings would not get set correctly.

One problem of the bootloader I know is that !!! , yes 3 ! in the binary cause every upload to fail. For that we do not have this in our text but it already happened that a function was at the address !! and the call also caused ! some how. Doe snot happen often but does happen. Enabling some features or adding a language would change positions and fix that.

Apart from this I always compile and upload without bootloader (old is ok, so why change that).

YP3002T

Hi. Yeah, everything is based off a config tool created Configuration.h, so the settings all load properly. I'll check for !!!, though it does seem like a low probability trigger. Thanks!

YP3002T

For the record, I got hold of a USBASP board and am now getting 100% flash successes.

YP3002T

I probably should add one oddity. Every time I update the firmware, the current EEPROM settings are lost and the current Configuration.h settings are applied. I had thought that changing the EEPROM mode prevented this, but it still keeps happening. Since I back up the current EEPROM before a firmware install this isn't a big deal -- I just reload from that save after the new firmware is in, but I'd like to better understand what's happening. Thanks.

Repetier

Good question. Firmware only rewrites if eeprom mode differs or checksum mismatches. If you use isp at least it atmel studio you have the option to also clear eeprom, so maybe that is enabled when you upload?

YP3002T

I think I nabbed it. For my m1284p the hfuse needed to be changed from 0xDE to 0xD6 for retaining of EEPROM. I'll verify that this worked after the next firmware upload. Thanks!

YP3002T

Confirmed. That did the trick.

YP3002T

Just to clarify, in my original comment above about changing the EEPROM mode, I should have said that NOT changing the EEPROM mode is supposed to prevent writing the Configuration.h settings over the EEPROM. Typo on my part. In fact, what was happening to me was that despite my not changing the EEPROM mode, Configuration.h settings kept being written into the EEPROM each time the firmware was flashed, due to the original hfuse settings of my m1284p chip as described above, which were erasing the EEPROM as part of the firmware flash process.