search

stefanrueger / urboot

Small AVR bootloader using urprotocol
GNU General Public License v3.0
55 stars 8 forks source link

What are the benefits that this bootloader consumes less memory? #24

Closed kr4fty closed 1 year ago

kr4fty commented 1 year ago

Hello, sorry for the question. I am testing the new firmware on my TransistorTester (MCU: atmega324pa), but when I want to add more features to said tester, I cannot upload it because it tells me that the space is exceeded (>100%). For this reason I thought that by putting this bootloader and it taking up less space than the default bootloader, I could add more functionality to the firmware, but avrdude throws me a message that it already exceeded the limit (100.3%) and does not allow me to upload it to said chip.

>make upload                                                                                                                                                         

AVR Memory Usage
----------------
Device: atmega324p

Program:   32878 bytes (100.3% Full)
(.text + .data + .bootloader)

Data:        264 bytes (12.9% Full)
(.data + .bss + .noinit)

EEPROM:      761 bytes (74.3% Full)
(.eeprom)

avrdude -c arduino -P /dev/ttyUSB0 -p m324pa -b 115200 \
  -U flash:w:./ComponentTester.hex:a -U eeprom:w:./ComponentTester.eep:a

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9511 (probably m324pa)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude error: address 0x8010 out of range at line 2049 of ./ComponentTester.hex
avrdude error: read from file ./ComponentTester.hex failed

avrdude done.  Thank you.

make: *** [Makefile:233: upload] Error 1

I would have to do something else, did you want to remap the memory? what am i missing?

stefanrueger commented 1 year ago

Do you actually use a bootloader to upload the software? In which case you would connect the target MCU/board directly to the PC with a serial cable or an USB to serial adapter; the MCU of your board (your IC tester) would have a small program (bootloader) to burn the program onto its own chip (without an external programmer such as arduino ISP).

If that is the case then urboot is a really small bootloader (ca 50% smaller than optiboot), and you can choose one that has only 256 bytes for the ATmega324PA MCU. This directory has some that have 2 s WDTO, use UART 0, detect the baud rate of the host automatically, and do not blink an LED on use). But remember, the maximum program you can upload is 32768 - 256 bytes. You would need to burn this bootloader first using an external programmer. You may need to set fuses appropriately, see here. After you did that, you can upload directly from the PC to the IC tester board (you would need to use avrdude -c urclock -xnometadata for this, avrdude -c arduino does not work for that).

If you are really, really hard up for space, then you might want to burn your program without bootloaders. Then you have the full 32k available for your program. You will always need to use an intermediary device between the PC with AVRDUDE and the IC tester board with the ATmega324PA. Also you will need to set the fuses to jump to reset (instead of the boot section) in this case.

Has that answered your questions?

kr4fty commented 1 year ago

So, if I wanted to save more space, should I use for example URBOOT and then record directly using the serial port? or do i understand wrong?

Maybe I could use this interface, for example?

What would happen if I don't have a physical serial port and if I wanted to use a USB-TTL adapter? I'm sorry if I'm asking and saying very basic things for you
stefanrueger commented 1 year ago

You save the most space by not using a bootloader at all. Advantage: you can use all flash for your application program. Disadvantage: you always need to use an intermediary (physical) programmer, less good for rapid prototyping.

The normal, typical setup for bootloader usage is

Does your TransistorTester (MCU: atmega324pa) currently have bootloader and do you use it that way? The answer to that question is no if you program using an intermediary physical programmer. In this case keep programming it that way and do not use a bootloader.

If your board has a bootloader and you already program it using that bootloader find out how big that bootloader is. That bootloader then is most likely between 512 bytes and 4096 bytes. The fuse setting BOOTSZ would tell you how big that bootloader is (and in order to read these you would need a physical programmer connected, say with the ISP header). If that is the case and if you want to keep programming your board via its own bootloader then you might want to look at replacing the boards's bootloader with a 256-byte urboot vector bootloader. You would need to have access to the ISP header with the 4 SPI signals and Reset in order to replace the bootloader. Not all boards have that, and if your TransistorTester board lacks an ISP header you may be out of luck!

The schematic you have shown is unlikely to help/work. The connection between PC and a bootloader board ultimately needs to be from the PC to the RX/TX signals of the MCU.

kr4fty commented 1 year ago

Ok, now the pieces of the puzzle are coming together.

I thought the bootloader was essential to boot and load the program just like the bootloader and OS do on a PC. What I didn't understand before was that if a physical programmer is used, by ISP, now the bootloader is not needed (reference), if I'm not mistaken.

stefanrueger commented 1 year ago

Correct. If you have a bootloader and want to remove it the easiest way is to ensure the BOOTRST fuse bit is set to 1 (on the ATmega324PA this should be bit 0 of the high fuse). That way, the MCU jumps to the ordinary reset vector on any reset (and not the selected HW supported boot section). You can do so with an external ISP programmer. Don't change the other bits of hfuse (otherwise you risk disabling ISP programming).

And if ever you are tired of using a physical programmer in your development and want a slick uploading experience for rapid prototyping, give urboot a whirl. It's worth every byte :wink:

kr4fty commented 1 year ago

Good perfect. I just realized that no matter how much I record a bootloader, it is deleted when uploading the firmware to the board (using ArduinoISP as programmer).

> avrdude -c arduino -P /dev/ttyUSB0 -p m324pa -b 115200 -U \
  flash:w:./ComponentTester.hex:a -U eeprom:w:./ComponentTester.eep:a

Thank you again for your patience and excellent explanation.

stefanrueger commented 1 year ago

Sure, that will be the case. The complete flash memory will be deleted with your command line (including any previous bootloader that might have been there). Do check that 

avrdude -c arduino -P /dev/ttyUSB0 -p m324pa -b 115200 -U hfuse:r:-h

gives you a hex byte where the low bit is set. Best to double check with the ATmega324PA data sheet that the hfuse and the other fuses are set correctly

kr4fty commented 1 year ago

Flashing the fuses

> make fuses                                                                                                                                                        ✔  1m 9s  
avrdude -c arduino -P /dev/ttyUSB0 -p m324pa -b 115200 -U lfuse:w:0xf7:m -U hfuse:w:0xd9:m -U efuse:w:0xfd:m

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9511 (probably m324pa)
avrdude: reading input file 0xf7 for lfuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte lfuse ...
avrdude: 1 byte of lfuse written
avrdude: verifying lfuse memory against 0xf7
avrdude: 1 byte of lfuse verified
avrdude: reading input file 0xd9 for hfuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte hfuse ...
avrdude: 1 byte of hfuse written
avrdude: verifying hfuse memory against 0xd9
avrdude: 1 byte of hfuse verified
avrdude: reading input file 0xfd for efuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte efuse ...
avrdude: 1 byte of efuse written
avrdude: verifying efuse memory against 0xfd
avrdude: 1 byte of efuse verified

avrdude done.  Thank you.

Verification

~/ComponentTester-1.49m >  avrdude -c arduino -p m324pa -P /dev/ttyUSB0  -t                                                                                                                          1 ✘ 

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9511 (probably m324pa)
avrdude> dump hfuse

Reading | ################################################## | 100% 0.00 s 

0000  d9                                                |.               |
stefanrueger commented 1 year ago

OK, good luck and all, closing the issue