This week I dig deeper into identifying the TCPIP Stack bug.
Ideal Case
Based on the document UG380 and XAPP502, ‘init_b’ of FPGA should be HIGH (reading from PIC32), if it was LOW during configuration means there is an error, ‘init_b’ can also be pulled LOW to delay configuration, in other words ‘init_b’ is a multipurpose pin for FPGA. Even after configuration ‘init_b’ will still remain HIGH.
Experiment Result
Therefore at the start of my state machine (PIC32), by enabling RD0 (the pin reading ‘init_b’ of FPGA) internally pull_up, I could ensure that ‘init_b’ is normally HIGH. However the problems happen when TCPIP stack was initialize.
By debugging step-by-step, to pin point the problem. Since these initialization was auto generated from Harmony, from ‘system_init.c’ when the program run before ‘TCPIP_STACK_Initialize’, ‘init_b’ will still read as HIGH and immediately LOW when ever the program run pass ‘TCPIP_STACK_Initialize()’. I double confirm this behaviour by purposely initialize the stack and deinitalize the stack with ‘TCPIP_STACK_Deinitialize()’, resulting ‘init_b’ going back HIGH.
So great, I have confirm this stack initialization is really fuck up. So I dig deeper to study every single ‘possible’ cause of pulling down RD0. However, I just could not come into understanding of any weird port used. For this TCPIP Stack only initialize stuff like DHCP, TCP, UDP, and other TCPIP related stuff, so how it could possible cause RD0 pulled LOW?
Since I could not solve this bug, I have no other option but to bypass it with deinitializing tcpip stack and reinitialize the stack. The reason of MUST having ‘init_b’ goes HIGH is so that I could pull ‘program_b’ LOW longer resulting ‘init_b’ LOW to clear the memory of FPGA whenever I want. In other words, able to do multiple reconfiguration without powering down the board.
0 Comments