I am using an Arria II GX with an 88E1111 PHY setup in RGMII mode. When I try to do this manually by writing to this register it doesn't work. I tried using the tse_mac_SwReset() API function which appeared to work until I realized after the timeout it restores the original contents of the command config register. When I disable this restore instruction, bit13 SW_RESET is stuck high after calling tse_mac_SwReset() API function.
What is very weird is if I use the Eclipse Debugger and tell it to do address renderings my software works and bit 13 gets cleared. If I don't do the address rendering in the Eclipse debugger, the software doesn't work and bit 13 is read back as a 1 even after some delay of the software reset. I should also note that all data cache has been disabled and we are using IOWR and IORD to access the MAC address apace.
Any help would be appreciated.
Below scenario may affect sw_reset operation as per TSE user guide doc.
You can checkout TSE user guide (page 53, figure 18) to learn about some of operation that may interrupt SW_RESET that you need to watchout
Anyway, you can always rely on TSE IP hardware reset if software reset is not reliable. Hardware reset is the superset of software reset that will reset everything in TSE IP.
Thanks for additional feedback but can you use back forum community for future issue update ?
The only explanation that I can think off is stepping through Eclipse debugger gives more time for certain function task execution to complete before proceed to next task.
Based on my earlier feedback, sw_reset got stuck is typically caused by some other operation is interrupting the reset sequence as explained in TSE user guide doc.
I presume your design flow is as below.
Also, does it work better if you don't use the API and perform access control to command_config register directly ?