-
Hi, I develop a custom bootloader for AVR64DD32. Application code stored in a 64K serial EEPROM. At power-up bootloader checks EEPROM and, if it has a valid code, bootloader copied it into APPCODE area and then passes control to it. So far I2C EEPROM connected to PD3, PD4. Bootloader uses bit-banging to access it. My bootloader fits into 1K. I tested it with a simple application developed in MPLAB-X. A programmer based on Arduino UNO used to pass application hex code into EEPROM. So far it works OK. Next I'd like to be able to write Arduino applications and download it via my bootloader. DxCore is just a treasure. But it compiles for a smaller bootloader OptiBoot. Somehow I have to add a new option into DxCore, In my installation of DxCore 1.5.6 I modified boards.txt located in folder C:\Users\User\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.5.6\ I took section avrdd as a sample and added a similar section named hbnode. Unfortunately I could not figure out where is the size of bootloader deifined. To force compiler to generate application code starting from address 0x400 I used the following line hbnode.build.text_section_start=.text=0x0400 The resulting hex file has code started at 0x400. However, when I loaded compiled application code via my bootloader, it does not work. Apparently I did something wrong. Could you please help me? How to define bootloader size properly? Regards |
Beta Was this translation helpful? Give feedback.
Replies: 7 comments 12 replies
-
Hm, perhaps I expected too much from DxCore. While trying to figure out what I did wrong, I compiled a "Blink" sample for two DxCore targets - AVR64DD32 with Optiboot and AVR64DD32 without Optiboot. The sample is as follows: `#define RED_LED PIN_PF5 void setup() This sample is successfully compiled for the target AVR-DD series (Optiboot) Sketch uses 1276 bytes (1%) of program storage space. Maximum is 65024 bytes. But for the target AVR-DD series (no bootloader) compiler generates a lot of errors: In file included from C:\Users\User\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.5.6\cores\dxcore\Arduino.h:597:0, It makes me think that DxCore is not quite mature. |
Beta Was this translation helpful? Give feedback.
-
Sorry, I am a bit confused. Should I wait for a new revision of DxCore? |
Beta Was this translation helpful? Give feedback.
-
Hi Alex, The symptoms you are describing look oddly similar to #403. You might check out tag 1.5.5 or later if you havent already. c. |
Beta Was this translation helpful? Give feedback.
-
OK, one more time. Lets consider a very simple program for a board based on AVR64DD32, There is a LED connected to PF5. Also there is a 1K bootloader capable to write code to application area and then passing control to address 0x400. Also there is an Arduino UNO based programmer passing hex files to the bootloader. DxCore file "boards.txt" modified, it has a new section "hbnode". It is similar to the section "avrddopti", but .text starts at 0x400. The sketch is as follows:
Compiled sketch as hex file follows:
When I load compiled sketch via the programmer and bootloader, nothing happens, LED is dark. More or less the same program compiled by MPLAB.X using AVR-GCC v7.3.0 and pack AVR-Rx_DFP v1.10.124. Compiled program follows:
|
Beta Was this translation helpful? Give feedback.
-
You say you copied avrddopti - did you correctly change the BOOTSIZE fuse?
Are you USING_BOOTLOADER or not? (this changes initialization routines in
very important ways - if it's set, we assume the bootloader is there, and
has done the resetting of reset flags and verified that we reset cleanly
before jumping to the app, so we don't do that again. If it is not set,
then we assume we are not using a bootloader, and then we have to put the
bad reset check in the app code. Duplicated reset checks (from
non-USING_BOOTLOADER-compiled sketch witha bootloader that checks and
clears the flags will crash in a bootloop because the reset check in the
app will see that there are no reset flags, and because it thinks nothing
has run first, it will hit the panic button because execution reached the
reset vector when the reset flags were 0x00, that can only happen if
something has cleared them since the last reset, ergo we did not run first,
and since we told it we weren't using a bootloader that coul;d only mean a
dirty reset occurecd and that nothing we do has any chance or hope of being
correct until the chip has been cleanly reset, so we do that. But if we lie
to the application and say there's no bootloader when there is one, and the
bootloader clears the flags, the app will continually reset when it sees no
reset flags, while the bootloader clears the flags before the app runs.
So:
* USING_BOOTLOADER must be defined if using a bootloader and the bootloader
clears flags (and, say, stuffs them into GPIOR0 in case the app needs to
know) before running the app.
* Otherwise it must not be defined.
* The size of the bootloader, the start of .text and the BOOTSIZE fuse must
ALL agree
* If USING_OPTIBOOT isn't defined, SPM_FROM_APP must not be defined either.
This is a bug - it was intended only to be an issue if SPM_FROM_APP was -1
(unconstrained), which forces us to have a fake bootloader section and
switch the vectors back to run from 0x0000 not 0x0200, and to get a bit
creative with where we locate the entry point to ensure that it goes in the
first page (it has to masquerade as something that the crt gives a high
priority for low addresses. progmem takes priority over almost everything
though, and you don';t control the order of PROGMEM entries in the flash.
So we had to find something with higher priority. Unfortunately that
section gets executed like code sometimes, so we had to guard it with an
rjmp over it to turn it into a speedbump instead of a deadfall trap.
…On Tue, May 30, 2023 at 5:06 AM Alex Kouznetsov ***@***.***> wrote:
OK, one more time. Lets consider a very simple program for a board based
on AVR64DD32 <https://github.com/akouz/HBnode>, There is a LED connected
to PF5. Also there is a 1K bootloader
<https://github.com/akouz/HBnode/tree/main/AVR64DD32/Bootloader> capable
to write code to application area and then passing control to address
0x400. Also there is an Arduino UNO based programmer
<https://github.com/akouz/HBnode/tree/main/AVR64DD32/Programmer> passing
hex files to the bootloader.
DxCore file "boards.txt" modified, it has a new section "hbnode". It is
similar to the section "avrddopti", but .text starts at 0x400.
The sketch is as follows:
void setup()
{
VPORTF.DIR = 0x20;
VPORTF.OUT = 0x20;
}
void loop()
{
while(1)
{
VPORTF.OUT ^= 0x20;
}
}
Compiled sketch as hex file follows:
:1004000047C0000055C0000053C0000051C00000AC
:100410004FC000004DC000004BC0000049C00000AC
:1004200047C0000045C0000043C0000041C00000BC
:100430003FC000003DC000003BC0000039C00000CC
:1004400037C0000035C0000033C0000031C00000DC
:100450002FC000002DC000002BC0000029C00000EC
:1004600027C0000025C0000023C0000021C00000FC
:100470001FC000001DC000001CC0000019C000000B
:1004800017C0000015C0000013C0000011C000001C
:1004900011241FBECFEFCDBFDFE7DEBF20E6A0E017
:1004A000B0E601C01D92A430B207E1F71ED085C0AE
:1004B000A7CFEF93FF93E0E0F0E68F938FB78F9392
:1004C00080818F5F808381818F4F818382818F4F75
:1004D000828383818F4F838381E08093260B8F916A
:1004E0008FBF8F91FF91EF91189588ED9CE084BFAD
:1004F0009093680021E02093030A9EEF9093260AD0
:100500009093270A89E08093000A85E08093E705AD
:100510001092E80537E03093010B90930C0B10928A
:100520000D0B8093000B3093110B90931C0B1092CA
:100530001D0B8093100B4FEF5FE04093AA0B50937D
:10054000AB0B90E89093820B1092810B4EEF50E032
:100550004093AE0B5093AF0B91E79093800B1092AA
:10056000E905209302069EE09093050690E690939D
:100570000306809300068091B000887F8560809399
:10058000B0008091B200887F85608093B2008FECCC
:1005900097E080932C0B90932D0B2093250B1092BA
:1005A000210B83E08093200B789480E284BB85BB91
:0E05B00090E285B3892785BBFCCFF894FFCF7E :0400000300000400F5 :00000001FF
When I load compiled sketch via the programmer and bootloader, nothing
happens, LED is dark.
More or less the same program compiled by MPLAB.X using AVR-GCC v7.3.0 and
pack AVR-Rx_DFP v1.10.124. Compiled program follows:
:100400000C9448020C9452020C9452020C94520226
:100410000C9452020C9452020C9452020C9452020C
:100420000C9452020C9452020C9452020C945202FC
:100430000C9452020C9452020C9452020C945202EC
:100440000C9452020C9452020C9452020C945202DC
:100450000C9452020C9452020C9452020C945202CC
:100460000C9452020C9452020C9452020C945202BC
:100470000C9452020C9452020C9452020C945202AC
:100480000C9452020C9452020C9452020C9452029C
:1004900011241FBECFEFCDBFDFE7DEBF0E945402A5
:1004A0000C945B020C94000280E284BB90E285B362 :0A04B000892785BBFCCFF894FFCF2D
:02000004008278 :090000000000000000D90C000210 :0400000300000400F5
:00000001FF
When I load compiled program via the programmer and bootloader, it works
as expected, LED is half brightness as it supposed to be,
—
Reply to this email directly, view it on GitHub
<#424 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEWZLXLE5LDON5B3NSALXIW2CDANCNFSM6AAAAAAWYBZYVM>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore <https://github.com/SpenceKonde/ATTinyCore>: Arduino support for
all pre-2016 tinyAVR with >2k flash!
megaTinyCore <https://github.com/SpenceKonde/megaTinyCore>: Arduino support
for all post-2016 tinyAVR parts!
DxCore <https://github.com/SpenceKonde/DxCore>: Arduino support for the AVR
Dx-series parts, the latest and greatest from Microchip!
Contact: ***@***.***
|
Beta Was this translation helpful? Give feedback.
-
Sorry, the #define that gets used is USING_OPTIBOOT on this core, It's USING_BOOTLOADER on one core and USING_OPTIBOOT on the other |
Beta Was this translation helpful? Give feedback.
-
I made another section in boards.txt named hbnode1. Instead of avrddopti, I used section avrdd as a base. It was edited the same way as before: hbnode1.build.text_section_start=.text=0x0400 This section does not define USING_OPTIBOOT flag, but for some reason my sketch compiled OK. And it works. |
Beta Was this translation helpful? Give feedback.
I made another section in boards.txt named hbnode1. Instead of avrddopti, I used section avrdd as a base. It was edited the same way as before:
hbnode1.build.text_section_start=.text=0x0400
hbnode1.bootloader.BOOTSIZE=0x02
This section does not define USING_OPTIBOOT flag, but for some reason my sketch compiled OK. And it works.