-
|
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.
-
|
I'll look into this with high priority and also investigate why this was not caught by CI testing. The bug was introduced when the DD support was added, which required nasty expressions to convert analog and digital pins, because if MVIO is enabled, you get fewer analog pins. In non-optiboot this isn't a problem because we set the MVIO fuses on upload. On optiboot boards, the fuses can only be set at bootload time, not upload time. This means that either the fuses match, in which case all is good, or they don't match, in which case undefined behavior can occur when performing analogReads (which we would otherwise prevent you from doing). The optiboot boards have 4 menu options for MVIO, two of which indicate the user is certain the fuses are set correctly and hence can be assumed, and the other two which verify the fuse when a pin is looked up. It is this pin lookup expression that has an issue in it, apparently. I thought I'd caught all of those. The DD support on the core is quite young, minor issues should not be surprising. |
Beta Was this translation helpful? Give feedback.
-
|
this may already have been fixed... |
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.
-
|
Yeah the latest release, 1.5.6. should have this fixed (the compile errors i mean. The 1k bootloader will still mean a new board definition in boards.txt that sets BOOTEND to 4 instead of 2 and section start of .text to 0x0400, and points to the right bootloader files and provides a ,means of uploading to it. |
Beta Was this translation helpful? Give feedback.
-
|
In Arduino 1.8.6 with installed DxCore 1.5.6 I use the following settings: If I use setting MultiVoltage I/O (MVIO): "Disabled" then Arduino refuses to compile the sketch: In file included from C:\Users\User\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.5.6\cores\dxcore\Arduino.h:597:0, If I use setting MultiVoltage I/O (MVIO): "Enabled" then Arduino compiles the sketch: Sketch uses 1308 bytes (1%) of program storage space. Maximum is 65536 bytes. If I try to program compiled sketch (eg hex file) using PicKIT4 and MPLAB IPE, I have the following output: _Configuration memory will not be programmed because no configuration bits settings have been defined in your code. Erasing... The following memory area(s) will be programmed: The programmed board does not work, eg LEDs do not blink, both LEDs stay lit. I did try a new board definition. The compiled application code was located properly, starting from 1K. But it did not work, both LEDs stay dark. |
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.
-
|
Could you include the (verbose) log from build? |
Beta Was this translation helpful? Give feedback.
-
|
Could you include the (verbose) log from build? I didn't see in your summary how you are setting the boot size fuses. Bootloader sets fuses as follows: The bootloader hex file has 3 lines at the end: As far as I understand, the second line defines fuses. When bootloader writes application code, it selects only records type 00, also it rejects records with addresses less than 0x0400. Thus, the following records shown above will be rejected:
In the last case the second record defines fuses, and it it is identical to the boodloader. In the Arduino code that record is absent, I think it is not relevant because bootloader already defined fuses and it will reject fuse record from the application code anyway. |
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.
-
|
did you correctly change the BOOTSIZE fuse? Yes, I changed bootloader size. Are you USING_BOOTLOADER or not? we assume the bootloader is there, and has done the resetting of reset flags Your explanations are quite complex. It looks like you refer to a context (eg knowledge of internal DxCore and Arduino guts) which might be obvious to you, but is not known to me, Sorry, I am missing what and where should I change. Maybe later I would be able to understand and appreciate the complexity you described. At the moment my goal is to make a very simple sketch working. |
Beta Was this translation helpful? Give feedback.
-
But how are you actually PROGRAMMING the fuses into the chip. AFAIK, not all tools will pull fuse info from the .hex file and translate it into actual UPDI commands to program the fuses.
Sorry; I should have been more explicit. Can we get the log from the upload attempt as well (with "verbose" turned on for upload preferences)? And for whatever you're using to burn the bootloader? I think the behavior you're seeing can be explained by having the BOOTEND fuse somehow not get updated for the 1k length. That would leave the vector table the wrong place (ie at the OLD BOOTEND) for the actual sketch, and the first interrupt would send it off into never-never land. (Could be something else, though...) |
Beta Was this translation helpful? Give feedback.
-
|
how are you actually PROGRAMMING the fuses into the chip. I use PicKIT4 to program my 1K bootloader and the fuses, as defined in the bootloader. So far bootloader itself cannot program fuses, while application code cannot program anything at all. Can we get the log from the upload attempt I do not use Arduino IDE to upload application code. There is a custom program. It takes hex file (generated by Arduino or MpLab) and sends it to a programmer. The programmer is based on Arduino UNO. It writes the received code into a serial EEPROM on the target board while keeping target AVR in reset mode. When all code successfully copied into EEPROM, the programmer writes a final message (ie a command for bootloader) into EEPROM and releases AVR reset. On power up bootloader checks the command in the EEPROM. If there is no command, it passes control to the application, to address 0x0400. If command is present, bootloader copies application code from the EEPROM into AVR flash, then erases command in EEPROM and resets. The intermediate step - EEPROM - needed because I am going to upload applications via a slow serial bus. I should be able to upload application to a selected node without interfering with other nodes and without upsetting normal bus operation. That would leave the vector table the wrong place (ie at the OLD BOOTEND) for the actual sketch In the hex files I posted above it is very clear that vector tables placed correctly starting from 0x0400. In Arduino code 2-bytes commands RJMP used, in MpLab code 4-bytes commands JMP used instead. In both cases the first application command at address 0x0400 jumps to address 0x0490. |
Beta Was this translation helpful? Give feedback.
-
MpLab doesn't default -mrelax? It can actually save a non-trivial amount of space. Not in the vector table ofc, but at a large scale it saves a word per jump or call in the app, which is often enough to notice. it's actually desirable if the vectors have been relaxed though, albeit only in specific fault conditions (in the event that you smash the stack and have corrupted the return address when you execute a ret instruction, you will return to whatever you overwrote the return address with interpreted as a pointer. execution will then bounce around your code with nonsense values in variables, jumping off to a random part of the program whenever it hit a return. It would eventually land in blank flash after the end of the app, a sea of 0xFFFF, which is not a valid instruction, and by all rights ought to be a noop. It's not, it's treated as sbrs r31, 7 0xFFF7. So assuming random contents in r31 after you;ve been bouncing around the program (a reasonable assumption) 50% of these will end up skipping every other instruction. Eventually they will reach the end of the flash and roll over. At this point the 50% that were not skipping, and 50% of the ones that were, ie, 75% of the time youwould hit the reset vector, and then assuming the bootloader or application checked for it and reset the reset fllags (one of the things USING_OPTIBOOT does is control this - if you are using a bootloader that clears the reset flags , you must define USING_OPTIBOOT, otherwise we will replicate the check, but the check will always fail because the bootloader cleared them, so we'll just sit there bootlooping. But anyway, I've actually thought about the idea of EEPROM bootloaders before myself... Never did anything on it though, couldn't come up with a use case. BTW, the wire buffer on those parts should be big enough to store a whole 128b page plus the 2 address bytes if you're using 24-series I2C eeproms :-P |
Beta Was this translation helpful? Give feedback.
-
|
the wire buffer on those parts should be big enough to store a whole 128b page plus the 2 address bytes The hex files I've seen so far all have no more than 16 bytes in any text string. But even if it is not the case in some occasions, it is irrelevant. While sending a code to EEPROM, I am not relaying to to the source hex file structure. First I read the whole hex file into an internal buffer, and then send 16-bytes chunks to EEPROM. While a typical 24C512 EEPROM write buffer can handle more than that, small chunks better fit bus traffic. |
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.
-
|
USING_OPTIBOOT is defined. If it is not defined, Arduino refuses to compile sketch. 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 I modified my bootloader to clear RSTCTRL.RSTFR flags before passing control to application. It did not make much difference, sketch still does not work. |
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.