Products Mentioned

ADIN6310 Recommended for New Designs
The ADIN3310 and ADIN6310 are 3-port and 6-port Gigabit Ethernet time sensitive networking (TSN) switches with integrated security primarily designed for...
Datasheet
ADIN6310 on Analog.com

Associated Drivers

Thread Details

  • State Verified Answer
  • Replies 7 replies
  • Subscribers 3 subscribers
  • Views 428 views
  • Users 0 members are here 

        

            Post
             Go back to editing
        

    

    


    

    









		


















	
	
			
	
			
		
	
	
		

	    
	    
	    		
First firmware download issue on blank components

		
	
				

			

									
					    PhilippeThirion
					
							

            
            			
				
									
											
			
			
				
			
			
			    	
			                    
                
				                on Aug 19, 2026 
				
			
			
		

		
		                    	    

        	    
Thread Summary

                The user experienced issues initializing four cascaded ADIN6310 devices with firmware loading, requiring multiple restarts. The solution involved increasing SES_NACK_RETRY_LIMIT from 5 to 10 and RPC_MAX_RESPONSES from 8 to 16 in the 5.1.0 API. The problem did not occur with already loaded firmware or with API 6.0.1.
                        	    

                
                     AI Generated Content
                
    	    

             
				
        		

		    
		    		    

		      		            		        
Category: Software

    		        		            		    
Product Number:  ADIN6310  

    		        		        		        
Software Version: adinx310_tsn_driver_library_rel5.1.0-ga

    		    		    

		    		    
		    			

			    
Hello,


I 'm developing software to test the hardware on the PCB manufacturer.


Our design contains four ADIN6310 linked in cascade.


I meet issues with new boards (adin6310 have not yet firmware loaded)  during the first time firmware loading.


I need to restart the hardware test several time to achieve firmware loading of the four ADIN6310 => It 's not acceptable for hardware test.


I do tests changing API version between 5.1.0 and 6.0.1 and back several time to force the reloading of the firmware but the behavior is not the same I notice with blank component (no firmware loading issue)


Question:


Is it possible to (re)blank ADIN6310 component to continue my investigation ?


The issue seems solve with API 6.0.1 but the project team would like to keep API 5.1.0.


Best Regards,


Philippe THIRION





			

			
									
		                             
                        

    

                                            
                 software
                
                                                    
                 firmware
                
                                                    
                 Interface Transceivers & Isolators
                
                                                    
                 adinx310_tsn_driver_library_rel5.1.0-ga
                
                                                    
                 ADIN6310
                
                                        
                                            
                
                
                                
                    Show More
            

    
    
		


				
				        
        		

			
						
									
												
			
			
                        
                                    
                        
                        
                        
            
			            
						
						
			
			
			
			
		


        
        
        
    
					

			





















	

	

					



			


				
	









	
    
	

  • 
	
    



	
		
	
	



    
	
    
		
    
							
					
    
		
    
		    
		    		    
			
				
									
							        
			
			
			
    •  Analog Employees  
    
            
						
                            
            
            				
            
                on Aug 19, 2026 11:22 AM
            
            
						
			            		
    
		
										0
					
	
    

		
		
    
		
    
                                
                                                            
    
					
    Hi Philippe,
    

    Thanks for message and sorry to hear you are having trouble with firmware load with new devices.
    

    If you want to erase the firmware so the device looks like a new device, then you can do this as follows: 
    

    Once you have the device initialized, calling the SES_ImageLoader API triggers a complete firmware reload sequence. As part of this process, the device firmware is erased before the new firmware image is requested and programmed. The firmware erase phase corresponds to the following state: SMP_FLASH_ERASE_SUCCESS
    

    This state is defined in the SES_firmware_update_control source code, within the HandleProgrammingMessage function. If the firmware update process is exited or halted while the system is in this state, the existing firmware will have already been erased. Once the firmware has been successfully erased, the switch begins issuing image request messages. For an Ethernet host, these requests are sent over Ethernet. For a SPI host, the requests are indicated through TIMER0/INT interrupts. 
    

    Sounds like the issue you have is specifically related to initial load with 5.1.0-GA only? 
    

    I believe you are using SPI interface to the switch. There were many improvements in the SPI implementation between 5.1 and 6.0.1 release to make the interface more robust and performant when sending/receiving data frames to/from host over the SPI interface. If possible, I would suggest transitioning to 6.0.1 if possible 
    

    If 5.1.0-GA is required, can you please experiment with increasing the SES_PORT_REBOOT_TIMEOUT from 350 to 370 and see if any improvement?
    

    Hope this helps, let us know if you continue to have issues. 
    

    Best regards,
    

    Catherine. 
    
			
    

		
			
	      

		
		
	
    
	
    
		
    
			
		
    
	
    
	
    
		
						
						
				
						
				
				
		
		
    
			
		
    
	
    

    

    • 

	

  • 
	
    



	
		
	
	



    
	
    
		
    
							
					
    
		
    
		    
		    		    
			
				
									
							        
			
			
			
            
						
                            
            
            				
            
                on Aug 31, 2026 8:40 AM
            
            
												
						in reply to CatherineR
					
										
			            		
    
		
										0
					
	
    

		
		
    
		
    
                                
                                                            
    
					
    

    Hi Catherine,
    

    Thank you for your answer.
    

    I am experiencing an issue with boards containing a "blank" ADIN6310 (right after manufacturing).
    

    The last ADIN6310 devices in the cascaded structure are not initialized properly on the first attempt, resulting in an AddDevice error. I need to restart the application several times before all ADIN6310 devices are initialized successfully.
    

    For debugging purposes, I alternated between API versions 6.0.1 and 5.1.0, but I have not been able to reproduce the same behavior observed with blank ADIN6310 devices.
    

    Do you have any explanation for this behavior or any suggestions on what could be causing it?
    

    Best regards,
    

    Philippe THIRION
    

    

    
			
    

		
			
	      

		
		
	
    
	
    
		
    
			
		
    
	
    
	
    
		
						
						
				
						
				
				
		
		
    
			
		
    
	
    

    

    • 

	

  • 
	
    



	
		
	
	



    
	
    
		
    
							
					
    
		
    
		    
		    		    
			
				
									
							        
			
			
			
    •  Analog Employees  
    
            
						
                            
            
            				
            
                on Sep 4, 2026 8:56 AM
            
            
						
			            		
    
		
										0
					
	
    

		
		
    
		
    
                                
                                                            
    
					
    Hi Philippe,
    

    Would it be possible to get a Wireshark capture or a tcpdump from the host so we can review the communication between the host and the ADIN6310 devices?
    

    This would help verify at what point the AddDevice error occurs and better understand what is happening during the firmware update.
    

    Regards,
    

    Karl
    
			
    

		
			
	      

		
		
	
    
	
    
		
    
			
		
    
	
    
	
    
		
						
						
				
						
				
				
		
		
    
			
		
    
	
    

    

    • 

	

  • 
	
    



	
			
		
	



    
	
    
		
    
							
					
    
		
    
		    
		    		    
			
				
									
							        
			
			
			
            
						
                            
            
            				
            
                on Sep 8, 2026 9:09 AM
            
            
												
						in reply to Karl.O
					
										
			            		
    
		
										0
					
	
    

		
		
    
		
    
                                
                                                            
    
					
    Hello,
    

    I finally succeed to solve the blank adin6310 component (cascaded X4) initialization issue.
    

    I have to modify the 5.1.0 API:
    

    1) Change SES_NACK_RETRY_LIMIT  from 5 to 10
    

    SES_firmware_update_control.c:
    #define SES_NACK_RETRY_LIMIT  (10)
    

    In the trace below , you will see that the NACK retries (instanceParam_p->nackRetryCount)  sometime reaches the value of 6 ( >5)
    

    => The value of 5 is too small !
    

    2) Change RPC_MAX_RESPONSES  from 8 to 16 
    

    RPC_client_process.c
    #define RPC_MAX_RESPONSES             (16)
    

    See trace 2 for the last switch : Unable to establish communication on default MAC after programming (-1)
    

    and SES_MX_GetInterfaces -3 before
    

    GetRemoteSesInterfaces calls SES_MX_GetInterfaces
    

    SES_MX_GetInterfaces calls RPC_ResponseDataStoreFindFirstFree primitive to fetch a descriptor
    

    static RPC_responseDataDescriptor_t responseDataStore_g[RPC_MAX_RESPONSES] = {0};
    

    Only 8 (RPC_MAX_RESPONSES) RPC_responseDataDescriptor_t slots are available.
    

    When all the 8 descriptors are used, RPC_ResponseDataStoreFindFirstFree  return a RPC_MEMORY_ERROR (-3)
    

    SES_MX_GetInterfaces return -3 and GetRemoteSesInterfaces return SES_ERROR (SES_ROUTE_api.c )
    

    and display the trace "Unable to establish communication on default MAC after programming (-1)"
    

    => The number of descriptors (8) is too small
    

    Trace:
    

    [355645.465334] device eth1 entered promiscuous mode
    DEBUG: SES_AddDevice
    [355645.984563] mv88e6085 42890000.ethernet-1:00 lan1: Link is Down
    [355646.811603] bond0: (slave lan1): link status definitely down, disabling slave
    [355646.811659] bond0: now running without any active interface!
    [355649.061812] mv88e6085 42890000.ethernet-1:00 lan1: Link is Up - 1Gbps/Full - flow control off
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 1
    [355649.883571] bond0: (slave lan1): link status definitely up, 1000 Mbps full duplex
    [355649.883600] bond0: (slave lan1): making interface the new active one
    [355649.883697] bond0: active interface up!
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 2
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 3
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 4
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:867] SMP_FLASH_ERASE_SUCCESS 0
    DEBUG: Version: 005 Build: 329
    DEBUG: SES_MX_InitializePorts
    DEBUG: switch1 initialization is done.
    [355683.315597] mv88e6085 42890000.ethernet-1:00 port0: Link is Down
    [355683.327568] mv88e6085 42890000.ethernet-1:00 port0: Link is Up - 1Gbps/Full - flow control off
    DEBUG: SES_AddDevice
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 1
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 2
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 3
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 4
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 5
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 6
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:867] SMP_FLASH_ERASE_SUCCESS 1
    DEBUG: Version: 005 Build: 329
    DEBUG: SES_MX_InitializePorts
    DEBUG: switch2 initialization is done.
    DEBUG: SES_AddDevice
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 1
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 2
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 3
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 4
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 5
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 6
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:867] SMP_FLASH_ERASE_SUCCESS 2
    DEBUG: Version: 005 Build: 329
    DEBUG: SES_MX_InitializePorts
    DEBUG: switch3 initialization is done.
    DEBUG: SES_AddDevice
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 1
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 2
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 3
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 4
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 5
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 6
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:867] SMP_FLASH_ERASE_SUCCESS 3
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-route-srv/src/SES_ROUTE_api.c:1114] ERROR: Unable to establish communication on default MAC after programming (-1)
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-route-srv/src/SES_ROUTE_api.c:294] ERROR: Failed to set MAC and check firmware
    

    

    

    Trace 2:
    


    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-route-srv/src/SES_ROUTE_api.c:928] ERROR: SES_MX_GetInterfaces -5
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-route-srv/src/SES_ROUTE_api.c:928] ERROR: SES_MX_GetInterfaces -5
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 1
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 2
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 3
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 4
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:732] NACK retry 5
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-tsn-api-srv/src/SES_firmware_update_control.c:867] SMP_FLASH_ERASE_SUCCESS 3
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-route-srv/src/SES_ROUTE_api.c:928] ERROR: SES_MX_GetInterfaces -3
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-route-srv/src/SES_ROUTE_api.c:1115] ERROR: Unable to establish communication on default MAC after programming (-1)
    [/users/thirion2/hg/spe16-app/driver-ad/ale/src/ses-route-srv/src/SES_ROUTE_api.c:294] ERROR: Failed to set MAC and check firmware
    

    

    Best Regards,
    

    Philippe THIRION
    
			
    

		
			
	      

		
		
	
    
	
    
		
    
			
		
    
	
    
	
    
		
						
						
						
						
				
				
		
		
    
			
		
    
	
    

    

    • 

	

  • 
	
    



	
		
	
	



    
	
    
		
    
							
					
    
		
    
		    
		    		    
			
				
									
							        
			
			
			
    •  Analog Employees  
    
            
						
                            
            
            				
            
                on Sep 9, 2026 2:34 AM
            
            
						
			            		
    
		
										0
					
	
    

		
		
    
		
    
                                
                                                            
    
					
    Hi Philippe,
    

    It's great that you were able to initialize your board.
    

    Did you also try increasing SES_PORT_REBOOT_TIMEOUT from 350ms to 370ms?
    

    In v6.0.1, this macro was increased to 370ms.
    

    Additionally, the RPC_MAX_RESPONSES is consumed when the host device sends a request and does not receive a response.
    

    SES_PORT_HandleTimeout can be called out periodically to clear expired response buffers.
    

    Regards,
    

    Karl
    
			
    

		
			
	      

		
		
	
    
	
    
		
    
			
		
    
	
    
	
    
		
						
						
				
						
				
				
		
		
    
			
		
    
	
    

    

    • 

	

  • 
	
    



	
		
	
	



    
	
    
		
    
							
					
    
		
    
		    
		    		    
			
				
									
							        
			
			
			
            
						
                            
            
            				
            
                on Sep 9, 2026 5:33 AM
            
            
												
						in reply to Karl.O
					
										
			            		
    
		
										0
					
	
    

		
		
    
		
    
                                
                                                            
    
					
    Hi Karl,
    

    Yes I have increased also the SES_PORT_REBOOT_TIMEOUT to 1000. But this is not enough to solve the issue. 
    

    The problem of the overflow of descriptor response buffer occurs only with a board with "blank" adin6310. Not when a firmware is already loaded in the adin6310 (during an down/upgrade or not).
    

    Do you have tested initialization of cascaded adin6310 chips of a depth of 4  or more. (specification says 10 max) ?
    

    Note that we use ethernet driver and not the SPI driver.
    

    HOST (API)  => SWITCH1 => SWITCH2 => SWITCH3 => SWITCH4
    

    

    Best Regards,
    

    Philippe
    
			
    

		
			
	      

		
		
	
    
	
    
		
    
			
		
    
	
    
	
    
		
						
						
				
						
				
				
		
		
    
			
		
    
	
    

    

    • 

	

  • 
	
    



	
		
	
	



    
	
    
		
    
							
					
    
		
    
		    
		    		    
			
				
									
							        
			
			
			
    •  Analog Employees  
    
            
						
                            
            
            				
            
                on Sep 15, 2026 2:34 AM
            
            
						
			            		
    
		
										0
					
	
    

		
		
    
		
    
                                
                                                            
    
					
    Hi Philippe,
    

    Yes, initialization has been tested with multiple cascaded board.
    

    We are also reviewing the existing test coverage for potential improvements.
    

    Regards,
    

    Karl
    
			
    

		
			
	      

		
		
	
    
	
    
		
    
			
		
    
	
    
	
    
		
						
						
				
						
				
				
		
		
    
			
		
    
	
    

    

    • 

	





	
			








		

		

			
    
				
  • 
					
												
						
						
						
						
						
						
						

																										
						
						

					
					
					
				
    • 
			

		

	








































     



















		        
        

            
Before You Switch

            
        

        

        

            Switching languages will make ADI Explorer unavailable. Resume your session by switching back to English and reopening ADI Explorer.