Upgrading Embedded Design Firmware Via Usb
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Upgrading Embedded Design Firmware Via Usb as PDF for free.
More details
- Words: 2,397
- Pages: 5
Upgrading Embedded Design Firmware via USB By Rakesh Reddy, Cypress Semiconductor Corp.
The ubiquitous USB communication medium that was intended to connect a mice or keyboard to a computer has spawned to work wonders with speakers, cameras, printers and many other devices. Today, products ranging from guitars to automobiles come equipped with USB. In such devices, new features can often be added or performance glitches can be fixed through changes in software running within the embedded controller and using the existing USB connection, designers can exploit an inherent benefit and provide product resident reprogrammability.
Changing the software running in a microcontroller can often add features and/or fix bugs on a device that were not caught before shipping. In a glucose meter for instance, compatibility with new strips can be made possible by a change in software. In the case of an optical mouse that does not work on certain customer’s desks, a software change could allow recharacterization of data received from the image sensor. Such design changes that do not require a redesign of the hardware layout are quite commonplace and can be effectively handled by reprogramming the target silicon when the product has not left the factory. Once in the hands of the customer, however, direct programming is not practical as such processes require unique hardware and access to dedicated pins on the microcontroller. If the device already required USB to serve as a communication mechanism, then with the addition of a simple bootloader application in the original firmware, new and subsequent firmware can be downloaded using a standard computer, either by the manufacturer or an end user.
In embedded microcontrollers, a bootloader is a small program that resides in program memory. When the part is reset or powered on, the bootloader application runs first and directs the processor to either execute the user application or download a new one. With this configuration, direct programming is required only to insert the bootloader into the program memory. The bootloader can then use different communication techniques to fetch the new application. USB, I2C, SPI, UART, or even a proprietary protocol can be implemented to download the new program. Different approaches can also be used to store the downloaded application. Based on memory requirements, the program can either be stored on the internal Flash of the microcontroller or externally in a variety of storage mediums. As most bootloaders can be implemented using a small amount of program space, they often reside alongside the user application in the same Flash memory. While coexisting, it is the bootloader application’s responsibility to avoid writing over itself when trying to download code to the same memory. The bootloader portion of memory space can be write-protected to prevent any accidental corruption.
Upgrading Embedded Design Firmware via USB Published in Embedded.com (http://www.embedded.com)
Page 1 of 5 June 2008
[+] Feedback
Figure 1. USB bootloader data flow
The Bootloader The general data flow prescribed for a USB bootloader application is shown in Figure 1. Upon power-up or reset, the bootloader calculates the checksum of the user application and compares it to the one stored in memory set aside as a field programmable bootloader checksum block. If the two values match, then the bootloader directs the processor to begin executing the user application. However, if the checksums are different, the bootloader assumes that a host is waiting to dispatch new user code. In preparation, it turns off any interrupts that could disturb the download process. In certain systems it might be necessary for the microcontroller to manage critical tasks before starting the download. For instance, a fan might need to be turned on or some LEDs need to be blinking. As the application space is targeted for deletion, it is important for critical tasks such as the fan or LED control routines to be a part of the bootloader application. To begin communication, the bootloader sets up the USB interface and waits till the computer connects with the device. The handshake process through which a computer learns about what is plugged in is called enumeration. This ensures that the device is communicating with the right host software, which in this case will be a PC application containing the content that needs to be downloaded. In order to prevent accidental downloads and to ensure security, the bootloader looks for a key from the host in the transactions. Once the key has been verified, the bootloader responds to the host and requests the Flash image. As Flash memory does not support single address writes, a full page write is required. This is made possible by buffering the arriving data in RAM before addressing the entire page. As the processor at this point is dedicated to downloading new firmware, almost all the RAM resources should be available. Writes to Flash need to be stronger at lower temperatures. In order to increase the memory Upgrading Embedded Design Firmware via USB Published in Embedded.com (http://www.embedded.com)
Page 2 of 5 June 2008
[+] Feedback
retention and the number of write cycles, it is important to know the temperature expected in the field and implement the programming algorithms accordingly. Power stability is also an important factor during flash programming. Any power noise, glitches, brownouts, slow power ramps, and poor connections can cause problems which are difficult to diagnose. If a power transient does occur, then the bootloader starts again and restarts the download process as the checksum verification will fail. Once all the Flash pages including the checksum are successfully written, the bootloader verifies the Flash and initiates a reset. This time, after system reset, the bootloader finds the right checksum and begins execution of the user code. Once the valid checksum is in place, any further bootloader operations need to be called from the running user code. With the right application interface calls in place, the PC application should be able to directly command the user code to disable all interrupts, reset the USB hardware, and begin functioning as a bootloader. Alternately, the device could be set up to enter the bootloader enumeration process after being triggered by a change in status of some hardware such as a switch.
Figure 2. Possible layout of a general purpose bootloader
Memory Management Accidental erasures of the bootloader can cripple any further attempts to download code via USB. A systematic allocation of memory reduces or eliminates the risk of such a mishap. Figure 2 shows a possible layout that may be employed to arrange the bootloader application which can be used by a wide variety of Flash architectures. The first set of blocks contains the reset and USB interrupt vectors. This part of memory is non-relocatable and non-upgradable. The second set, highlighted in green, comprises the memory that is set aside for the bootloader application. This consists of the initial start command that looks for the bootloader checksum, the code used for downloading the new image, and finally room for the checksum itself. This set of code is re-locatable and different sections can be placed in unique areas of memory. However, once the project is ready to be deployed, all areas of this section except the checksum are non-upgradable. The third section is set aside for the user application. This portion contains the user code, along with any associated interrupt vectors and also the routines to call the bootloader application. This area is reprogrammable and re-locatable but should not
Upgrading Embedded Design Firmware via USB Published in Embedded.com (http://www.embedded.com)
Page 3 of 5 June 2008
[+] Feedback
be accessed when the bootloader is downloading code. Any interrupts that point to this section of code should be disabled before calling any bootloader functions. Consider the problems that a program might encounter if the code being executed was changed during execution.
The PC side of bootloading On the PC side, a software application needs to communicate with the device and transmit the new user code. This software can be made available by developers via the web or CD ROMs. The software should be capable of requesting the device to enter the bootloading state and provide it with the right verification key. When the device is ready, the host should send over the new contents which will be programmed onto the Flash memory. The user code being downloaded should be stitched together with the bootloader’s memory allocation in mind. This requires knowledge of the beginning and end of the user code, the checksum etc. As specified, in normal operation mode, the bootloader will always link to the address where it expects to find the start of the user code. Any bootloader calls from the user code will also have to point to the correct static locations of the bootloader functions. The PC can use a variety of mechanisms to deliver the content over USB to the bootloader. Based on the requirements of the bootloader residing in the device, either control, interrupt, or bulk transfers can be used to shuttle the data. The USB descriptors nested in the device can also decide the type of driver support that the application will require. The application can either be designed to exploit an operating system’s HID driver or use a custom vendor specific one.
Simplifying bootloading Bootloading is actually a common practice. Personal computers use the same principle for loading an operating system from a hard-drive. Many reference designs and example projects on the web help with the implementation of a bootloader in embedded designs. For example, Cypress Semiconductor’s PSoC Designer is an utility that can be used to create a USB or I2C bootloader that works with a wide series of Programmable System on Chips or PSoCs™. The USB bootloader user module generates all required bootloader code in a framework that coexists with the user application. This utility allows design of either a full speed, chapter 9 compliant, HID, or generic USB device. A wizard that helps generate accurate USB descriptors and supports bootloader transfers using either interrupt or control transfer types.
Figure 3: The USB bootloader looks for various selectable parameters such as the location of the first and last user application blocks, the first and last bootloader blocks, and the checksum addresses.
The user module dynamically creates the bootloader code based on the requirements anticipated during the design process. As shown in Figure 3 it looks for various selectable parameters such as the location of the first and last user application
Upgrading Embedded Design Firmware via USB Published in Embedded.com (http://www.embedded.com)
Page 4 of 5 June 2008
[+] Feedback
blocks, the first and last bootloader blocks, and the checksum addresses. Bootloader size can be also be customized to allow insertion of any special code that needs to run alongside the download process. The key that is prepended to USB transactions is also customizable. Knowledge of the anticipated temperature during future bootloader operations allows the utility to generate the appropriate programming routines. Finally, users can generate functions like void BootLdrUSB_EnterBootloader(void) that provide user code with ability to initiate bootloading operations from within the application. The module generates and validates the checksum of the content that is to be downloaded through the bootloader. Another tool derives the download file from the output of the compiler. This *.dld file contains the hex code arranged in Flash blocks along with the new checksum. It can be parsed easily by PC applications written using Visual Basic or C#. Engineering a method to download new user application into devices via USB can allow end users to upgrade their products for bug fixes or feature enhancements. The ability to update without requiring any special hardware eliminates the need for expensive recalls or replacements.
Cypress Semiconductor 198 Champion Court San Jose, CA 95134-1709 Phone: 408-943-2600 Fax: 408-943-4730 http://www.cypress.com © Cypress Semiconductor Corporation, 2007. The information contained herein is subject to change without notice. Cypress Semiconductor Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. PSoC Designer™, Programmable System-on-Chip™, and PSoC Express™ are trademarks and PSoC® is a registered trademark of Cypress Semiconductor Corp. All other trademarks or registered trademarks referenced herein are property of the respective corporations. This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source Code except as specified above is prohibited without the express written permission of Cypress. Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. Use may be limited by and subject to the applicable Cypress software license agreement.
Upgrading Embedded Design Firmware via USB Published in Embedded.com (http://www.embedded.com)
Page 5 of 5 June 2008
[+] Feedback
The ubiquitous USB communication medium that was intended to connect a mice or keyboard to a computer has spawned to work wonders with speakers, cameras, printers and many other devices. Today, products ranging from guitars to automobiles come equipped with USB. In such devices, new features can often be added or performance glitches can be fixed through changes in software running within the embedded controller and using the existing USB connection, designers can exploit an inherent benefit and provide product resident reprogrammability.
Changing the software running in a microcontroller can often add features and/or fix bugs on a device that were not caught before shipping. In a glucose meter for instance, compatibility with new strips can be made possible by a change in software. In the case of an optical mouse that does not work on certain customer’s desks, a software change could allow recharacterization of data received from the image sensor. Such design changes that do not require a redesign of the hardware layout are quite commonplace and can be effectively handled by reprogramming the target silicon when the product has not left the factory. Once in the hands of the customer, however, direct programming is not practical as such processes require unique hardware and access to dedicated pins on the microcontroller. If the device already required USB to serve as a communication mechanism, then with the addition of a simple bootloader application in the original firmware, new and subsequent firmware can be downloaded using a standard computer, either by the manufacturer or an end user.
In embedded microcontrollers, a bootloader is a small program that resides in program memory. When the part is reset or powered on, the bootloader application runs first and directs the processor to either execute the user application or download a new one. With this configuration, direct programming is required only to insert the bootloader into the program memory. The bootloader can then use different communication techniques to fetch the new application. USB, I2C, SPI, UART, or even a proprietary protocol can be implemented to download the new program. Different approaches can also be used to store the downloaded application. Based on memory requirements, the program can either be stored on the internal Flash of the microcontroller or externally in a variety of storage mediums. As most bootloaders can be implemented using a small amount of program space, they often reside alongside the user application in the same Flash memory. While coexisting, it is the bootloader application’s responsibility to avoid writing over itself when trying to download code to the same memory. The bootloader portion of memory space can be write-protected to prevent any accidental corruption.
Upgrading Embedded Design Firmware via USB Published in Embedded.com (http://www.embedded.com)
Page 1 of 5 June 2008
[+] Feedback
Figure 1. USB bootloader data flow
The Bootloader The general data flow prescribed for a USB bootloader application is shown in Figure 1. Upon power-up or reset, the bootloader calculates the checksum of the user application and compares it to the one stored in memory set aside as a field programmable bootloader checksum block. If the two values match, then the bootloader directs the processor to begin executing the user application. However, if the checksums are different, the bootloader assumes that a host is waiting to dispatch new user code. In preparation, it turns off any interrupts that could disturb the download process. In certain systems it might be necessary for the microcontroller to manage critical tasks before starting the download. For instance, a fan might need to be turned on or some LEDs need to be blinking. As the application space is targeted for deletion, it is important for critical tasks such as the fan or LED control routines to be a part of the bootloader application. To begin communication, the bootloader sets up the USB interface and waits till the computer connects with the device. The handshake process through which a computer learns about what is plugged in is called enumeration. This ensures that the device is communicating with the right host software, which in this case will be a PC application containing the content that needs to be downloaded. In order to prevent accidental downloads and to ensure security, the bootloader looks for a key from the host in the transactions. Once the key has been verified, the bootloader responds to the host and requests the Flash image. As Flash memory does not support single address writes, a full page write is required. This is made possible by buffering the arriving data in RAM before addressing the entire page. As the processor at this point is dedicated to downloading new firmware, almost all the RAM resources should be available. Writes to Flash need to be stronger at lower temperatures. In order to increase the memory Upgrading Embedded Design Firmware via USB Published in Embedded.com (http://www.embedded.com)
Page 2 of 5 June 2008
[+] Feedback
retention and the number of write cycles, it is important to know the temperature expected in the field and implement the programming algorithms accordingly. Power stability is also an important factor during flash programming. Any power noise, glitches, brownouts, slow power ramps, and poor connections can cause problems which are difficult to diagnose. If a power transient does occur, then the bootloader starts again and restarts the download process as the checksum verification will fail. Once all the Flash pages including the checksum are successfully written, the bootloader verifies the Flash and initiates a reset. This time, after system reset, the bootloader finds the right checksum and begins execution of the user code. Once the valid checksum is in place, any further bootloader operations need to be called from the running user code. With the right application interface calls in place, the PC application should be able to directly command the user code to disable all interrupts, reset the USB hardware, and begin functioning as a bootloader. Alternately, the device could be set up to enter the bootloader enumeration process after being triggered by a change in status of some hardware such as a switch.
Figure 2. Possible layout of a general purpose bootloader
Memory Management Accidental erasures of the bootloader can cripple any further attempts to download code via USB. A systematic allocation of memory reduces or eliminates the risk of such a mishap. Figure 2 shows a possible layout that may be employed to arrange the bootloader application which can be used by a wide variety of Flash architectures. The first set of blocks contains the reset and USB interrupt vectors. This part of memory is non-relocatable and non-upgradable. The second set, highlighted in green, comprises the memory that is set aside for the bootloader application. This consists of the initial start command that looks for the bootloader checksum, the code used for downloading the new image, and finally room for the checksum itself. This set of code is re-locatable and different sections can be placed in unique areas of memory. However, once the project is ready to be deployed, all areas of this section except the checksum are non-upgradable. The third section is set aside for the user application. This portion contains the user code, along with any associated interrupt vectors and also the routines to call the bootloader application. This area is reprogrammable and re-locatable but should not
Upgrading Embedded Design Firmware via USB Published in Embedded.com (http://www.embedded.com)
Page 3 of 5 June 2008
[+] Feedback
be accessed when the bootloader is downloading code. Any interrupts that point to this section of code should be disabled before calling any bootloader functions. Consider the problems that a program might encounter if the code being executed was changed during execution.
The PC side of bootloading On the PC side, a software application needs to communicate with the device and transmit the new user code. This software can be made available by developers via the web or CD ROMs. The software should be capable of requesting the device to enter the bootloading state and provide it with the right verification key. When the device is ready, the host should send over the new contents which will be programmed onto the Flash memory. The user code being downloaded should be stitched together with the bootloader’s memory allocation in mind. This requires knowledge of the beginning and end of the user code, the checksum etc. As specified, in normal operation mode, the bootloader will always link to the address where it expects to find the start of the user code. Any bootloader calls from the user code will also have to point to the correct static locations of the bootloader functions. The PC can use a variety of mechanisms to deliver the content over USB to the bootloader. Based on the requirements of the bootloader residing in the device, either control, interrupt, or bulk transfers can be used to shuttle the data. The USB descriptors nested in the device can also decide the type of driver support that the application will require. The application can either be designed to exploit an operating system’s HID driver or use a custom vendor specific one.
Simplifying bootloading Bootloading is actually a common practice. Personal computers use the same principle for loading an operating system from a hard-drive. Many reference designs and example projects on the web help with the implementation of a bootloader in embedded designs. For example, Cypress Semiconductor’s PSoC Designer is an utility that can be used to create a USB or I2C bootloader that works with a wide series of Programmable System on Chips or PSoCs™. The USB bootloader user module generates all required bootloader code in a framework that coexists with the user application. This utility allows design of either a full speed, chapter 9 compliant, HID, or generic USB device. A wizard that helps generate accurate USB descriptors and supports bootloader transfers using either interrupt or control transfer types.
Figure 3: The USB bootloader looks for various selectable parameters such as the location of the first and last user application blocks, the first and last bootloader blocks, and the checksum addresses.
The user module dynamically creates the bootloader code based on the requirements anticipated during the design process. As shown in Figure 3 it looks for various selectable parameters such as the location of the first and last user application
Upgrading Embedded Design Firmware via USB Published in Embedded.com (http://www.embedded.com)
Page 4 of 5 June 2008
[+] Feedback
blocks, the first and last bootloader blocks, and the checksum addresses. Bootloader size can be also be customized to allow insertion of any special code that needs to run alongside the download process. The key that is prepended to USB transactions is also customizable. Knowledge of the anticipated temperature during future bootloader operations allows the utility to generate the appropriate programming routines. Finally, users can generate functions like void BootLdrUSB_EnterBootloader(void) that provide user code with ability to initiate bootloading operations from within the application. The module generates and validates the checksum of the content that is to be downloaded through the bootloader. Another tool derives the download file from the output of the compiler. This *.dld file contains the hex code arranged in Flash blocks along with the new checksum. It can be parsed easily by PC applications written using Visual Basic or C#. Engineering a method to download new user application into devices via USB can allow end users to upgrade their products for bug fixes or feature enhancements. The ability to update without requiring any special hardware eliminates the need for expensive recalls or replacements.
Cypress Semiconductor 198 Champion Court San Jose, CA 95134-1709 Phone: 408-943-2600 Fax: 408-943-4730 http://www.cypress.com © Cypress Semiconductor Corporation, 2007. The information contained herein is subject to change without notice. Cypress Semiconductor Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. PSoC Designer™, Programmable System-on-Chip™, and PSoC Express™ are trademarks and PSoC® is a registered trademark of Cypress Semiconductor Corp. All other trademarks or registered trademarks referenced herein are property of the respective corporations. This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source Code except as specified above is prohibited without the express written permission of Cypress. Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. Use may be limited by and subject to the applicable Cypress software license agreement.
Upgrading Embedded Design Firmware via USB Published in Embedded.com (http://www.embedded.com)
Page 5 of 5 June 2008
[+] Feedback
Related Documents
Upgrading Embedded Design Firmware Via Usb
December 2019 6
Embedded Systems Firmware Demystified
November 2019 14
Sherwood Firmware Upgrading Instruction-1
November 2019 12
Upgrading
May 2020 8
Usb Driver Design
June 2020 2