Mega2560 - can't burn FlashForth, burns bootloader fine

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

Been fighting this for a week now ..

 

I have 2 Mega2560s, an R2 and an R3. I have USBASP, 2 AVR Dragons, a Micro with ArduinoISP, and a TL866A. Generally been using the USBASP, and all fail the same way.

So I can install bootloaders on each of the 2560s without issue using any of the programmers. I've successfully installed FlashForth on a Micro (32u4) using any of the programmers.

When I attempt to install FlashForth on the 2560s, no matter which programmer, it fails on the first verify read at 0x0000 (returning FF).

I've tried various incantations, latest avrdude and Arduino avrdude, tried recipe on flashforth site, tried replicating recipe used by Arduino burn bootloader output .. same failure each time.

 

attached file pass.log shows complete programming of bootloader (paths chopped for brevity)

../hardware/tools/avr/bin/avrdude -C../hardware/tools/avr/etc/avrdude.conf -v -patmega2560 -cusbasp -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xD8:m -Ulfuse:w:0xFF:m
../hardware/tools/avr/bin/avrdude -C../hardware/tools/avr/etc/avrdude.conf -v -patmega2560 -cusbasp -Pusb -Uflash:w:../hardware/arduino/avr/bootloaders/stk500v2/stk500boot_v2_mega2560.hex:i -Ulock:w:0x0F:m

 

attached file fail.log uses same sequence of commands to attempt to program flashforth

../hardware/tools/avr/bin/avrdude -C../hardware/tools/avr/etc/avrdude.conf -v -patmega2560 -cusbasp -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xD8:m -Ulfuse:w:0xFF:m
../hardware/tools/avr/bin/avrdude -C../hardware/tools/avr/etc/avrdude.conf -v -patmega2560 -cusbasp -Pusb -D -Uflash:w:hex/2560-16MHz-38400.hex:i -Ulock:w:0x0F:m

 

Hopefully I'm not doing something dumb ..

Attachment(s): 

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

When I attempt to install FlashForth on the 2560s

Have you looked at the list file or even the hex file for it? Does the code start at 0x0000?

 

Or maybe the code is too big and it wraps around? Just wild guesses here.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

It does start at 0000, it's designed to run without the bootloader.

The code is slightly smaller than the bootloader that succeeds.

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

But the bootloader would install up high in the bootloader region not at 0x0000. Can you share the list file just in case somone can pick something up?

an R2 and an R3

Are these Arduino boards?

 

I don't really understand Arduino or Dude stuff very much. blush

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

At a guess, the programmer you're using doesn't properly reset the "extended" part of the address being read/written.

The flashforth .hex files contains two sections - one in low memory (most of the program), and one at the top of memory (in the "bootloader section", and this able to write additional flash memory.)

A bunch of the low-end programmers are only barely away of memory beyond 128k, and handle it by sending a "raw SPI command" to set the high byte of the address.  Which is fine, but then they would also need to send a command when they're done writing to RESET that byte, and that's what I suspect is missing.  So when the programmer reads 00 for the verify, it actually ends up reading 0x10000 (or something like that.)

 

If that's the case, it might be that the flash IS being programmed correctly, and the only reason that the flashforth isn't working is that "safe mode" has reset the fuses at the end.  You might try programming it without the verify, and see how that works.

 

Alternately, there are a couple of ways you could modify/split the hex file that might help.

 

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

Why are you messing with lock bits? And especially, why are you setting lock bits first?

 

I have a feeling the second programming attempt fails because the chip is then locked at that stage. Having said that I have not tried to decode the lock bit value you are setting - perhaps it is benign?

 

For that matter why are you programming fuses every time? Surely fuses is something you do once just after you have changed to using a crystal or something like that? Then you do repeated programming of the HEX with your program being developed. When you are happy that everything is fine for production/distribution (and you don't want prying eyes) you have one further session to set lock bits.

 

PS oh and I forgot to ask - is your intention here to have the bootloader in high memory and the Forth in application memory at the same time? If so you will want to JOIN the two HEX files at the start then have one , single programming session.

Last Edited: Tue. Oct 5, 2021 - 08:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, got off on some different projects for a few days .. turns out it was the bootloader size bits, which needed to be 512 words instead of the default 4K