mega4809 curiosity nano bootloader EXTREMELY slow

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Has anyone tried using the simple UART bootloader put out by Microchip on the mega4809 curiosity nano? Here: https://www.microchip.com/wwwApp...

It's basically just transmitting the hex file byte by byte and verifying with an echo after each transmission. I'm using the virtual COM port on the on-board nedbg.

On this board the bootloading is pathetically slow - I'm talking over 60-70 seconds for a 7000 byte transfer (I've modified it to transfer only the required number of pages instead of padding and filling the whole flash). 

Using the same bootloader on the attiny817 xplained mini board is very fast, the transfer would probably take about a tenth of the time or lesser. Maybe the difference is the edbg chip - 4809 cnano has a SAMD21 while the 817xm has a mega32U4. I've had this issue before (https://www.avrfreaks.net/forum/...) and found that the USB-serial chip makes a world of difference, but this performance is the worst I've seen by far.

 

Would be glad to know if anyone has had a different experience, or anything I can do to make this better. I'm using a Mac, in case that makes a difference.

Thanks, and stay safe.

 

This topic has a solution.

-Sam

Last Edited: Sat. Jun 6, 2020 - 10:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think Arduino Uno Wifi2 tries to use it for over-the-air bootloading.
I looked at the code and decided that it really sucked.  Perhaps useful as an example how to use the NVM on the mega0 (significantly different that prior chips, BTW), but not much more.

 

I ported optiboot to the mega0/etc, and it's being used by MCUDude's MegaCoreC and Spence Konde's MegaTinyCore Arduino distributions (for whatever percentage of people are using a bootloader.  Most of the commonly-avaiable 4809 boards seem to include a UPDI programming chip.)

 

https://github.com/Optiboot/opti...

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Curiosity Nano user guide states that the CDC is block-based, so its optimised for larger chunks of data (up to 64b) coming in from the USB and being DMA-sent by the UART.   This means it probably has more overhead with repeated single-byte transfers.  The mEDBG has no DMA, so its interrupt-driven UART, which loads the core more but transfers small frames faster.

 

I bet if you used a Python driver that did a serial.write([array of data bytes]) if would go a lot faster than a repeated round-trip byte-by-byte...

 

nEDBG should find a better middle ground too though :/

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

samay wrote:
Has anyone tried using the simple UART bootloader put out by Microchip on the mega4809 curiosity nano?

Why would you want to try this if the direct programming via the nEDBG interface is much faster? nEDBG Virtual COM is a nice addition feature but not intended as a gateway for bootloaders...

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

Thanks for the explanation, @mraardvark. This is pretty much what I was expecting, that the nedbg had some sort of lacking USB CDC implementation. Guess I'll try rewriting the bootloader to do 64 byte transfers instead.

Also interesting that you should be the one to reply; the project I'm asking this for is actually based on pyupdi, so thanks for that too!

-Sam

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

Update: Rewriting the bootloader to do full-frame (multiples of 64 bytes) transfers gave me a ~20x improvement in speed (6400 byte program in approx. 3s including echo of all data).

 

-Sam

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

Nice work!

And thanks for the update.