Products Mentioned

ADSP-21571 Production
The ADSP-SC57x/ADSP-2157x processors are members of the SHARC® family of products. The ADSP-SC57x processor is based on the SHARC+® dual-core and the arm...
Datasheet
ADSP-21571 on Analog.com

  • State Not Answered
  • +2 person also asked this people also asked this
  • Replies 17 replies
  • Subscribers 38 subscribers
  • Views 7964 views
  • Users 0 members are here
Options 

        

            Post
             Go back to editing
        

    

    


    

    









		


















	
	
			
	
			
		
	
	
		

		
ADSP-21571 SPI Slave Boot problem



		

			

									
					    Andersson
					
							

			
				
									
											
			
			
				
    
			
			
			    	
			                    
                
				                on Jan 28, 2019 
				
			
			
		
    

				
		
    
		    		    
		    
		    	
			
    Hi,
    

    I'm trying to boot an ADSP-21571 using SPI Slave mode, but I just can't get it to work.
    I'm pretty sure I have configured my SPI Master correctly (msb-first, pos. clk polarity). At the moment I'm running at a very low rate (1MHz).
    

    When analyzing the Boot Stream (as generated by the elfloader tool), I can not quite understand the value of Target Address field in the Block Headers.
    From what I understand, for a Normal Block, the Target Address should always be the byte address of where the payload should be loaded.
    However, all Target Address fields have $28 in the most-significant byte. The other 24 bits seem to represent the correct address, but multiplied with a factor 2,4, 12 etc compared to the address found in the generated map-file.
    

    Could someone please shed some light on this?
    

    By the way, are there any examples on how to boot an ADSP-.21571 in SPI Slave mode available?
    

    Thanks!
    
									
			        
		
    

				
						
        

    
    Tags: 
                                            
                 Audio Signal Processors
                
                                                    
                 ADSP-21571
                
                                                    
                 SHARC Audio Processors/SoCs
                
                                
            
    
    
    

		
    
			
						
									
									
						
						
			
			
			
			
		
    

        
        

					
    
			
    


    
















    
	
    
	
    
					



			








	
	
	
	



Parents
	
      
	

    • 
	
      



	
		
	
	



      
	
      
		
      
							
					
      
		
      
			
													0
							
			
				
									
							        
			
			
			
      •  Analog Employees  
      
            
						
                            
            
            				
            
                on Feb 8, 2019 1:39 AM
            
            
					
      
	
      

		
		
      
					
      Hi Anderson,

      I understand that SPI slave boot is not working for ADSP-21571. Is this correct? Can you please check the below and see if this could be of help.

      Can you please let me know how are you loading the .ldr file and sending it from the Host processor?
      Note that the SPI slave boot types do not need bit reversing necessarily. For SPI slave boots to non-PROM devices, the same default exists (bit-reversed); however, the host can simply be configured to transmit LSB first. Are you doing so?

      Please ensure that the correct boot kernel is used before generating the loader (.LDR) file. If you are using a modified boot kernel, try using the default boot kernel supplied with CCES together with a simple LED blink code to confirm basic boot-loading.

      Also, ensure that you have selected the correct parameters while generating the .LDR file. Selecting an inappropriate parameter may cause the boot to fail. Please choose the loader option (Boot mode (-b)) as ‘SPI slave’ for booting from the external host processor. 

      Meanwhile I would suggest you to try booting a simple LED blink application and check if that boots correctly. BTW, is it possible for you to hook up the SPI signals from the host and check if the data is sent out correctly?

      Regards,
      Lalitha S
      
			
      

		
			
	      

		
		
	
      
	
      
		
      
			
		
      
	
      
	
      
		
						
						
				
						
				
				
		
		
      
			
		
      
	
      

      

      • 

	

    • 
	
      



	
		
	
	



      
	
      
		
      
							
					
      
		
      
			
													0
							
			
				
									
							        
			
			
			
        
            
						
                            
            
            				
            
                on Feb 28, 2019 8:43 AM
            
            
												
						in reply to ADIApproved
					
									
        
	
        

		
		
        
					
        Hello Lalitha,
        

        Here's some further info on how I generate the loader stream.
        I'm calling the elfloader from command line using the following flags:
        

        elfloader -b SPISLAVE -bcode 3 -f INCLUDE -proc ADSP-21571 -verbose -Width 8 \
         -core1="Core1.dxe" \
         -core2="Core2.dxe" \
         -NoFinalTag="Core1.dxe" \
         -o ../Output.ldr
        

        The elfloader outputs the following message(s):
        

        *********************************************************************
         ADSP-21571 INPUT FILE(S) FOR BUILD
         CORE1 Core1.dxe
         CORE2 Core2.dxe
        *********************************************************************
        Process file: Core1.dxe
         Process section: dxe_block0_data_prio0_bw 
         Section start address: 0x2403F0 [0x2403F0]
         Section byte count: 0x68
         Process section: dxe_block0_data_prio1_bw 
         Section start address: 0x240468 [0x240468]
         Section byte count: 0xD84
         Process section: dxe_block0_data_prio2_bw 
         Section start address: 0x241240 [0x241240]
         Section byte count: 0x8C
         Process section: dxe_block0_data_prio3_bw 
         Section start address: 0x2412D4 [0x2412D4]
         Section byte count: 0x18
         Process section: dxe_iv_code 
         Section start address: 0x90000 [0x28240000]
         Section byte count: 0x300
         Process section: dxe_block0_data_prio1 
         Section start address: 0x90117 [0x2824045C]
         Section byte count: 0xA (0x8)
         Process section: dxe_block0_data_prio2 
         Section start address: 0x9047C [0x282411F0]
         Section byte count: 0x64 (0x50)
         Process section: dxe_block0_data_prio3 
         Section start address: 0x904B3 [0x282412CC]
         Section byte count: 0xA (0x8)
         Process section: dxe_block3_sw_code_prio0 
         Section start address: 0x1C0000 [0x28380000]
         Section byte count: 0x3BE
         Process section: dxe_block3_nw_code_prio0 
         Section start address: 0xE00A0 [0x283803C0]
         Section byte count: 0x6
         Process section: dxe_block3_sw_code_prio1 
         Section start address: 0x1C01E4 [0x283803C8]
         Section byte count: 0x1196
         Process section: dxe_block3_sw_code_prio2 
         Section start address: 0x1C0AB0 [0x28381560]
         Section byte count: 0xD16
         Process section: dxe_block3_sw_code_prio3 
         Section start address: 0x1C113E [0x2838227C]
         Section byte count: 0x148
        

        Process file: Core2.dxe
         Process section: dxe_block0_data_prio0_bw 
         Section start address: 0x2403F0 [0x2403F0]
         Section byte count: 0x68
         Process section: dxe_block0_data_prio1_bw 
         Section start address: 0x240468 [0x240468]
         Section byte count: 0xD84
         Process section: dxe_block0_data_prio2_bw 
         Section start address: 0x241240 [0x241240]
         Section byte count: 0x8C
         Process section: dxe_block0_data_prio3_bw 
         Section start address: 0x2412D4 [0x2412D4]
         Section byte count: 0x18
         Process section: dxe_iv_code 
         Section start address: 0x90000 [0x28A40000]
         Section byte count: 0x300
         Process section: dxe_block0_data_prio1 
         Section start address: 0x90117 [0x28A4045C]
         Section byte count: 0xA (0x8)
         Process section: dxe_block0_data_prio2 
         Section start address: 0x9047C [0x28A411F0]
         Section byte count: 0x64 (0x50)
         Process section: dxe_block0_data_prio3 
         Section start address: 0x904B3 [0x28A412CC]
         Section byte count: 0xA (0x8)
         Process section: dxe_block3_sw_code_prio0 
         Section start address: 0x1C0000 [0x28B80000]
         Section byte count: 0x3BE
         Process section: dxe_block3_nw_code_prio0 
         Section start address: 0xE00A0 [0x28B803C0]
         Section byte count: 0x6
         Process section: dxe_block3_sw_code_prio1 
         Section start address: 0x1C01E4 [0x28B803C8]
         Section byte count: 0x1196
         Process section: dxe_block3_sw_code_prio2 
         Section start address: 0x1C0AB0 [0x28B81560]
         Section byte count: 0xCE2
         Process section: dxe_block3_sw_code_prio3 
         Section start address: 0x1C1122 [0x28B82244]
         Section byte count: 0x148
        

        *** Summary of -NoFinalTag usage
        

        -NoFinalTag Core1.dxe was successful
        

        ----------
        

        As you can see I generate an "INCLUDE" file. When looking at the generated data some values puzzle me.
        Below you can see the initial 32 generated bytes. I marked the values I don't really understand with a '*'.
        

        0x03,
         0x50,
         0xAD,
         0xAC,
         0xB0,
         0x0A,
         0x1C,
         0x00,
         0x00,
         0x00,
         0x00,
         0x00,
         0xDC,
         0x28,
         0x00,
         0x00,
         0x03,
         0x00,
         0x38,
         0xAC,
         0xF0, *
         0x03, *
         0x24, *
         0x28, *
         0x68,
         0x00,
         0x00,
         0x00,
         0x00,
         0x00,
         0x00,
         0x00,
        ...
        ...
        

        Section 'dxe_block0_data_prio0_bw' (see elfloader output above) is destined for address 0x2403f0.
        But somehow it's translated to address 0x282403f0 (see marked bytes above).
        Could you please explain why this happens?
        

        Several other address are also translated (0x90000 ---> 0x28240000, 0x1c0000 ---> 0x28380000 etc) but these translations are indicated by the elfloader output.
        Still, I do not understand why this translation of addresses take place.
        

        Thank you!
        
			
        

		
			
	      

		
		
	
        
	
        
		
        
			
		
        
	
        
	
        
		
						
						
				
						
				
				
		
		
        
			
		
        
	
        

        

        • 

	
      



Reply

        


      • 
	
        



	
		
	
	



        
	
        
		
        
							
					
        
		
        
			
													0
							
			
				
									
							        
			
			
			
          
            
						
                            
            
            				
            
                on Feb 28, 2019 8:43 AM
            
            
												
						in reply to ADIApproved
					
									
          
	
          

		
		
          
					
          Hello Lalitha,
          

          Here's some further info on how I generate the loader stream.
          I'm calling the elfloader from command line using the following flags:
          

          elfloader -b SPISLAVE -bcode 3 -f INCLUDE -proc ADSP-21571 -verbose -Width 8 \
           -core1="Core1.dxe" \
           -core2="Core2.dxe" \
           -NoFinalTag="Core1.dxe" \
           -o ../Output.ldr
          

          The elfloader outputs the following message(s):
          

          *********************************************************************
           ADSP-21571 INPUT FILE(S) FOR BUILD
           CORE1 Core1.dxe
           CORE2 Core2.dxe
          *********************************************************************
          Process file: Core1.dxe
           Process section: dxe_block0_data_prio0_bw 
           Section start address: 0x2403F0 [0x2403F0]
           Section byte count: 0x68
           Process section: dxe_block0_data_prio1_bw 
           Section start address: 0x240468 [0x240468]
           Section byte count: 0xD84
           Process section: dxe_block0_data_prio2_bw 
           Section start address: 0x241240 [0x241240]
           Section byte count: 0x8C
           Process section: dxe_block0_data_prio3_bw 
           Section start address: 0x2412D4 [0x2412D4]
           Section byte count: 0x18
           Process section: dxe_iv_code 
           Section start address: 0x90000 [0x28240000]
           Section byte count: 0x300
           Process section: dxe_block0_data_prio1 
           Section start address: 0x90117 [0x2824045C]
           Section byte count: 0xA (0x8)
           Process section: dxe_block0_data_prio2 
           Section start address: 0x9047C [0x282411F0]
           Section byte count: 0x64 (0x50)
           Process section: dxe_block0_data_prio3 
           Section start address: 0x904B3 [0x282412CC]
           Section byte count: 0xA (0x8)
           Process section: dxe_block3_sw_code_prio0 
           Section start address: 0x1C0000 [0x28380000]
           Section byte count: 0x3BE
           Process section: dxe_block3_nw_code_prio0 
           Section start address: 0xE00A0 [0x283803C0]
           Section byte count: 0x6
           Process section: dxe_block3_sw_code_prio1 
           Section start address: 0x1C01E4 [0x283803C8]
           Section byte count: 0x1196
           Process section: dxe_block3_sw_code_prio2 
           Section start address: 0x1C0AB0 [0x28381560]
           Section byte count: 0xD16
           Process section: dxe_block3_sw_code_prio3 
           Section start address: 0x1C113E [0x2838227C]
           Section byte count: 0x148
          

          Process file: Core2.dxe
           Process section: dxe_block0_data_prio0_bw 
           Section start address: 0x2403F0 [0x2403F0]
           Section byte count: 0x68
           Process section: dxe_block0_data_prio1_bw 
           Section start address: 0x240468 [0x240468]
           Section byte count: 0xD84
           Process section: dxe_block0_data_prio2_bw 
           Section start address: 0x241240 [0x241240]
           Section byte count: 0x8C
           Process section: dxe_block0_data_prio3_bw 
           Section start address: 0x2412D4 [0x2412D4]
           Section byte count: 0x18
           Process section: dxe_iv_code 
           Section start address: 0x90000 [0x28A40000]
           Section byte count: 0x300
           Process section: dxe_block0_data_prio1 
           Section start address: 0x90117 [0x28A4045C]
           Section byte count: 0xA (0x8)
           Process section: dxe_block0_data_prio2 
           Section start address: 0x9047C [0x28A411F0]
           Section byte count: 0x64 (0x50)
           Process section: dxe_block0_data_prio3 
           Section start address: 0x904B3 [0x28A412CC]
           Section byte count: 0xA (0x8)
           Process section: dxe_block3_sw_code_prio0 
           Section start address: 0x1C0000 [0x28B80000]
           Section byte count: 0x3BE
           Process section: dxe_block3_nw_code_prio0 
           Section start address: 0xE00A0 [0x28B803C0]
           Section byte count: 0x6
           Process section: dxe_block3_sw_code_prio1 
           Section start address: 0x1C01E4 [0x28B803C8]
           Section byte count: 0x1196
           Process section: dxe_block3_sw_code_prio2 
           Section start address: 0x1C0AB0 [0x28B81560]
           Section byte count: 0xCE2
           Process section: dxe_block3_sw_code_prio3 
           Section start address: 0x1C1122 [0x28B82244]
           Section byte count: 0x148
          

          *** Summary of -NoFinalTag usage
          

          -NoFinalTag Core1.dxe was successful
          

          ----------
          

          As you can see I generate an "INCLUDE" file. When looking at the generated data some values puzzle me.
          Below you can see the initial 32 generated bytes. I marked the values I don't really understand with a '*'.
          

          0x03,
           0x50,
           0xAD,
           0xAC,
           0xB0,
           0x0A,
           0x1C,
           0x00,
           0x00,
           0x00,
           0x00,
           0x00,
           0xDC,
           0x28,
           0x00,
           0x00,
           0x03,
           0x00,
           0x38,
           0xAC,
           0xF0, *
           0x03, *
           0x24, *
           0x28, *
           0x68,
           0x00,
           0x00,
           0x00,
           0x00,
           0x00,
           0x00,
           0x00,
          ...
          ...
          

          Section 'dxe_block0_data_prio0_bw' (see elfloader output above) is destined for address 0x2403f0.
          But somehow it's translated to address 0x282403f0 (see marked bytes above).
          Could you please explain why this happens?
          

          Several other address are also translated (0x90000 ---> 0x28240000, 0x1c0000 ---> 0x28380000 etc) but these translations are indicated by the elfloader output.
          Still, I do not understand why this translation of addresses take place.
          

          Thank you!
          
			
          

		
			
	      

		
		
	
          
	
          
		
          
			
		
          
	
          
	
          
		
						
						
				
						
				
				
		
		
          
			
		
          
	
          

          

          • 


        


Children
	
        No Data