Bad batch of RCM3200 module (bearing white mark of T14)?

Rabbit
, ,
1

We have been using RCM3200 module in our product for 15 years.

Recently we received a batch of RCM3200 modules from Arrows, and they are having communication problem, many broken/missing packets according to Wireshark captures. The module is used “as is” without any modification, and the same firmware has been working flawlessly in the past 15 years.

Comparing them with old ones, I noticed:

This batch all have a white mark of T14 and T4? on the Rabbit micro and they uses AX88796A Ethernet controller (I used up my previous batch so I have no idea what my previous batch uses, but a test module from old days uses AX88796 instead of AX88796A)

Maybe a bad batch of RCM3200 somehow got shipped to your distributor?

Regards,

Xun Chen

1 Like
2

Xun Chen,

If you are requesting what is called an RMA, then you need to either contact your place of purchase or Digi Support via the web site or via email at technical.support@digi.com
https://www.digi.com/support

3

Does the latest RCM3200 module use AX88796 or AX88796A?

4

To answer your question it uses both. The part AX88796 is obsolete, this is the new replacement AX88796A. You should’ve received a PCN informing of a change in power consumption.

5

Please contact tech support for an RMA

6

I have had a similar problem with a batch of RCM3200’s that I received from my local supplier.

They were delivered with AX88786ALF Ethernet chips.

These chips advertise 100/10meg Half and Full duplex to any switch that they are connected to but create packets with CRC errors on the network.

Symptoms are intermittent pings and sometimes the port is even disabled by smart switches.

a Workaround is to configure the switch port to 10meg Half duplex.

Another workaround is to change the ASIX.LIB library to force the Rabbit RCM3200 (AX88796ALF chip) to only advertise 10Meg Half Duplex speed.

I use Dynamic C 9.62.

In Asix.lib, in the "asix_internal_func int pd_setup_RCM3200CORE(_ASIXConfig *rt); " function at the bottom of the function just before the “pop ix” command:

insert the following code:

// Default for phy register MR4 is 0x01E1 = Advertize 100FD,100HD,10FD,10HD
// bit8 = 100FD, Bit 7 = 100meg, Bit 6 = 10FD, Bit 5 = 10meg
// bit 0 must always be 1

  ; Check if MR3 is 0x1821 - ASIX 88796ALF
ld		hl,0x0003
  push	hl
  ld		hl,0x0010
  push	hl
  push	ix
  asix_internal_call(asix_readphy)
  add	sp,6
	or		a		; Clear carry flag
	ld		de,0x1821
  sbc	hl,de
	jr		nz,.skip_10M_HD

 // Now set 10Meg Half Duplex mode
 ;ld      hl,0x01E1        // 100/10 Meg Half or Full Duplex. (Default)
 ld      hl,0x0021        // 10Meg Half Duplex
 push    hl
 ld      hl,4                // reg 4
 push    hl
 ld      hl,0x10            // internal phy
 push    hl
 push    ix                // Asix config pointer
 asix_internal_call(asix_writephy)
 add    sp,8

 // Force a link speed re-negotiation
 ;ld      hl,0x3000        //  (Default)
 ld      hl,0x3200        // Force re-Negotiation
 push    hl
 ld      hl,0                // reg 0
 push    hl
 ld      hl,0x10            // internal phy
 push    hl
 push    ix                // Asix config pointer
 asix_internal_call(asix_writephy)
 add    sp,8

.skip_10M_HD:

1 Like
7

Thanks

In our case, Digi took all RCM3200 back, and we changed to RCM3209.

8

Digi has started manufacturing RCM3200 modules with the original LF chip (I’m not sure of the revision number) and at some point expects to ship modules with a modified board layout that works with the ALF chip (which was susceptible to noise that distorted the transmit signal).