-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optiboot for AVR-DD #354
Comments
I tried the bootloader and it does not work either. Then I tried the option without bootloader and now the board seems to be bricked. I will see how I can revive the board using PICKit 4 (HV UPDI). It is my fault though as I did not notice that both the two options for reset requires HV UPDI programmer. Looks like a bug though to me.
|
I found one bit of buried treasure.... I was testing for RAMPZ to decide whether to build with the support for the extended address, and whether to use lpm or elpm to access flash. the 64k DA/DB parts define RAMPZ The 64k DD's do not. This is wholly responsible for the difference in size between the 64k and 32k versions of optiboot. setting it to write the data by word makes virtually no difference. |
This may or may not have something to do with the observed failures. |
You guys are doing better than I am. I can't even get it enable the UART at all. And another optiboot bug just came in where any write in the last page of the first half of memory on a 128k part triggers a verification error. |
I have this working correctly now. We are down to... THREE INSTRUCTION WORDS OF FLASH for some 128k parts. I've identified 6-9 words that could be eliminated if the compiler could be perform certain operations correctly, but the inline ASM to force that would be super nasty. Might be possible with a union. When it takes the 2 byte length it does 3 wordsof extra gymnastics to get it into the high half of pointer register.. Like it copies the value to the low byte, loads 0 to the high byte, copies the low byte to the high byte and eors the low byte with itself, before getting the second byte, and when it arrives, simply copying it to the low byte. We could have instead copied the high byte to the high register, then gotten the second character, and copies it to the low byte. That's rcall, mov, rcall, mov. Instead of rcall, mov, ldi, mov, eor, rcall,mov I currently have it turning on pullup on RX line, because I was seeing strange behavior without that, but I'm not certain it's required. Would save 3 words if it could be dropped./ The last broken part was a misspelling in a preprocessor conditional and poor compile warning settings that caused me to not realize I was testing an undefined (hence 0) variable. But this never made it into the field unless using github versions. I think misuse of SPM Z+ may have been a factor, along with believing the headers when it said it had a RAMPZ on 64 k DA/DB. |
fixed by |
Great! I'll give it a try just to confirm that it will work properly with the soon-to-be-released Avrdude 7.1 |
This seems to work. I am using 1.5.1 beta and avrdude-7.0arduino.4-rc1 from here. I patched programmer.txt as well to use
|
Testing: blink sketch (LED is PF5 or Pin 25)
|
Using git main version of avrdude. I need to unplug and plug to get the board into bootloader mode.
|
It's probably better to create a separate issue, so we can keep the discussion on point.
When helping out with the Avrdude project I found out that the existing, pre-compiled bootloaders bundled to DxCore didn't work properly with the new AVR-DD series. I'm able to establish a connection with the target, but I can't read and write to EEPROM or flash. The bootloader I'm using is
optiboot_dx64_ser0_alt_8sec.hex
The errors you're seeing below are outputted from the development version of Avrdude, but I'm getting the same result when using Avrdude 6.3.
Have you @SpenceKonde tried to get Optiboot to work on the AVR-DD series?
The pre-compiled bootloader hex file I'm using is generated by a command line tool called
srec_cat
, and is not a "real" program, but is only used as a test to see if the bootloader is actually able to do its job. It's a file containing 32256 0xAA's, starting from address 512.srec_cat -generate 0x200 0x8000 -repeat_data 0xaa -o 0xaa_32256b.hex -Intel
Here are the fuse settings:
I can establish communication with the bootloader:
But I can't write anything to memory.
EEPROM:
Flash:
The text was updated successfully, but these errors were encountered: