Problems and Solutions

i.MX 6Solox SabreSD platform:

As per U-boot, IOMUX is configured, PHY is configured with Tx/Rx delay and Eth also is as per old driver. But, Transmit was Ok. Receive is just happening two times with 0x40 packet and 0x5F0 packet. The 0x5F0 varies based on the RXBUFLEN value configured in the RX buffer Size Register value.

Solution was the Rx Buffer Size register needs to be configured as 0x600. I do not know what is the reason behind it. But, when U-boot is just stopped in the middle of DHCP command to see the Ethernet values using i-jet debugger (Attach to Running Target).

DMA completes transfer of Data, but packet is not coming out
In i.MX 6SoloX, the MUX Input was not enabled for the Reference clock. Once enabled, it started receiving. After enable Tx delay in PHY, transmission also was Ok.

ENET1 was working, but ENET2 was not working in vein

Everything (all MUX looking at Linux dts file), I did as same as ENET1 except the following:
    sfr_outl(ENET2_RX_CLK_INPUT, 1);        /* DAISY=1 (pad ENET_MDIO for ENET_MDIO) */
Once I did, it started working.

RT1060 Sample proting: Cortex-M7, when just running the scheduler, execution just to unknown:
Stack No issue, Cache is disabled... But, needed to disable 3 Watchdog Timers.

UART Wrong clock
All clocks except the 480clk needed for UART was missing. (Reverse engineering 80MHz*6)

i.MX RT1060: When Data is placed in OCRAM and Cache Enabled, Exception

When Data is placed in OCRAM, Vector table is copied to OCRAM in intini() once after Cache is enabled. And, later the drivers updates the Vector table with its own ISR handler addresses. The both Vector table including the SVC handler addresses and other interrupt handler addresses are just cached and seems not to be updated in physical OCRAM. So, whenever some interrupt occurs or SVC instruction is executed in sysini(), the exception is thrown. (Look at the point where exception is thrown, mainly SVC or other interrupts. It will give clue for fast debugging)
But, since SDRAM is Write-through by default, this problem does not occur when data is placed and the vector table is copied there.
Also, when the exception is traced and the saved LR itself 0xfffffffd, that means exception is thrown on SVC not getting proper handler address.

Prefetch Abort, once MMU is enabled
Old TLB might be used. Make sure that TLB is invalidated before enabling the MMU.

Exception occurs after cache is invalidated
Invalidating entire cache when it is enabled is like you tear your passport while you are using it in abroad. Your stack and other data using currently and recorded in cache itself will be invalidated and you can not even return from where you are.
So, when cache is enabled, use clean and invalidate instruction instead of just invalidate. Similarly, do not clean and invalidate when cache is disabled. Wrong data might overwrite your valid data. Just invalidate when cache is not enabled in your program.

Exception While Running. Does not arise when single stepping

ent_int/ret_int() was missing in LPC54608. Usually, these are default cases for NORTi when exception was caused.

1. Stack Overflow: Increase task stack size and interrupt stack size
2. Interrupt Handler: Assembly code is not as per NORTi expectation. Optimization level may be causing this. Or, user has dumped all the code in the interrupt handler, not as per NORTi's 3 statement interrupt handler. Or, ent_int/ret_int() has not been added in the interrupt handler.

Execution Jumps to blank location (all zeros memory region, etc)

Execution jumps to blank location and even the Link Register is Zero or invalid address. So, no clue or not able to trace exactly what happened.

It may be the cause of LR register content is corrupted or not restored properly. So, when some function returns with "bx lr", the execution jumps to invalid location. Also, the LR register stays with the same invalid branch address. Here, the debug tip is, to Keep breakpoint in the address which LR register holds. Suppose, if LR is 0, then keep breakpoint at 0th address. The execution jumps to that address from a valid function call. So, you can find the function from where the corruption happened.

Ethernet Connector Does not Lit On

At board Power-On-Reset, the Ethernet Connectors should glow on even before program start-up just by connecting the cable with Hubs. If it does not, that meant the PHY is held in Reset by GPIO pins. Find the GPIO pin that is connected to the PHY Reset, configure it as GPIO in your program and make it Low or High with GPIO data register.

iTRON does not return from dly_tsk()

When testing with highest optimization level -O3 and with NEON enabled kernel library, the TCP test sample program does not return from dly_tsk() called in PHY driver. But, the other sample program works fine.

It is because, with high optimization level and NEON enabled, the stack consumption is very high. So, just increasing the stack size of Tasks is not enough. But, the stack size of idle task (timer handlers) too and interrupt handlers too. In the other sample, these sizes were defined with large size by default. So, that was running. With TCP test case, they were not defined and in idle task the global variable SDISP was not at all reset, since the address that were stored in stack was wrongly referenced because of stack corruption. Because of that, the task was not dispatched even though it is in ready queue.

Ping is inconsistent. Losing response packets

Ping command from host gets some responses, but loses other response packets. Mostly, the PHY configuration is insufficient. Check the Board patch for any specific settings. Clock or Delay settings or LED settings. In RZ/N1D switch, normal GMAC was working fine. But, with the switch, ping was missing packets. The PHY LED[0] needs to be configured for Link. 

Debugging MUX, Clock or Other settings

1) Find U-Boot patch. Just go through all the code once to learn about board specific settings.

2) Just copy the register settings when U-Boot was working, make a array[] of values and just overwrite the settings in RTOS.