WinEC7 - full LAN (FEC) driver disrupts SDHC driver operation if started after SDHC driver

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

WinEC7 - full LAN (FEC) driver disrupts SDHC driver operation if started after SDHC driver

Jump to solution
1,370 Views
AlexeyT
Contributor III

Hello All,

I think found another issue with SDHC driver in WinEC7 BSP.

It looks like SDHC driver conflicts with FEC (LAN) driver.

The situation is as follow:

- if SDHC driver starts after FEC driver everything seems to be ok

- if FEC driver starts after SDHC it kills SDHC driver.

It was found during my attempt to register FEC driver on the fly using NDIS register IOCTL.

CE image starts without FEC driver being registered/active.

After FEC registration any subsequent SDHC access attempt fails.

Most likely this problem causes issues with persistent registry on SD card.

I tried implementing it but SDHC stops working after the registry is read from card and used.

Funny thing but persistent registry worked ok when CE was being debugged over LAN by using platform builder

but completely failed when debugger is not used.

I think it happens because when PB uses LAN to debug CE kernel so it effectively bans normal LAN driver and uses

KITL version of it instead.

So I added 2 and 2 and my conclusion is:

Full LAN (FEC) driver disrupts SDHC driver operation if started after SDHC driver.

Has someone seen this issue?

It would be great to hear something from support team as well.

Best regards,

Alexey

PS I will post my finding/fixes if I manage to fix it.

Labels (1)
Tags (1)
1 Solution
928 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

There is a code issue in file "platform\imx53_smd\src\inc\bsp_cfg.h", the macro

#define BSP_ETH_RST_IOMUX_PIN   DDK_IOMUX_PAD_PATA_DA_0

should be

#define BSP_ETH_RST_IOMUX_PIN   DDK_IOMUX_PIN_PATA_DA_0

The original code had set wrong IOMUX register for Ethernet reset pin, that pin is SD1_DATA1, so after fec driver runs, the sdhc1 driver will fail to work.

DDK_IOMUX_PAD_PATA_DA_0 = 178 = DDK_IOMUX_PIN_SD1_DATA1

View solution in original post

0 Kudos
5 Replies
928 Views
AlexeyT
Contributor III

Hello again,

Problem is identified.

It seems that SDHC3 conflict with FEC transceiver reset line.

Pin 6 of GPIO7 can be configured as one of the SDHC3 lines or it can be used as

GPIO output pin connected to FEC transceiver reset line.

It looks like IT WAS connected to FEC reset some time ago but not any more (at least for iMX53 Sabre board).

On Sabre it is used for SDHC3 but in the code (surprise!) it was forgotten.

It is interesting that is was fixed in function OALKitlFECBSPInit which has #ifdef BSP_ETH_USE_HW_RST conditional code and that define is not in defined state.

But in BSPFECIomuxConfig function it was forgotten and it still tries to reconfigure GPIO7_6 for FEC reset causing SDHC3 to fail.

The problem is that

- if it is configured for GPIO out, it causes SDHC3 to fail

- if it is configured for SDHC3, it causes LAN to fail

Can we have SDHC3 and LAN devices working together correctly?

Freescale support team, could you please have a look at it?

Best regards,

Alexey

0 Kudos
928 Views
AlexeyT
Contributor III

Update on the issue.

I was a bit wrong but there still a conflict.

If mux mode of that pin is ALT1 (GPIO&_6), SDHC fails wo work.

If mux mode is ALT0 (DA_0), SDHC work ok but LAN fails to work.

This occures on Sabre iMX53 prototype board so it can be easily reproduced by support.

The workaround:

Change BSPFECIomuxConfig to :

BOOL BSPFECIomuxConfig( IN BOOL Enable )

{

    DDK_IOMUX_PIN_MUXMODE        savedRstMuxmode;

    DDK_IOMUX_PIN_SION                 savedRstSion;

    DEBUGMSG(ZONE_FUNCTION, (TEXT("FEC: +BSPFECIomuxConfig\r\n")));

  

    if(Enable)

    {

          // Save MUX mode

          DDKIomuxGetPinMux(BSP_ETH_RST_IOMUX_PIN, &savedRstMuxmode,&savedRstSion);

         

          // Here goes original MUX configuration code

        // Restore MUX mode back

        DDKIomuxSetPinMux(BSP_ETH_RST_IOMUX_PIN, savedRstMuxmode,savedRstSion);


     }

     return TRUE;

}

LAN driver only use reset once so it is acceptable solution.

Please note that for a fraction of time SDHC will be unavailable.

This workarond can help with 'persistent registry on SD card' issue if your design includes FEC LAN.

Think registry issue is caused by SDHC driver instantiated BEFORE LAN driver so original LAN configuration code changes

mux mode of pin to GPIO7_6 to ALT1 and caused SDHC driver to fail.

Hope it helps.

Best regards,

Alexey

0 Kudos
929 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

There is a code issue in file "platform\imx53_smd\src\inc\bsp_cfg.h", the macro

#define BSP_ETH_RST_IOMUX_PIN   DDK_IOMUX_PAD_PATA_DA_0

should be

#define BSP_ETH_RST_IOMUX_PIN   DDK_IOMUX_PIN_PATA_DA_0

The original code had set wrong IOMUX register for Ethernet reset pin, that pin is SD1_DATA1, so after fec driver runs, the sdhc1 driver will fail to work.

DDK_IOMUX_PAD_PATA_DA_0 = 178 = DDK_IOMUX_PIN_SD1_DATA1

0 Kudos
928 Views
AlexeyT
Contributor III

Thank you very much for answer.

I checked other BSP's and found following :

In EVK code it use different pin but still has the same issue: pad instead of pin
#define BSP_ETH_RST_IOMUX_PIN   DDK_IOMUX_PAD_KEY_COL3

AFAIK it should be #define BSP_ETH_RST_IOMUX_PIN   DDK_IOMUX_PIN_KEY_COL3

ARD code has the same issue as SMD

Could you please check other BSP code as well?

Best regards,

Alexey

0 Kudos
928 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

Yes, all of them are wrong, the "BSP_ETH_RST_IOMUX_PIN" should use DDK_IOMUX_PIN_xxx, not DDK_IOMUX_PAD_xxx.

0 Kudos