9x wont turn on after flashing

[Koarl]

Hello gruvin,

Thanks for your answer. First i wanna say: Don't hurry! It's just a hobby you know. [emoji12]

What you say sounds reasonable, but I already reflashed the programmer. But it's possible that I hit the wrong FW.

[rperkins]

What i can do tonight is attempt to compile the usbasp firmware that is listed on the gruvin source. as i said before there didnt seem to be a hex file for a m8 mcu.

his explanation of why it mismatches at 0x0000 makes sense.

What you could do to verify that the size of the firmware written is in fact causing the problem.
You could try to write a smaller piece of firmware to your gruvin board. It wont work of course but you shouldnt get a mismatch error.

Of course the safest thing to do is to wait for gruvin to have a chance to help out

[KAL]

Here the firmware I flashed to my USBASPs

for using them with my 9Xs with 2561 processor.

Klaus

[Koarl]

Thanks!
I'm outa town for the weekend, but as soon as I'm back I'll give it a try!

[gruvin]

What you say sounds reasonable, but I already reflashed the programmer. But it's possible that I hit the wrong FW.

You hit the wrong firmware for sure. The following is the exact symptom you get with the buggy USBASP fw ...

Code: Select all

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x0c != 0x04
avrdude: verification error; content mismatch

The firmware that @Klaus has just posted (by Romolo) will work, I'm sure. Everything Romolo does Just Works™

And no. Don't worry. Nothing is fried. Well, maybe some little flash memory cells. But that's a good thing.

Gruvin

P.S: FWIW, what is happening is that when the USBASP address counter hits 0x1FFFF -- the 128K boundary -- then on the next increment, which should be to 0x20000, it actually wraps back around to 0x00000. Actually, it's to do with 64K block bank switching. USBASP assumed that 128K was the largest address ever to exist (basically) and so fails to switch up to the next higher bank. Anyway, the result is that the first block of 64K Flash gets overwritten with data intended for addresses above 128K. This in turn causes the verification error at the very first byte 0x00000.

That had me pulling my hair out on the gProg project. It read to me as if even the very first byte didn't write correctly. Indeed, when one checks with another programmer, that first byte is some seemingly random value -- though actually of course, it is the byte intended for address 0x20000.

It took me over a week to figure out what the heck was going on. That final realisation was one of those, "D'oh! Of course! Geeze!" moments. hehe

[Koarl]

Hello gruvin,

Thanks for your answer, gives me confidence. But I just have to learn some hard stuff (private law) at the moment and what you wrote made the knot in my brain even bigger. Only hard booze can solve this. [emoji12][emoji482][emoji483][emoji484][emoji485]

[gruvin]

[Koarl]

The problem stays the same.

/usr/local/bin/avrdude -c usbasp -p m2560 -U flash:r:/var/folders/l0/vd5nvhv53wnfjxqr7kbshmy40000gn/T/13564-flash-check.bin:r
=================================================================================

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9801
avrdude: reading flash memory:

Reading | ################################################## | 100% 53.13s

avrdude: writing output file "/var/folders/l0/vd5nvhv53wnfjxqr7kbshmy40000gn/T/13564-flash-check.bin"

avrdude done. Thank you.


=================================================================================
/usr/local/bin/avrdude -c usbasp -p m2560 -U flash:w:/Users/carloskammerlander/Desktop/opentx-gruvin9x-templates-nocurves-PXX-ppmca-gvars-potscroll-autosource-autoswitch-dblkeys-battgraph-pgbar-de-2.1.511111.hex:i
=================================================================================

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9801
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "/Users/carloskammerlander/Desktop/opentx-gruvin9x-templates-nocurves-PXX-ppmca-gvars-potscroll-autosource-autoswitch-dblkeys-battgraph-pgbar-de-2.1.511111.hex"
avrdude: writing flash (74442 bytes):

Writing | ################################################## | 100% 23.79s

avrdude: 74442 bytes of flash written
avrdude: verifying flash memory against /Users/carloskammerlander/Desktop/opentx-gruvin9x-templates-nocurves-PXX-ppmca-gvars-potscroll-autosource-autoswitch-dblkeys-battgraph-pgbar-de-2.1.511111.hex:
avrdude: load data flash data from input file /Users/carloskammerlander/Desktop/opentx-gruvin9x-templates-nocurves-PXX-ppmca-gvars-potscroll-autosource-autoswitch-dblkeys-battgraph-pgbar-de-2.1.511111.hex:
avrdude: input file /Users/carloskammerlander/Desktop/opentx-gruvin9x-templates-nocurves-PXX-ppmca-gvars-potscroll-autosource-autoswitch-dblkeys-battgraph-pgbar-de-2.1.511111.hex contains 74442 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 14.98s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x0c != 0x08
avrdude: verification error; content mismatch

avrdude done. Thank you.


=================================================================================

[rperkins]

maybe until gruvin responds you could post the avrdude output that you get when you try to update the one usbasp with the other one, using the romolo firmware posted in this thread. Maybe this will pinpoint whether you are actually updating the firmware on the usbasp

[MikeB]

Only 74442 bytes are being flashed, so you are NOT crossing a 128K boundary, only a 64K one. I believe some versions of AVRDUDE get this wrong, rather than the USBASP. What version of AVRDUDE are you using?

Mike.

[rperkins]

earlier he posted this which shows 5.11.1 on a mac

viewtopic.php?f=95&t=7804#p104307

[Koarl]

Exactly!
I' m gonna post the avrdude output tomorrow.

[MikeB]

You could try reading the flash from the '2560 as it now is, and post that .hex file and the one you are flashing. We could then have a look and check what is being flashed.

You might zip both files to save space on the forum server.

Mike.

[gruvin]

Yes. Good idea. Please post a copy of both the hex file you are writing and a Flash read (hex) directly after that.

[gruvin]

Some random notes ...

I did some checking. It's not the 128K boundary. It was all 64K boundaries. So apparently, the original USBASP firmware will not work with any code that crosses the 64K boundary.

I have attached firmware for the ATmega48P and the '88P versions of my gProg (USBASP) firmware. I made one change to the gProg hardware, to control a buffer chip, which allows the gProg to remain always connected, without interfering with the shared I/O pins on the '2560 -- especially /RESET. The extra I/O pin I used should just be not connected to anything on your board.

I *know* this one works, as I use it personally. Famous last words!

@Koarl -- your USBASP most likely has the ATmega48 chip, like the original. But it might pay to check. Got a magnifying glass?

Here's the Flash command I use for the '48 ...

Code: Select all

avrdude -c usbasp -P usb -p atmega48 -U flash:w:fw-v120-48.hex

... and the same for the '88P version ...

Code: Select all

avrdude -c usbasp -P usb -p atmega88p -U flash:w:fw-v120-88.hex

- - - -

@Koarl -- Do still send us the intended and actual flash data files. I'd really like to confirm that the byte intended for 0x10000 ended up writing to 0x00000, as previously described, except for the boundary address being 64K, not 128K.


Gruvin

EDIT: Removed -F from the atmega48 AVRDUE command example. At the time I used that, AVRDUDE did not support Atmega48P's signature. Only the plain '48. In fact, I think that may still be the case.

[rperkins]

[quote="gruvin"]
@Koarl -- your USBASP most likely has the ATmega48 chip, like the original. But it might pay to check. Got a magnifying glass?

[/code]

I'm pretty sure it comes with an m8 . He can just attempt to read the flash or even and it will print out the actual signature which then can be searched with google to verify the MCU it has.

Update - just reread this post. Uugh. Cellphone post and in a hurry. hope it made a little sense

[Koarl]

Hey guys,

I tried the firmwares gruvin has posted. Both with epee and the command recommended. No difference, the problem stays the same.

I have now read the firmware on the usbasp, you find it in the attachment named as usbasp- read. You will also find the firmware of the transmitter.

And I tried to read which processor my programmer has. I used a pocket microscope, it must be an Atmega 8A

Thanks!

Edit:

This is the what terminal tells me when I type in one of the commands gruvin postet.


Last login: Mon Nov 9 18:34:37 on ttys001
localhost:~ carloskammerlander$ avrdude -c usbasp -P usb -p atmega88p -U flash:w:fw-v120-88.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9307
avrdude: Expected signature for ATMEGA88P is 1E 93 0F
Double check chip, or use -F to override this check.

avrdude done. Thank you.

localhost:~ carloskammerlander$

[rperkins]

You did not successfully update the firmware on the usbasp. Your usbasp does not have an m88 mcu. Most assuredly it has an m8. The firmware gruvin posted will not work with an m8. The romulo firmware posted earlier should work but you will need to update the command line syntax. Replace 'atmega88p' with 'm8'.

you did a good job posting the output of avrdude. That is what we need to see. Keep posting it with your attempts.

[KAL]

For those who struggle with the command line parameters of avrdude
there exists a splendid GUI for WIN and also Linux and OS X: avrdudess.

Klaus

[Koarl]

I tried what you said. Flashed Romolos firmware again. Using the command you posted and once again with epee like in the tutorial. It stays the same. Throwing all this c**p out of the window is really tempting now.

[rperkins]

You didnt post your output. Dont give up you are almost there.

[Koarl]

You mean what console tells me when I hit the command.

[rperkins]

Yes. Like you did earlier when it mentioned the signature.

[Koarl]

This is the output of console:


localhost:~ carloskammerlander$ avrdude -c usbasp -P usb -p m8 -U flash:w:firmware.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9307
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "firmware.hex"
avrdude: error opening firmware.hex: No such file or directory
avrdude: input file firmware.hex auto detected as invalid format
avrdude: can't open input file firmware.hex: No such file or directory
avrdude: read from file 'firmware.hex' failed

avrdude: safemode: Fuses OK

avrdude done. Thank you.

localhost:~ carloskammerlander$


I tried to flash with epee cause it seems I got something wrong with console but epee won´t let me copy the output. When the window appears that avrdude finished correctly I hit ok and then the output disappears

[rperkins]

yes that is the output we need.

this particular time the output says the the file firmware.hex is not in the directory you called the command from. this appears to be the 'carloskammerlander' directory. verify that the file firmware.hex is in the directory you are calling the avrdude command from.

I also note that the firmware.hex file is provided in this thread within a .zip file. you will need to extract the firmware.hex file from the .zip file you downloaded from this thread.

I am reasonably sure you have never updated your usbasp properly yet. Based on the information from gruvin and Kilrah, that is the root of you updating problems

[Koarl]

Ah got that! And something changed now!
When I try to flash the radio with companion I get this warning:


Your radio uses a Atmega 2560 CPU!!!

Please select an appropriate firmware type to program it.
ie: OpenTX for Gruvin9X board
You are currently using:
Gruvin9x board / 9X

But in the radio profile settings I set the radio type to gruvin9x board/ 9x. I let companion download the firmware and flashed it.

[Koarl]

This was the avrdude output when I reflashed the programmer by the way:


localhost:~ carloskammerlander$ avrdude -c usbasp -P usb -p atmega48 -F -U flash:w:firmware.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9307
avrdude: Expected signature for ATMEGA48 is 1E 92 05
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "firmware.hex"
avrdude: input file firmware.hex auto detected as Intel Hex
avrdude: writing flash (3966 bytes):

Writing | ################################################## | 100% 2.22s



avrdude: 3966 bytes of flash written
avrdude: verifying flash memory against firmware.hex:
avrdude: load data flash data from input file firmware.hex:
avrdude: input file firmware.hex auto detected as Intel Hex
avrdude: input file firmware.hex contains 3966 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.97s



avrdude: verifying ...
avrdude: 3966 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

localhost:~ carloskammerlander$


At the flashing attempt I mentioned before I forgot to delete the extra argument (-p m8) I used when I tried to flash the programmer via companion.

Edit: I have added the firmware I read from the usbasp after flashing.

[rperkins]

Never use the -F option to avrdude.

localhost:~ carloskammerlander$ avrdude -c usbasp -P usb -p atmega48 -F -U flash:w:firmware.hex

This is how you brick your radio. luckily you are only messing with a programmer. I know it was mentioned early on not to use the F option. BAD BOY. Very bad habit to start. I dont even want to hear that it worked for you.

If you are lucky you will be able to reflash the usbasp with this command line

Code: Select all

 avrdude -c usbasp -P usb -p m8 -U flash:w:firmware.hex

please reflash as mentioned above post the output of this command

[rperkins]

viewtopic.php?f=95&t=7804#p104279
yes right here under Dont Panic it says not to use -F option
It probably should have been mentioned in a more pronounced way.

[MikeB]

On eepe, there is an option under the BURN menu or "Review Output". This lets you look at and copy the Avrdude output.

Mike.