# Efficient Runtime Firmware Update Mechanism for LoRaWAN Class A Devices
## 3 Developed System
### Implementation of the Proposed System
#### 3.5.2 Firmware  
The developed firmware testbed must consider the static and absolute allocation of functions in the microcontroller's memory. Therefore, updating a functionality of the application only requires replacing that particular function, which is confined to a code block whose size is an integer multiple of the memory rows size. In the development of the firmware update method during runtime proposed in [17], a maximum update size of up to eight rows was considered, resulting in a very short update downtime of less than 30 ms for the considered maximum number of update rows. Figure 9 depicts the functional diagram of the implemented application. In its normal state, the device is in sleep mode. Upon detecting that the wake-up button is pressed, the device wakes up and activates the RFID card reader. If a valid RFID card is detected during the listening period, the device opens the electric latch; otherwise, it returns to low-power sleep mode. After reading a valid RFID card, the device activates the electric latch and waits for access. Upon completion of this procedure, the device enables communications to log that event in the application server. Thereafter, the device checks for instructions to update new RFID cards, which may include removing or inserting new codes, and finally it checks for firmware update instruction. Figure 8: Implemented electronic device. The functional architecture of the proposed system can be divided into three functional blocks: applications, management of external peripherals, namely the RFID card reader and LoRaWAN transceiver, and system functions, encompassing internal peripherals and system management. For this purpose, three partitions were created in the program memory (Figure 10). The first is dedicated to applications, the second to external peripherals, and the third to the system, which includes management of the applications of the microcontroller proposed in this article, interface with internal peripherals, and support functions for applications. Upon setting the program memory map, the function addresses were statically allocated across the corresponding partitions (Figure 11). The program's memory map design considers the possibility that a function might require more memory in the future. Therefore, it was determined that the size allocated to each function should be increased by approximately 25% to accommodate extensions on the functions size, as shown in Expression (1). Using this expression, it was verified that the number of program memory  
Figure 10: Distribution of the three partitions in program memory. Figure 9: Functional diagram of the implemented application. rows assigned to each function corresponds to the integer value obtained by multiplying the function size in bytes by 1.25, divided by the size in bytes of a memory row plus 1. This approach aims to ensure a reserve of about 25% of the program memory for future updates. \[\text{Memory Allocation}\ \ [\text{row}]=\text{INT}\left[\frac{\text{Function Size}\times 1.25}{ \text{Row Size}}+1\right] \tag{1}\]  
In the developed system, it was considered that the device was of Class A, meaning a device that can only receive data from the network server in response to an uplink. Additionally, a data processing mechanism was implemented for received messages, differentiated based on virtual communication port usage. In the proposed firmware update scenario, the fact that information arrives through the firmware update-associated communication port is sufficient to trigger the firmware update mechanism, thus dispensing with the frame initialization tag. To validate the proposed remote firmware update process during runtime presented in this article, a correction was made for an error detected after the release of the last firmware version. After the installation of the end devices, it was found that energy consumption was higher than expected.