Hello everyone,

I am willing to program an ATtiny1617 microcontroller, I will develop UART, I2C and SPI protocols. 

Being used to AVR microcontrollers where there is a free arduino bootloader, I am a little bit lost here since I don't know where to develop a bootloader for my ATtiny1617 or not.

After many searchs on internet, I found people saying that if you have complicated programs better use a bootloader, but I  didn't find an explanation.

So my question is why a bootloader is safer ? What does it do that a JTAG doesn't ? And can I make a robust updatable firmware with just a JTAG ? thank you !

#Bootloaders #JTAG

Your JTAG tool is great for debugging and developing an embedded application. If you are physically present to your device, you would want to use JTAG (or SWD). 

A bootloader is useful in a production system to allow you to update your software through software without the need for specialized hardware (the JTAG tool). You can write a bootloader to read new firmware from an SD card, read a file from the internet, receive a new application through TCP/IP, I2C, UART or any other interface. 

If you deploy a product, you don't want to have to send an expensive JTAG to every customer to allow them to reprogram their device. Instead, you use a bootloader to accept a new application over a common interface. 

Complication of the program has nothing to do with whether you use a bootloader or not. They are not necessarily "safer" (where I think you would have to define what you mean by safe).

The obvious difference is a JTAG adapter is hardware and a bootloader is software. Of course, to feed bits into a target device you need both a hardware connection and software to work the connection (and feed the bits). The jtag adapter gives you the hardware connection but you still need some software to use that connection. With a software bootloader, you need some hardware connection (like USB or wireless). The JTAG adapter will almost always let you jam bits in but more difficult to do remotely of course. The software bootloader will let you add the bits anywhere there's a connection but if you brick the device, you're out of luck. Also, the JTAG typically uses integrated hardware features things like SWD and comes with deep built-in debugging capabilities well beyond the scope of the bootloading process.

For a simple AVR micro that you possibly just use for hobby projects you probably don't need a bootloader. Burn the chip and that's it.

But if you develop a system that is deployed on the field in numbers and which might need a firmware update, you almost certainly would use a bootloader. 

A bootloader can check the integrity of the FLASH. That is actually an important thing if you plan your device to run unattended for years or maybe decades. In some cases the bootloader also performs a basic HW test so that the firmware is not unleashed on obviously broken hardware.

The other issue arises when you want to keep your code secret, e.g. you don't want someone just clone your gizmo. Then you put your MCU into lock-down, which renders all the JTAG and other debug interfaces inoperable. From that point on the only way you can burn the FLASH is via the bootloader. Chances are, the new firmware image will be stored in some external memory - which your competitor can read. Therefore, you store the code encrypted and only the bootloader knows how to decrypt it (as it contains the decryption key) and it can also verify that the image is intact and that indeed it came from you and not from a third party. 

The above is not some far-fetched exaggeration. Every car's engine is controlled by micros and they contain tricks that squeeze a few more horsepowers out of the engine while shaving one more percent off the fuel consumption and still meet environmental regulations. Those tricks cost manufacturers millions and they most certainly do not want their competitors to learn them. At the same time, the engine management MCUs must be upgradeable (if something turns up and needs fixing, for example).

So the bootloader of an embedded gizmo can be quite complicated. Yes, what it needs to to is not much more than to transfer the binary image from your computer into the MCU's FLASH, but that process can become quite complicated, depending on your circumstances.

JTAG can program a bootloader (uses HW mechanism to bootstrap the CPU/MCU); as such has complete and unrestricted access to the device.

JTAG can also load an application (bootloader is actually special application).

Bootloader is application and it's purpose is to bootstrap the core (CPU/MCU) and set a channel (typically something serial, like UART, USB, SPI, CAN, etc.) from where to listen for incomming application. When application received and burned to local storage, it will give the control of the core to the application just loaded.

JTAG is a external piece of HW, which sometimes can cost quite a bit; also it needs special PCB provisioning for the signals;

to avoid this constraint, the bootloader enters the picture.

So safety in the bootloader is in the fact that it is a firmware that can check the incomming data and see if the address specified to burn the data, are actually safe address (bootloader should protect itself from being overwritten) and that is one the safety mechanisms it provides.

Obviously the previous statement is a bit simplified and naive, so often bootloader also implements some authentication & verification mechanism; and encription too...

so in the end it can become quite sophisticated application.

So on one side you have a JTAG that will load anything and you have bootloaders that can be as secure as a bank transaction...

With JTAG you can make robust updateable firmware (kind a obvious ;), but not OTA (Over-The-Air); just because you need special physical access to your device!

While with appropriate bootloader, you can do even that. and you don't need special hardware, just use one of the serial channels you have available (serial and USB are the most obvious).

Maybe this thread could be useful to you:

What is a Bootloader and when do you need one?

What they said.

Fundamentally, if you don't need hardware breakpoints, a bootloader gives you simplicity. All you need is some sort of (generally serial) communication path to the target.

Consider an Arduino. One of the reason for their success is you only need a USB cable. You can compile, download, and run in one simple step. And - the same USB cable allows you to put print() statements for debugging, reporting, and control.

Earlier bootloaders included monitor functions where you could set software breakpoints. DasBoot is an example.

Keep in mind, too, JTAG is relatively new. Most embedded projects required you to burn your code on an EEPROM to run it. By burning a bootloader on the EEPROM, it made downloading your code a lot easier and faster.

"And can I make a robust updatable firmware with just a JTAG ?"

- yes, if you always have a JTAG. What happens if you don't? Or your clients/customers don't?

"Being used to AVR microcontrollers where there is a free arduino bootloader, I am a little bit lost here since I don't know where to develop a bootloader for my ATtiny1617 or not"

First, don't re-invent the wheel unless you want to learn howto make a bootloader. You could use the Arduino bootloader for the ATTiny. I also suspect others have written a bootloader for it.

One of the best bootloaders out there is the one for the Teensy. Sadly, the teensy folks consider it proprietary. Basically, you run a program that sits in the background && point it at your .hex file. To download after a compile, you just reset the Teensy && the magic happens. I would be thrilled if they licensed it for a reasonable cost.

Good Question! Let us know what you decide to do!

There are a lot of advantages of use a bootloader in a product. The main is safety, a  bootloader will provide access only to whom know the bootloader process, also you can add authentication or/and encryption to the process while anyone can attach a JTAG to change your application. In the other hand a bootloader is very useful no intrusive way to update a product on the field, with the right tools even the user can do the software update.

The only disadvantages are to add some complexity in your code and maybe some memory space. In the past I did basic bootloaders <3Kb in Cortex M0 and M3 MCUs.

More complex bootloaders can accept small applications running in RAM for diagnostics tasks, the sky is the limit!

Hi there.

Basically JTAG was developped for two main reasons (except of programming and debugging of a device of course): to perform the boundary scan of quite complex HW especially (FPGA alike) - what has @Kotsonya mentioned - and to program bunch of devices automatically. If you are thinking of mass production somewhere on the horizon, JTAG is the reasonable option.

Cheers, Adam.