Engineer-to-Engineer Note EE-336 Technicl notes on using Anlog Devices DSPs, processors nd development tools Visit our Web resources http://www.nlog.com/ee-notes nd http://www.nlog.com/processors or e-mil processor.support@nlog.com or processor.tools.support@nlog.com for technicl support. Putting ADSP-BF54x Blckfin Processor Booting into Prctice Contributed by Andres Pellkofer Rev 1 June 25, 2008 Introduction ADSP-BF54x Blckfin processors provide multiple wys to boot the processor. Some re known from older Blckfin derivtives, some hve updted fetures, nd some re completely new. For conceptul informtion nd descriptions of booting modes, refer to the Booting chpter in the processor s Hrdwre Reference [1]. This document provides the following references nd helps you get strted: Slve boot modes like SPI slve, TWI slve, nd UART slve A softwre exmple for the host device (which is nother ADSP-BF548 processor for the purpose of this demonstrtion), including loder files Records of the booting process in l formt. See [4] for the required softwre. Description of specil functions in the initiliztion code exmples [5] Figure 1. VisulDSP++ project options (Project -> Project Options -> Lod -> Options) Copyright 2008, Anlog Devices, Inc. All rights reserved. Anlog Devices ssumes no responsibility for customer product design or the use or ppliction of customers products or for ny infringements of ptents or rights of others which my result from Anlog Devices ssistnce. All trdemrks nd logos re property of their respective holders. Informtion furnished by Anlog Devices pplictions nd development tools engineers is believed to be ccurte nd relible, however no responsibility is ssumed by Anlog Devices regrding technicl ccurcy nd topiclity of the content provided in Anlog Devices Engineer-to-Engineer Notes.
Boot Host Wit (HWAIT) Signl The boot host wit (HWAIT) signl is sserted by the boot kernel when the processor is not redy to receive dt. It is vilble in ll boot modes, by defult. This signl is GPIO, which is hndled very conservtively by the boot code without encountering the receive fill sttus of peripherl buffers. This mens tht even if there is free spce in the peripherl s buffer to receive dt, this signl is sserted when the boot kernel is busy. The HWAIT GPIO signl must be pulled to its ctive stte by resistor to prevent the host device from strting the boot process while the Blckfin processor is still held in reset. The resistor lso defines the polrity of the signl. If Blckfin processor is the host device, the trnsfer should be done by the core only s the Blckfin DMA rchitecture does not enble the core to puse running DMA trnsfer. The HWAIT signl cn be evluted every single word or n interrupt cn be triggered if the signl is sserted. Once sserted, the host must puse immeditely fter hving sent the current word. With the new hrdwre flow control mechnism introduced with the ADSP-BF54x UART module, evluting the HWAIT signl is optionl when the host device properly dels with the RTS/CTS hndshke. Refer to the Booting chpter in [1] for more informtion. SPI Slve Boot Mode (BMODE = 0100) For SPI slve mode boot, the Blckfin processor receives boot dt from n externl host device connected over SPI. Refer to [1] for more detils on the generl setup nd configurtion. Figure 2 shows the strt of booting sequence using the SPI interfce. After the first bytes, some clcultions on the Blckfin SPI slve device hold up the device from receiving more dt. Tht s why the HWAIT signl is sserted. The SPI mster device does not stop sending dt immeditely, but finishes the current dt word. After HWAIT is de-sserted, the booting process continues (for demonstrtion purposes, dely loop implemented in the initiliztion code is executed during the booting process). Figure 2. Beginning of SPI slve booting TWI Slve Boot Mode (BMODE = 0110) For TWI slve mode boot, the Blckfin processor receives boot dt from n externl host device connected over TWI. Refer to [1] for more detils on the generl setup nd configurtion. The Blckfin TWI slve device behves similrly to the SPI device. Figure 3 shows the beginning of the TWI slve booting sequence, wheres Figure 4 shows how the TWI slve device cn stop the host to send Putting ADSP-BF54x Blckfin Processor Booting into Prctice (EE-336) Pge 2 of 6
more dt (for demonstrtion purposes, dely loop is implemented in the initiliztion code executed during the booting process). Figure 3. Beginning of TWI slve booting Figure 4. Initiliztion code execution with dely UART Slve Boot Mode (BMODE = 0111) For UART slve mode boot, the Blckfin processor receives boot dt from n externl host device connected over UART. Refer to [1] for more detils on the generl setup nd configurtion. During the booting UART host booting process, few criticl moments must be hndled properly. Bit Rte: Hndling System Clock Chnges The initil ction tken is the utobud sequence tht sets the UART bit rte in reltion to the system clock speed. Unlike other slve boot modes (e.g., SPI or TWI), the slve device requires the correct setting for the UART bit rte. Figure 5 shows the utobud detection sequence t the very beginning of trnsfer. Once the @ (0x40) utobud detection byte hs been received, the boot kernel returns 0xBF, DLL, DLH, 0x00 sequence on its trnsmit output. Finlly, HWAIT is relesed. Figure 5. UART: Autobud detection Flow Control The UART slve cn signl the host to puse ny on-going trnsfer in two different wys: HWAIT nd UART hrdwre flow control (UART RTS). Figure 6 shows the behvior when initiliztion code delys the boot process by trnsmitting sttus words bck to the host device, which, in this cse, relies on the HWAIT signl. Once HWAIT sserts, the host finishes the current dt word nd then wits before sending more dt (see UART1_TX). Tht is similr to the other slve boot modes described here. Figure 5 lso shows some ctivity on the trnsmit line before HWAIT releses nd the host processor resumes opertion. Putting ADSP-BF54x Blckfin Processor Booting into Prctice (EE-336) Pge 3 of 6
Figure 6. UART: HWAIT signlling Another wy to puse n on-going trnsfer is vi the UART hrdwre flow control mechnism. This feture is implemented on the ADSP-BF54x UART for the first time nd is not vilble on other Blckfin derivtives t this time. It uses the UART RTS signl. If the host device supports this feture, no dditionl signl need be connected. The behvior on the host side is similr; if RTS is sserted, gin the host trnsmits the current word only nd puses immeditely fter the trnsmission hs been completed. Figure 7 shows the behvior: the host stops to send (see UART1_TX) more dt fter UART1_RTS hs been de-sserted (RTS is ctive-low logic). This occurs when specific fill sttus in the buffer hs been reched. Figure 7. UART: RTS signlling Figure 6 nd Figure 7 show tht the slve device is sending dt words to the host. For full-duplex connections, the time overlp is not n issue. For hlf-duplex connections, where the dt line is shred, the progrmmer must tke cre of this (see VisulDSP++ initcode Exmples). To properly resolve reset sitution, pull-up resistor on the RTS output is recommended. VisulDSP++ initcode Exmples The initcode exmples tht ship with the VisulDSP++ 5.0 (Updte 3) [5] instlltion chnges the PLL frequency on the fly nd pys close ttention to the following two chllenges: Updting the UART bit rte divider when the system clock hs chnged during booting process Hlf-duplex trnsfer requirements by tking control of UART RTS signling If the PLL is chnged during the booting process (e.g., initiliztion code), specil cre must be tken by the progrmmer; otherwise, the boot process my fil. The UART controller requires tht the correct bit rte be set in the UARTx_DLL nd UARTx_DLL registers to interpret the incoming dt properly. If the system clock chnges, the bit rte dividers must be djusted. The initcode exmples tht ship with VisulDSP++ 5.0 (Updte 3) development tools nd lter tke cre of this with two functions. The functions, which re clled u32 urt1_get_bitrte(void) nd void urt1_set_bitrte(u32), re executed before nd fter the PLL chnge sequence, respectively. They re clled utomticlly if BMODE=0111 is detected. These functions sve (u32 urt1_get_bitrte(void)) the current UART bit rte, clculte the new UART divider vlue tht fit the sved bit rte, nd store it in the UARTx_DLL nd UARTx_DLH registers (void urt1_set_bitrte(u32)). Function void urt1_set_bitrte(u32) provides feedbck to the host by sending bck some bytes (like the boot kernel does fter utobud detection): Putting ADSP-BF54x Blckfin Processor Booting into Prctice (EE-336) Pge 4 of 6
0xAD UART1_DLL UART1_DLH 0x00 You cn see this on the UART1_TX signl in Figure 6 to Figure 9. Additionlly, criticl moment is the PLL reprogrmming sequence. There is time dely between the PLL chnge nd the renewing of the UART divisor. You must ensure tht during this reprogrmming phse the UART host does not send ny more dt. The function u16 urt1_check_buffer(u32) forces the UART to ssert the RTS signl by disbling hrdwre flow control nd setting RTS mnully. This is done in the UARTx_MCR register. After this, the host my send the very lst byte, for which you must wit. As this function is sending out 4-byte feedbck sequence, there is quite sfe time slot: 0xAA UART1_MSR UART1_LSR 0x00 After this the PLL reprogrmming sequence is running nd fter setting the new UART divisor vlue, the control for the RTS signl is pssed bck to the UART controller (re-enble hrdwre flow control). The originl settings of the UARTx_MCR re restored. You cn lso see tht HWAIT is de-sserted t the sme time. Figure 8. Mnipultion of hrdwre flow control For hlf-duplex connection, there might still be n overlp. Therefore, you cn insert dely (e.g., length of one dt word). This should ensure tht there will be no conflict on the line. Figure 9 shows the sme sequence s Figure 8 but with the included dely. Figure 9. Mnipultion of hrdwre flow control with dditionl dely If the host sends the lst word delyed, you must mnipulte your booting process to fit ll possible conditions. Putting ADSP-BF54x Blckfin Processor Booting into Prctice (EE-336) Pge 5 of 6
Appendix A A ZIP file is ssocited with this document. It contins project with code exmples for n ADSP-BF548 EZ-KIT Lite bord nd supports the following boot modes s host device: SPI slve boot TWI slve boot UART slve boot The project is progrmmed nd tested with VisulDSP++ 5.0 (Updte 3) development tools. The bsic configurtions re set in configurtions.h. Refer to README.txt for dditionl informtion. Appendix B A ZIP file is ssocited with this document. It contins some recordings of the specific booting processes. The files re for Agilent Technologies logic nlyzer ppliction softwre [4]. The code exmples from Appendix A hve been used. Refer to README.txt for more informtion. References [1] ADSP-BF548 Blckfin Processor Hrdwre Reference. Rev 0.3, My 2008. Anlog Devices, Inc. [2] ADSP-BF548 Blckfin Processor Peripherl Hrdwre Reference Mnul. Rev 0.1, Mrch 2007. Anlog Devices, Inc. [3] ADSP-BF548 Blckfin Processor Evlution System Mnul. Rev 1.2, April 2008. Anlog Devices, Inc. [4] Agilent Technologies 16900, 16800, nd 1680/90 Series Appliction Softwre. [5] VisulDSP++ 5.0 (Updte 3): Initiliztion code exmples (<instll_pth>\blckfin\ldr\init_code\) Redings [6] ADSP-BF53x/ADSP-BF56x Progrmming Reference. Rev 1.2. Februry 2007. Anlog Devices, Inc. [7] EE-240: ADSP-BF533 Blckfin Booting Process. Rev 3, Jnury 2005. Anlog Devices, Inc. [8] EE-331: UART Enhncements on ADSP-BF54x Blckfin Processors. Rev 1, November 2007. Anlog Devices, Inc. Document History Revision Rev 1 June 25, 2008 by Andres Pellkofer Description Initil relese. Putting ADSP-BF54x Blckfin Processor Booting into Prctice (EE-336) Pge 6 of 6