Comfused with AVR bootloader flash section

Go To Last Post
64 posts / 0 new

Pages

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

 

AmVRosia wrote:
If you refer back to older conversations, I cannot fit the whole of the bootloader at the Boot Flash Section, hence I had to split it (my bootloader is about 0x3500 words and the Boot Flash Section has max size 0x2000 words).

 

Now, I've totally lost track of this, and perhaps the "older conversations" would spread some light.

 

0x3500 is 13568 words, 27000 bytes.  A nearly-full Mega328 or Mega324.  That is "big iron" for almost all of my many scores of production AVR8 apps over the years.

 

But your bootloader needs to be that large?!?  Is there a complete AI engine in there?  How then can there be an Arduino bootloader that is somewhat nearly universally used, that is comprehensive and reliable and fits nicely into the much much smaller bootloader section of a '328?  And has been adapted for other image sources besides UART?

 

Yes, indeed, I've proceeded down a path in the past using initial assumptions that just turned too onerous.  But then I needed to back up and take a different direction rather than try to turn that sow's ear into a silk purse.

 

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Mon. Jul 19, 2021 - 03:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee, I tend to agree that it sounds very large but just to say this is an AT90CAN128 and the bootloader protocol is CAN. Now I don't know how much a minimal CAN support stack occupies but it's probably going to be a wee bit bigger than your "normal" UARt driver or whatever.

 

The AT90CAN128 datasheet tells us that the four bootloader sizes are 512, 1024, 2048 and 4096 words but that latter one is therefore 8K bytes. You might have thought you could get enough of CAN into that space (and a smattering of SPM) just to support firmware packet delivery. But, then again, I don't know that much about Atmel CAN - perhaps a LOT of work is left to the stack author ?

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

I did some testing without interrupts and I managed to get the same functionality in bootloader without them.

If no interrupts are now needed, then can use the simple version in post #49. You can change the start address to whatever you now want ( 0xC000 word address, 0x18000 byte address, it now seems). The boot vector is fixed to 4 options in upper flash, and since not using interrupts now the only requirement is to get the reset vector code in the proper place which will jump to your bootloader code. You also get the vector table, but is harmless if not used.

 

As you need more than 8k of bootloader code, you make the bootloader size the smallest it can be (1024bytes), and the only code in that 1024bytes will be the vectors, and the flash writing code as they are the only ones required to be there. The reason for using the smallest size is because all the other code will still be in a .text section which will live below the bootloader, and you would otherwise have to split it up if the vectors were stuck in the middle.

 

fuses set to boot reset vector, bootsize is minimal value-

mcu reset -> reset vector (flash size-1024 bytes) -> reset 'jmp' to __init(or whatever) which will most likely be at the start of .text 0x18000 since you specified the text region start address as 0x18000 in the linker script (doesn't matter where in .text the reset vector jumps to, it will be in the .text section in any case). You now no longer need the use of the vectors since interrupts not in use (no need to touch IVSEL either). The only requirement left is for the flash writing code to live in the NRWW section, which is done by using the section attribute on its function(s) (.flashfuncs). The flash writing function will need to block until done, and re-enable the RWW section so you can then return to your bootloader code which is in the RWW section.

 

If you decide you want interrupts, you change nothing except to set IVSEL as now required, and make sure interrupts are off during a flash write as you cannot jump into the RWW section where your code is located.

 

-------------------0x0000 (word addresses)
normal vectors
normal app code

end app code
-------------------0xBFFF (app gets 96K)
-------------------0xC000 (32K remaining, 31K usable)

(.text)
bootloader code 

                   0xF000 NRWW section
-------------------0xFE00 (bootsize=1024 bytes)

(.bls)
reset vectors

(.flashfuncs)
flash write function
-------------------0xFFFF end

 

 

  bls    (rx)   : ORIGIN = 0x1FC00, LENGTH = 1024
  text   (rx)   : ORIGIN = 0x18000, LENGTH = 32k-1024

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


clawson wrote:
Now I don't know how much a minimal CAN support stack occupies but it's probably going to be a wee bit bigger than your "normal" UARt driver or whatever.

I do know that one could do a functional app with a Mega161/Mega162 with the satellite chip.  Now, when doing a bootloader app one has some control over the configurations at both ends, so "minimal" is indeed a key word -- just as with doing e.g. SD-card bootloader.  Right? ;)

 

In any case, I'd like to see the analysis of this needed space.

 

https://www.avrfreaks.net/forum/... LOL, in this thread I tried to talk the poster out of using a bootloader, CAN or otherwise.  But there is an awfully interesting mention:

PorinsR wrote:
I have found Atmel's app note and code for "Slim" CAN bootloader, but its written in IAR.

 

And indeed:  http://ww1.microchip.com/downloa...

So 27KB still seems excessive...

 

 

 

 

 

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Mon. Jul 19, 2021 - 06:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Further digging shows an 8K bootloader in app note AVR914 https://www.datasheetarchive.com...

MikeB talked of it here https://www.avrfreaks.net/forum/... and we know that he knows his way around a can.

 

These people https://www.can-cia.org/fileadmi... did a CANopen implementation in about 4KB.

 

There are other hits that may be pertinent with a Google search on "atmel AVR bootloader using "CAN" protocol"  .  But there is enough in a quick dig to seem to indicate several (many?) existing implementations in the 4KB to 8KB -- i.e. conventional AVR8 bootloader-section-sized -- implementations.  Thus, the thrust to invent a new solution with convoluted vector tables seems puzzingl.

 

Also interesting is a recent discussion on eliminating the four cycles to save/restore R24 when doing a minimal ISR.  So any of the jumpity-jump approaches will totally obliterate chances for minimal ISR handling.  Trampolines, anyone?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:
... and perhaps the "older conversations" would spread some light.
#7's URL 

https://www.avrfreaks.net/forum/comfused-avr-bootloader-flash-section#comment-3138511

led to the OpenBLT bootloader.

theusch wrote:
A nearly-full Mega328 or Mega324.
Maybe port OpenBLT to a CAN PIC [CAN PIC <-> megaAVR or AVR Dx (megaAVR follow-on)]

 


homepage [OpenBLT Bootloader]

 

Microchip Delivers First 8-bit MCU Family for CAN FD Networks | Microchip Technology

PIC18F27Q84 - 8-bit Microcontrollers

PIC18F27Q84 microchipDIRECT (minimum 1.39USD each for 100)

 

"Dare to be naïve." - Buckminster Fuller

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

clawson wrote:
Now I don't know how much a minimal CAN support stack occupies but it's probably going to be a wee bit bigger than your "normal" UARt driver or whatever.
Similar

clawson wrote:
You might have thought you could get enough of CAN into that space (and a smattering of SPM) just to support firmware packet delivery.
May be akin to the program space of USB DFU is greater than USB CDC or USB HID (protocol makes the difference)

 

P.S.

Wasn't aware CAN is in hospitals.

CAN Applications | Controller Area Network (CAN) Overview - NI (second paragraph)

 


https://github.com/huukit/Atmega-CAN/tree/master/canbootloader/binaries

"Dare to be naïve." - Buckminster Fuller

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


gchapman wrote:

Maybe port OpenBLT to a CAN PIC

 

I'm not keeping up any longer.  When I was your age, open-faced BLT:

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

 

theusch wrote:

 

AmVRosia wrote:
If you refer back to older conversations, I cannot fit the whole of the bootloader at the Boot Flash Section, hence I had to split it (my bootloader is about 0x3500 words and the Boot Flash Section has max size 0x2000 words).

 

Now, I've totally lost track of this, and perhaps the "older conversations" would spread some light.

 

0x3500 is 13568 words, 27000 bytes.  A nearly-full Mega328 or Mega324.  That is "big iron" for almost all of my many scores of production AVR8 apps over the years.

 

But your bootloader needs to be that large?!?  Is there a complete AI engine in there?  How then can there be an Arduino bootloader that is somewhat nearly universally used, that is comprehensive and reliable and fits nicely into the much much smaller bootloader section of a '328?  And has been adapted for other image sources besides UART?

 

Yes, indeed, I've proceeded down a path in the past using initial assumptions that just turned too onerous.  But then I needed to back up and take a different direction rather than try to turn that sow's ear into a silk purse.

 

 

To sum up and clarify a few things regarding the bootloader choice and size:

 

The actual size of the bootloader is a bit over 0x2000 bytes (sorry mistakenly I said words in the previous post)

 

That includes the:

CANBus,

XCP protocol over CAN which supports file transfer and some other features (and I think that we should focus more on that as a size increase suspect rather than the CAN driver), 

the UART with printf for debugging purposes (biggie too),

some GPIO control,

flash drivers and

I2C drivers for an external EEPROM.

 

If I remove the UART it just about fits under the 0x2000 margin. But for some reason, I could not make other parts to work and I did not had a debugging mechanism to know why.

I could develop debugging over CANBus but I might end up to the same size problem. Or alternatively in a future revision of the boards I am working on have the additional debug pin accessible by the programmer as I asked for (JTAG instead of ISP).
 

If you see the source code of Feaser OpenBLT they have created a struct of the flash layout, dividing it into sectors of 32kb which I divided further down to 8kb. Because I just about exceed the 8kb I have to reserve 2 sectors hence the 16kb and the address 0x4000 (address in .hex file). Then I started becoming greedy and since I have reserved so much space for the bootloader I added a few more features and now I am at specifically 0x311A total and after the revised architecture it looks like this:

.text              0x0001a000     0x296e

.bootloader     0x0001e000      0x7ac

 


 

 

Last Edited: Tue. Jul 20, 2021 - 11:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:

I did some testing without interrupts and I managed to get the same functionality in bootloader without them.

If no interrupts are now needed, then can use the simple version in post #49. You can change the start address to whatever you now want ( 0xC000 word address, 0x18000 byte address, it now seems). The boot vector is fixed to 4 options in upper flash, and since not using interrupts now the only requirement is to get the reset vector code in the proper place which will jump to your bootloader code. You also get the vector table, but is harmless if not used.

 

As you need more than 8k of bootloader code, you make the bootloader size the smallest it can be (1024bytes), and the only code in that 1024bytes will be the vectors, and the flash writing code as they are the only ones required to be there. The reason for using the smallest size is because all the other code will still be in a .text section which will live below the bootloader, and you would otherwise have to split it up if the vectors were stuck in the middle.

 

fuses set to boot reset vector, bootsize is minimal value-

mcu reset -> reset vector (flash size-1024 bytes) -> reset 'jmp' to __init(or whatever) which will most likely be at the start of .text 0x18000 since you specified the text region start address as 0x18000 in the linker script (doesn't matter where in .text the reset vector jumps to, it will be in the .text section in any case). You now no longer need the use of the vectors since interrupts not in use (no need to touch IVSEL either). The only requirement left is for the flash writing code to live in the NRWW section, which is done by using the section attribute on its function(s) (.flashfuncs). The flash writing function will need to block until done, and re-enable the RWW section so you can then return to your bootloader code which is in the RWW section.

 

If you decide you want interrupts, you change nothing except to set IVSEL as now required, and make sure interrupts are off during a flash write as you cannot jump into the RWW section where your code is located.

 

-------------------0x0000 (word addresses)
normal vectors
normal app code

end app code
-------------------0xBFFF (app gets 96K)
-------------------0xC000 (32K remaining, 31K usable)

(.text)
bootloader code 

                   0xF000 NRWW section
-------------------0xFE00 (bootsize=1024 bytes)

(.bls)
reset vectors

(.flashfuncs)
flash write function
-------------------0xFFFF end

 

 

  bls    (rx)   : ORIGIN = 0x1FC00, LENGTH = 1024
  text   (rx)   : ORIGIN = 0x18000, LENGTH = 32k-1024

 

I think I follow this design, but I am not 100% sure, I will come back to that and check it in more detail.

 

I have removed the interrupts, I have set the reset vector to jump to NRWW section, and somehow it works which I do not fully understand yet. How does it know where my bootloader starts?
The .text is at 0x0001a000 and includes main() as well as everything else

The .bootloader is at 0x0001e000 and it only includes the flash write and flash erase functions

 

My application at 0x0 is working fine with its interrupts. Sometimes I think when I jump from the bootloader to the application I get problems, but I have changed a few things and I need to spend more time testing. I was wondering is it best for the bootloader to change the reset vector to point to address 0x0 just before the jump? Or is it best for the application to change the reset vector to point to address 0x0 during its initialisation? What if the application is corrupted? How do we get back to the bootloader execution if the reset vector points at 0x0?

Last Edited: Tue. Jul 20, 2021 - 11:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AmVRosia wrote:
The actual size of the bootloader is a bit over 0x2000 bytes
So close ... well done!

Bootloader documentation sometimes states a specific toolchain configuration; might try different versions of the compiler and/or different compiler makes (several for C on AVR)

AmVRosia wrote:
the UART with printf for debugging purposes (biggie too),
Microchip Data Visualizer (extension or executable) can do the formatting in-lieu of the AVR.

AmVRosia wrote:
Or alternatively in a future revision of the boards I am working on have the additional debug pin accessible by the programmer as I asked for (JTAG instead of ISP).
If there's a spare port then consider requesting that to a logic analyzer connector.

JTAG will enable a low-rate no-breakpoint communication between Microchip Studio and the AVR (OCDR register)

A logic analyzer enables high-rate low-latency communication via an AVR port.

 


Terminal Example Code | Data Visualizer Software User's Guide

 

Troubleshooting real-time software issues using a logic analyzer - Embedded.com

Logic-to-2x4 Header (Gen 2) | Saleae Cart

IDR Events | Microchip Studio  (OCDR)

 

"Dare to be naïve." - Buckminster Fuller

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

AmVRosia wrote:
Or alternatively in a future revision of the boards I am working on have the additional debug pin accessible by the programmer as I asked for (JTAG instead of ISP).
If there's a spare port then consider requesting that to a logic analyzer connector.

JTAG will enable a low-rate no-breakpoint communication between Microchip Studio and the AVR (OCDR register)

A logic analyzer enables high-rate low-latency communication via an AVR port.

 

Thanks. Could you please post more information on hardware setup?

 

Is there any way of accessing any breakpoints in AVR?

 

https://microchipsupport.force.c...

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

You're welcome.

AmVRosia wrote:
Could you please post more information on hardware setup?
If EBI (XMEM) isn't in use then port A or port C to a header.

Header layout depends on the logic analyzer though Mictor is a somewhat common connector.

Other than a complete port, a spare SPI may be fast enough and may be preferred as SPI can be the source or sink of biphase (clock recovery from one signal as signal is data plus clock)

AmVRosia wrote:
Is there any way of accessing any breakpoints in AVR?
Yes by enabling the OCD (OCDEN)

In linked article, Atmel Studio has been replaced by Microchip Studio.

 


AT90CAN32 AT90CAN64 AT90CAN128 - doc7679.pdf

[page 5, package lower right corner]

Pinout AT90CAN32/64/128 - TQFP

MA134A Mictor Adapter for Intronix Logic Analyzers

Getting Started with Configurable Custom Logic (CCL) (mid-page for bi-phase)

The Art of Electronics 3rd Edition | by Horowitz and Hill

Download a sample chapter

[page 19, middle of left column]

14.7.10 Biphase coding1041

A biphase encoder and decoder can be in a sPLD.

 

Microchip Studio (operator's manual)

Interface Settings | Microchip Studio

Microchip Studio for AVR® and SAM Devices | Microchip Technology

Connecting to a JTAG Target | Atmel-ICE

Pinouts for Interfaces | MPLAB® PICkit™ 4 In-Circuit Debugger User's Guide

 

"Dare to be naïve." - Buckminster Fuller

Pages