Troubleshooting Firmware Updates

Transcription

1 Troubleshooting Firmware Updates Fails To Enter Bootloader Mode Installing Bootloader Drivers Verify Proper Bootloader Installation Cannot Detect Firmware Version Using the Wrong Firmware Flash Overwriting the Bootloader Bootloader Corruption When Developing Under Atmel Studio 7 Atmel Studio 7 Development Precautions The following sections provide additional details on how to troubleshoot different issues related to the HDK firmware. Fails To Enter Bootloader Mode If during the firmware update process you receive an error message similar to the ones below it may indicate that the bootloader driver is not properly installed on your system. Installing Bootloader Drivers Before the firmware on an HDK can be flashed the headset must be put into bootloader mode. The tricky bit is when in bootloader mode the HDK is recognized, by Windows, as a different device. More importantly, Windows needs a specific driver in order to communicate with that device. Loading the drivers is simple and can be done at any time (not just during the firmware update flow). To update these drivers, navigate to C:\Program Files\HDK\HDK-Firmware-Utility/dfu-prog-usb (or the corresponding path on your system) and run the HDK_Bootloader_Drivers.exe

2 Verify Proper Bootloader Installation You can see if the drivers are properly installed by manually placing the headset into bootloader mode and checking the Device Manager. Follow the steps outlined in the Using Putty to Communicate with the HDK Firmware section of Advanced HDK Configuration. Open Device Manager. Check the Other Devices category and look for a device named "DFU ATXMEGA2563BU" with an exclamation point icon. If you see this entry it means the headset is in bootloader mode and the drivers are not properly installed. If instead, you find an Atmel USB Devices category at the top of the component and there is a device is listed there with no warnings, the drivers are properly installed and you may re-attempt the firmware update.

3 Cannot Detect Firmware Version There may be rare occasions where the firmware utility is unable to detect your HDK firmware version. Most likely this is caused by improperly connected hardware. Check your connections and re-check the firmware version number. If unsuccessful still you may also try manually checking the firmware version number using the Putty application. More information on this topic may be found here. Finally, if you are still unable to resolve the issue you may also try the OSVR Control application. If none of these steps resolves our issue we recommend that you contact support. Using the Wrong Firmware Flash If you happen to accidently flash an HDK 1 with an HDK 2 firmware file (or vice versa) it may be possible to recover it using specialized tools and procedure. These steps are beyond the scope of this document. We recommend contacting support for assistance. Overwriting the Bootloader It is possible to accidently overwrite the HDK Firmware bootloader when flashing the firmware using Atmel Studio 7.

4 Bootloader Corruption When Developing Under Atmel Studio 7 The Atmel ATxmega256A3BU bootloader occupies a special location in Flash memory starting at 256K, which is just above the Application Flash memory segment (see the following diagram). The OSVR HDK MCU application firmware is compiled under Atmel Studio 7. The HDK MCU bootloader Firmware is compiled under the IAR Embedded Workbench. There was no effort in either environment to combine the output of both compilers into a single complete hex file that includes both the Firmware application and bootloader. Therefore, if developing MCU Firmware in Atmel Studio 7 using the Atmel AVR JTAGICE3 debugger (shown below), when the Atmel Studio 7 enters debug mode by flashing the new firmware, the image only contains the firmware application (and not the bootloader). If precautions are not taken, the application firmware update will corrupt, erase, or overwrite the existing bootloader. This issue only occurs when using an JTAG programmer, because it goes directly to the hardware to update the flash memory. Any other flash update method (e.g. Atmel Flip, DFU Programmer, etc.) uses the bootloader to perform the update and thus protects the bootloader from being overwritten. Atmel Studio 7 Development Precautions Most OSVR HDK MCU developers use the JTAG programmer and have no need for a working bootloader. In fact, the only reason MCU developer might need a valid bootloader is to test bootloader functions. When the application hex file is released, the JTAG debugger is not used and no issue will arise since the bootloader is protected by the normal flash update methods. There are procedures or settings that can restore/preserve the Bootloader for the MCU application Firmware developers: Flash the Bootloader from the IAR Embedded Workbench immediately after the MCU application Firmware update. Note: the IAR IDE can be setup to use the same JTAG programmer. Set the Atmel ASF Wizard settings to "Erase only program area" and "Preserve EEPROM," and examine the MAP file to verify that no

5 code/data goes over the 0x address.there is no way to update the bootloader without the JTAG debugger. The bootloader is meant to be written once and only once and then protected, as all normal field firmware update events will use the bootloader and a Windows based application to update the OSVR application firmware.