Hi Folks,

I wanna ask on how can I update the firmware of a microcontroller using another microcontroller with only UART connection.



Basically, I wanna load the data of the updated software in the PIC18F then use it to change the firmware of the EFM32 microcontroller.

Now, I have read in the internet that it is possible but can someone explain it in more easier terms since I'm just starting to learn microcontrollers.
If someone could, it will be very helpful to me. Thanks!

Regards,
Chandler

 

You have to create a bootloader on the receiving MCU that the sending MCU can pipe data to over the UART. The sending controller needs to be able to manipulate the receiving MCUs pins according to how the receiving MCU is set for bootloader execution.

 

The sending controller needs to be able to manipulate the receiving MCUs pins according to how the receiving MCU is set for bootloader execution.

Can you elaborate this sentence sir. I can't quite understand what you mean.

 

SiLabs EFM32 is programmed via a 2-wire SWD interface.
You need two signals, SWCLK and SWDIO.

AN0062 - Programming internal flash over the Serial Wire Debug interface.
https://www.silabs.com/documents/public/application-notes/an0062.pdf

AN1011 - Standalone programmer via the SWD interface.
https://www.silabs.com/documents/public/application-notes/AN1011-efm32-standalone-programmer.pdf

 

If you're just starting to learn microcontrollers then this is likely beyond your ability. Why don't you start with learning your individual microcontrollers? Then get one to use a bootloader. Why people want to start off doing several things that they don't understand is beyond me.

 

You have to create a bootloader on the receiving MCU that the sending MCU can pipe data to over the UART. The sending controller needs to be able to manipulate the receiving MCUs pins according to how the receiving MCU is set for bootloader execution.

Is it also possible to create a bootloader on the sending MCU to bootload the receiving MCU?

 

Is it also possible to create a bootloader on the sending MCU to bootload the receiving MCU?

No. The receiving MCU needs to know what to do with the data. Hence, it needs a boot loader.

 

You may not have to write a boot loader. Many MCUs have bootloaders built in (ROM or otherwise-protected memory). These run some very simple protocol (not SWD) over a serial port (UART, e.g.), which allow you to erase and write Flash, which is really all you need.

It looks like the EFM32-s have one that talks over UART0:
https://www.silabs.com/documents/public/application-notes/an0042-efm32-usb-uart-bootloader.pdf

Before you get too far into this, consider: Where will you get the text to send to the program-ee?

[Edit: Clarified that these don't use SWD.]

 

Before you get too far into this, consider: Where will you get the text to send to the program-ee?

[Edit: Clarified that these don't use SWD.]

You mean the updated firmware? It will be sent to the PIC thru wireless transmission.

The part of updated firmware will be other team member's duty.

Mine is just about the PIC. The EFM32 is on another member also.

So, as I understand. What I need to do is just to send the updated firmware from PIC to EFM32 through UART rx and tx pins only, nothing more?

 

Also

You mean the updated firmware? It will be sent to the PIC thru wireless transmission.

The part of updated firmware will be other team member's duty.

Mine is just about the PIC. The EFM32 is on another member also.

So, as I understand. What I need to do is just to send the updated firmware from PIC to EFM32 through UART rx and tx pins only, nothing more?

Also, what if I use the same UART pins(PIC to EFM) to send other commands and receive data. Can I use the same UART lines that I used with bootloading the EFM32?

 

A bootloader is a piece of code that is placed in a specific, different area of memory from where your application code lives- you must write this code- or buy it.

The bootloader writes the incoming firmware into the application area of memory.

It must know where it can and cannot write, so it cannot overwrite itself.
If the bootloader gets erased or corrupted- it's bricked.


I have written a few bootloaders and I have to say it's really not a project for a beginner, even with years of experience, it's a very difficult task.

 

I don't know this EFM32, but not all processors can run a bootloader. What it needs is the ability to run code at the same time as loading code--it should be obvious that the code that runs will be writing to some other part of memory! Also, you have to deal with the processor's requirements for how the data is presented and what has to happen to load it properly. You need to be able to write code, and also to understand how the target processor functions on a pretty intimate level. It's challenging software, and not a project for a beginner, certainly not if you have a team waiting for it to work right.

If this processor can be loaded using 2 wires, the SWD interface, it might be easier than using the UART, even if a bootloader approach is possible.

 

Can I use the same UART lines to transmit and receive data (sensor reading), other than the new firmware image.

 

Yes, that's the attraction of a bootloader: you can connect up a serial port, and use it both to program the processor and to communicate with it while it's in operation. But it's not the simplest thing in the world to get running.

Edit to say that one thing you have to be aware of with a bootloader--the bootloader itself has to be installed with some other kind of setup, most likely a commercial programming device. And you'd better keep that device available and design your system to make it possible to use it, because accidents do happen, where the bootloader code gets damaged and has to be reinstalled. The voice of experience is speaking here.

 

Is it still called a bootloader in this case? You described a custom programmer more than a bootloader.

 

So, as I understand. What I need to do is just to send the updated firmware from PIC to EFM32 through UART rx and tx pins only, nothing more?

That is the gist of it. There's probably some mechanism for putting the target into the bootloader, which may involve access to one or two other pins. The STM32, for example, reads the state of a specific pin BOOT0 (extra pin #1) when you wiggle /RST (extra pin #2). But everything else happens over Tx/Rx.

I encourage you to read that AppNote, which should explain all this. I only read far enough to convince myself it was what you were (probably) looking for.