wrong boot loader parameter?

[qrti]

the optiboot makefile configures the high fuse

# 1024 byte boot
atmega1284_isp: HFUSE = DE

according to ATMega 1284 manuals chapter 26.8.17 this would result in

0xDE = 
1 1 0 1 1 1 1 0             -> 512 byte, start at 0xFE00
          | | |
          | | BOOTRST
          | BOOTSZ0
          BOOTSZ1

after my understanding, this would be correct

0xDC = 
1 1 0 1 1 1 0 0             -> 1024 byte, start at 0xFC00
          | | |
          | | BOOTRST
          | BOOTSZ0
          BOOTSZ1

[JChristensen]

Optiboot is actually 512 bytes (look at the .hex files) so I think the issue is with the comment. Else I think there would have been problem reports before now. Are you experiencing an actual problem?

[qrti]

ok the boot loader <512 byte in size but there is an other discrepancy, when I look in the boot code, hex or make file, they all start at 0xFC00 which also hints to a 1024 byte configuration, how can the controller boot at 0xFE00?

my original problem was that I'm using a normal programmer and tried to figure out correct fuse settings, it works with my 0xDC setting, but I will the try the 0xDE setting as well now

[JChristensen]

OK well I'd be interested to hear if there is an actual issue. I've used the AVRISP mkII and the USBasp successfully, along with AVRDUDE. You say a "normal" programmer, what exactly would that be?

[qrti]

Maybe I should have said a 'universal' programmer, this means I have to set the fuses on my own.

I tried out both fuse settings and they work, so there is no real issue here.

But I was curious and did some research.

Playing with
rjmp PC ;= opcode FF CF
at address 0xFC00 and 0xFE00

- fuse setting 0xDE starts execution as expected at 0xFE00
- if memory is deleted here the controller worms it's way through the 0xFFs (undefined opcode)
- when it reaches the end of program memory, I don't really know what happens there
- somehow it 'finds' the bootloader that resides beginning at 0xFC00

- fuse setting 0xDC starts execution as expected at 0xFC00
- this is were the bootloader resides

[JChristensen]

Well that's pretty interesting. I wonder whether it's working as designed. This repo is several years old. I don't know when or if I might get around to updating it. You might also check out the Optiboot repo to see what the current situation is. If you come to any conclusions, please let me know!

[qrti]

I have to apologize to stir up confusion, your settings are totally correct.
I simply was mislead by my programmer showing byte addresses while the documentation always speaks of word addresses. Now I'm the one who worms through the code ;) ...

[JChristensen]

Oh! Those guys are tricky, word addresses! Hey no worries :-)

[per1234]

Hi @JChristensen. Since you're involved in this project again, I'd really appreciate if you'd take a second to merge #29. This will be useful to other projects, since it will provide a properly licensed source for the Sleeping Beauty variant code.

[JChristensen]

To be clear, I am (perhaps unfortunately) not involved again with this project nor with any number of older projects. Appearances to the contrary may be attributed to whims and random bits of available time so there should be no expectations as to responses. This project could stand a refresh but there is no guarantee when or even if that might happen. If it does, I may just start with a clean sheet.

[per1234]

Thanks so much for taking the time to merge that! I completely understand if you don't have time for this project. mighty-1284p was great in its time before it was abandoned and I am proud to have made some small contributions to this project. Luckily, someone else has taken up the reins on providing ATmega1284P support and created something far bigger and better than mighty-1284p ever could have been:
https://github.com/MCUdude/MightyCore
I don't see any reason for making any further efforts on this project, though it's good to leave it online for historical purposes. If anyone wants to work on ATmega1284P support for Arduino, it will probably be most efficient to just get involved with the excellent MightyCore project.

[JChristensen]

@per1234, that's a good looking core, I was not aware of it. Thanks for the link!