Ethernet with MK60DN512ZVMC10

[mhier]

I have to write new firmware for an old device. The device is based on the MK60DN512ZVMC10 (note the Z) and uses an Ethernet connection to communication with a control system. The existing firmware is based on MQX and some unknown version of the Kinetis SDK and is in quite a messy state. Hence it was decided to rewrite the firmware based on FreeRTOS and the LWIP stack (and to use the open62541 stack to replace our broken custom network protocol).

I downloaded the MCUXpresso SDK with FreeRTOS and LWIP and used the Config Tools to setup pins, clocks and peripherials. After realising the differences between MK60DN512ZVMC10 and MK60DN512VMC10 (NXP should really point this out clearly on the product page!), I found out that I have to comment a few lines which use MCG->C7 so that the clock configuration works (it tries to configure a switch which is not there and hence runs into a hard fault - the commented lines merely put the switch into the position which is the hardcoded signal flow in my MCU). Now the code compiles and runs, and I see output on the serial console.

Next part is to get Ethernet working. I managed to communicate with the PHY by using fsl_phy.c/h from one of the examples and modifying it slightly (our PHY somehow seems to report the auto-negotiation result differently). I see it reports a link with the proper parameters (100M full-duplex), and this matches what the other side sees.

From this point I do not get any further. I do not manage to convince the Ethernet controller to send or receive any packages. I have tried many things. To boil down the problem, I have switched to the enet_txrx_transfer example and modified it for my board. I again see serial output and the PHY is working, but nothing gets transmitted or received through Ethernet. The example seems to fill up the buffers and prints "The 1 frame transmitted success!" etc. until the buffers are all full, then it prints "Transmit frame failed!" for the remaining attempts. Of course I have checked with wireshark that no package arrives at the other side.

I went through all registers of the Ethernet controller and checked them with the reference manual. I found no obvious problem. I have also checked the content of the first transmit buffer descriptor (after the first package has been seemingly successfully sent). Everything looks ok to me. I have put the dump below.

I can exclude hardware issues, because the old firmware works. It is very hard to understand what the old firmware does differently, since its structure is entirely different from the MCUXpresso SDK.

I don't understand what I am doing wrong. I know that this particular version of the MCU is not well supported any more, but I fail to see why this should not work. Can someone point me into the right direction what else to try or how to debug this further?

Cheers and many thanks in advance,
Martin

Here is the register/buffer dump:

==== ETHERNET MAC MEMORY MAP
EIR: 0
EIMR: 0
RDAR: 0
TDAR: 1000000
ECR: f0000002
MMFR: 6006786d
MSCR: 26
MIBC: c0000000
RCR: 5ee4104
TCR: 4
PALR: d4bed945
PAUR: 22608808
OPD: 10000
IAUR: 0
IALR: 0
GAUR: 0
GALR: 0
TFWR: 100
RDSR: 1fff0170
TDSR: 1fff01a0
MRBR: 5f0
RSFL: 0
RSEM: 0
RAEM: 4
RAFL: 4
TSEM: 0
TAEM: 4
TAFL: 8
TIPG: c
FTRL: 7ff
TACC: 0
RACC: 0
==== BUFFER DESCRIPTOR:
control: 8c00
length: 1000
==== BUFFER CONTENT:
0000: ffff ffff ffff d4be
0008: d945 2260 03da 0001
0016: 0203 0405 0607 0809
0024: 0a0b 0c0d 0e0f 1011
0032: 1213 1415 1617 1819
(continues like this for all 1000 bytes in the buffer)

This output has been produced using the following code (placed right below the call to ENET_SendFrame()):

ENET_Type *b = EXAMPLE_ENET;
PRINTF("==== ETHERNET MAC MEMORY MAP\n\r");
PRINTF("EIR: %x\n\r", b->EIR);
PRINTF("EIMR: %x\n\r", b->EIMR);
PRINTF("RDAR: %x\n\r", b->RDAR);
PRINTF("TDAR: %x\n\r", b->TDAR);
PRINTF("ECR: %x\n\r", b->ECR);
PRINTF("MMFR: %x\n\r", b->MMFR);
PRINTF("MSCR: %x\n\r", b->MSCR);
PRINTF("MIBC: %x\n\r", b->MIBC);
PRINTF("RCR: %x\n\r", b->RCR);
PRINTF("TCR: %x\n\r", b->TCR);
PRINTF("PALR: %x\n\r", b->PALR);
PRINTF("PAUR: %x\n\r", b->PAUR);
PRINTF("OPD: %x\n\r", b->OPD);
PRINTF("IAUR: %x\n\r", b->IAUR);
PRINTF("IALR: %x\n\r", b->IALR);
PRINTF("GAUR: %x\n\r", b->GAUR);
PRINTF("GALR: %x\n\r", b->GALR);
PRINTF("TFWR: %x\n\r", b->TFWR);
PRINTF("RDSR: %x\n\r", b->RDSR);
PRINTF("TDSR: %x\n\r", b->TDSR);
PRINTF("MRBR: %x\n\r", b->MRBR);
PRINTF("RSFL: %x\n\r", b->RSFL);
PRINTF("RSEM: %x\n\r", b->RSEM);
PRINTF("RAEM: %x\n\r", b->RAEM);
PRINTF("RAFL: %x\n\r", b->RAFL);
PRINTF("TSEM: %x\n\r", b->TSEM);
PRINTF("TAEM: %x\n\r", b->TAEM);
PRINTF("TAFL: %x\n\r", b->TAFL);
PRINTF("TIPG: %x\n\r", b->TIPG);
PRINTF("FTRL: %x\n\r", b->FTRL);
PRINTF("TACC: %x\n\r", b->TACC);
PRINTF("RACC: %x\n\r", b->RACC);

// -> TX buffer descriptor
void *transmitBufferDescriptorRingStart = (void *) b->TDSR;

typedef struct
{
uint16_t length; /*!< Buffer descriptor data length. */
uint16_t control; /*!< Buffer descriptor control and status. */
uint8_t *buffer; /*!< Data buffer pointer. */
} bd_struct;

bd_struct *desc = (bd_struct *) transmitBufferDescriptorRingStart;

PRINTF("==== BUFFER DESCRIPTOR:\n\r");
PRINTF("control: %04x\n\r", desc->control);
PRINTF("length: %d\n\r", desc->length);
PRINTF("==== BUFFER CONTENT:\n\r");
void *buffer = desc->buffer;
for (uint16_t i = 0; i < desc->length; ++i) {
uint8_t p = ((uint8_t *) buffer)[i];
if (i == 0) {
PRINTF("%04d: ", i);
} else if (i % 8 == 0) {
PRINTF("\n\r%04d: ", i);
} else if (i % 2 == 0) {
PRINTF(" ");
}
PRINTF("%02x", p);
}
PRINTF("\n\r");
PRINTF("======================================\n\r");

[mhier · Accepted solution]

I have found the issue. The Z version of the MCU does not has the DBSWP bit in the ENET_ECR register. The driver in the MCUXpresso SDK relies on this. Hence the byte order in the buffer descriptors is simply wrong. After correcting this (adding a bunch of ENET_HTONS etc. to the code) I am able to ping the IP address.

NXP, this is really bad. You are directing people from the product page of the Z version to this SDK, without clearly mentioning that it is not supported. I could not even find any SDK on your download page which seems to support the Z version. Can you please direct me to the place where I can download it? I need an SDK with FreeRTOS support.

[danielchen]

Here is an application note shows the differences and describes the details of migrating from Kinetis 100Mhz Rev1.x (Z version) to Rev 2.x (non-z).

https://www.nxp.com.cn/docs/en/application-note/AN4445.pdf

I am really sorry there is no support for MK60DN512ZVMC10 in MCUXpresso SDK.   I will take your suggestions to the software team.

Regards

Daniel

[mhier]

Thanks for pointing me to this document, this is really helpful. You should also correct the website:

1. It is not clear that the Z in the name corresponds to the revision. Hence there is a 50:50 chance to even download the wrong data sheet and reference manual. This should be clarified in the list of files here:
   https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mc...b
   And it should be clarified at the product page:
   https://www.nxp.com/part/MK60DN512ZVMC10#/
2. It should be clearly mentioned that the MCUXpresso SDK is not compatible. Currently, people are directly led do the MCXpresso SDK when navigating from the Rev1.x product page.
3. It should be easily possible to find a compatible SDK, even if that one is fairly outdated. Currently, I cannot find any SDK which mentions the Z version, not even the old Kinetis SDK versions have the right header files etc. in.
4. While you are at it, please also fix the forum: It does not keep me logged in, but it allows to write an answer while not being logged in. Clicking the Post button will redirect to the login, but the answer is then thrown away with a stupid error message (after successful login). This happened to me for every single answer in this thread now, I had to type them all two times. (And please throw out these stupid badges which are spamming my mail box!)

[mjbcswitzerland]

Hi

For efficiency keep two sets of the buffer descriptor fields so that you don't need to swap those controls when moving between Z and revision 2 parts - for example)

#if defined ETHER_DBSWP                                                  // {15} natural little-endian
    typedef struct stKINETIS_FEC_BD
    {
        volatile unsigned short usBDLength;
        volatile unsigned short usBDControl;
        unsigned char *ptrBD_Data;
    #if defined EMAC_ENHANCED                                            // additional fields available in enhanced mode
        volatile unsigned long  ulBDControlEnhanced;
        volatile unsigned short usPayloadCS;                             // only receiver
        volatile unsigned short usRxInfoHeaderProt;                      // only receiver
        volatile unsigned long  ulBDU;
        volatile unsigned long  ul1588_timestamp;
        unsigned long  ulRes[2];
    #endif
    } KINETIS_FEC_BD;

    #define EMPTY_BUFFER         0x8000                                  // RX BD Control bits
    #define RECEIVE_OWNERSHIP_1  0x4000                                  // can be optionally used by software
    #define WRAP_BIT_RX          0x2000
    #define RECEIVE_OWNERSHIP_2  0x1000                                  // can be optionally used by software
    #define LAST_IN_FRAME_RX     0x0800
    #define RECEIVE_MISS         0x0100                                  // received due to promiscuous mode only
    #define RECEIVE_BROADCAST    0x0080                                  // received due to broadcast address
    #define RECEIVE_MULTICAST    0x0040                                  // received due to multicast address
    #define RECEIVE_LENGTH_VIOL  0x0020                                  // receive frame length violation
    #define RECEIVE_NON_OCTET_AL 0x0010                                  // non-octet aligned frame
    #define RECEIVE_CRC_ERROR    0x0004                                  // receive CRC or frame error
    #define OVERRUN_FRAME        0x0002
    #define TRUNCATED_FRAME      0x0001

    // Enhanced
    //
    #define RX_MAC_ERROR         0x80000000
    #define RX_PHY_ERROR         0x04000000
    #define RX_COLLISION         0x02000000
    #define RX_UNICAST           0x01000000
    #define RX_GEN_INTERRUPT     0x00800000
    #define RX_IP_CS_ERROR       0x00000020
    #define RX_PROT_CS_ERROR     0x00000010
    #define RX_VLAN              0x00000004
    #define RX_IPV6              0x00000002
    #define RX_IPV4_FRAG         0x00000001

    #define RX_HEADER_LEN_MASK   0xf800
    #define RX_PROT_TYPE_MASK    0x00ff


    #define READY_TX             0x8000                                  // TX BD Control bits
    #define TRANSMIT_OWNERSHIP_1 0x4000                                  // can be optionally used by software
    #define WRAP_BIT_TX          0x2000
    #define TRANSMIT_OWNERSHIP_2 0x1000                                  // can be optionally used by software
    #define LAST_IN_FRAME_TX     0x0800
    #define TX_CRC               0x0400
    #define TX_ABC               0x0200                                  // append bad CRC - not supported in enhanced mode

    // Enhanced
    //
    #define TX_GENERATE_INT      0x40000000
    #define TX_ADD_TIMESTAMP     0x20000000
    #define TX_INSERT_PROT_CS    0x10000000
    #define TX_INSERT_IP_CS      0x08000000
    #define TX_ERROR_OCCURRED    0x00008000
    #define TX_UNDERFLOW_ERROR   0x00002000
    #define TX_EXCESS_COLLISIONS 0x00001000
    #define TX_FRAME_ERROR       0x00000800
    #define TX_LATE_COLLISION    0x00000400
    #define TX_OVERFLOW_ERROR    0x00000200
    #define TX_TIMESTAMP_ERROR   0x00000100

    #define BD_UPDATE_DONE       0x80000000                              // rx and tx
#else                                                                    // big-endian representation
    typedef struct stKINETIS_FEC_BD
    {
        volatile unsigned short usBDControl;
        volatile unsigned short usBDLength;
        unsigned char *ptrBD_Data;
    #if defined EMAC_ENHANCED                                            // additional fields available in enhanced mode
        volatile unsigned long  ulBDControlEnhanced;
        volatile unsigned short usRxInfoHeaderProt;                      // only receiver
        volatile unsigned short usPayloadCS;                             // only receiver
        volatile unsigned long  ulBDU;
        volatile unsigned long  ul1588_timestamp;
        unsigned long  ulRes[2];
    #endif
    } KINETIS_FEC_BD;

    #define EMPTY_BUFFER         0x0080                                  // RX BD Control bits
    #define RECEIVE_OWNERSHIP_1  0x0040                                  // can be optionally used by software
    #define WRAP_BIT_RX          0x0020
    #define RECEIVE_OWNERSHIP_2  0x0010                                  // can be optionally used by software
    #define LAST_IN_FRAME_RX     0x0008
    #define RECEIVE_MISS         0x0001                                  // received due to promiscuous mode only
    #define RECEIVE_BROADCAST    0x8000                                  // received due to broadcast address
    #define RECEIVE_MULTICAST    0x4000                                  // received due to multicast address
    #define RECEIVE_LENGTH_VIOL  0x2000                                  // receive frame length violation
    #define RECEIVE_NON_OCTET_AL 0x1000                                  // non-octet aligned frame
    #define RECEIVE_CRC_ERROR    0x0400                                  // receive CRC or frame error
    #define OVERRUN_FRAME        0x0200
    #define TRUNCATED_FRAME      0x0100

    // Enhanced
    //
    #define RX_MAC_ERROR         0x00000080
    #define RX_PHY_ERROR         0x00000004
    #define RX_COLLISION         0x00000002
    #define RX_UNICAST           0x00000001
    #define RX_GEN_INTERRUPT     0x00008000
    #define RX_IP_CS_ERROR       0x20000000
    #define RX_PROT_CS_ERROR     0x10000000
    #define RX_VLAN              0x04000000
    #define RX_IPV6              0x02000000
    #define RX_IPV4_FRAG         0x01000000

    #define RX_HEADER_LEN_MASK   0x00f8
    #define RX_PROT_TYPE_MASK    0xff00


    #define READY_TX             0x0080                                  // TX BD Control bits
    #define TRANSMIT_OWNERSHIP_1 0x0040                                  // can be optionally used by software
    #define WRAP_BIT_TX          0x0020
    #define TRANSMIT_OWNERSHIP_2 0x0010                                  // can be optionally used by software
    #define LAST_IN_FRAME_TX     0x0008
    #define TX_CRC               0x0004
    #define TX_ABC               0x0002                                  // append bad CRC - not supported in enhanced mode

    // Enhanced
    //
    #define TX_GENERATE_INT      0x00000040
    #define TX_ADD_TIMESTAMP     0x00000020
    #define TX_INSERT_PROT_CS    0x00000010
    #define TX_INSERT_IP_CS      0x00000008
    #define TX_ERROR_OCCURRED    0x00800000
    #define TX_UNDERFLOW_ERROR   0x00200000
    #define TX_EXCESS_COLLISIONS 0x00100000
    #define TX_FRAME_ERROR       0x00080000
    #define TX_LATE_COLLISION    0x00040000
    #define TX_OVERFLOW_ERROR    0x00020000
    #define TX_TIMESTAMP_ERROR   0x00010000

    #define BD_UPDATE_DONE       0x00000080                              // rx and tx
#endif

 And for maintainability put reads/writes of buffer descriptors addresses in a wrapper such as

fnLE_ENET_add(ptrTxBd[ETH_INTERFACE_CHANNEL]->ptrBD_Data);

and reads/write of data length such as

rx_frame->frame_size = fnLE_ENET_word(ptrRxBd[iInterface]->usBDLength); // length in the buffer

where the wrapper is nothing if the part has the register bit or uses an HTON function when it doesn't, eg.

#if defined ETHER_DBSWP
    #define fnLE_ENET_add(x) x
    #define fnLE_ENET_word(x) x
#else
    #define fnLE_ENET_add(x) (unsigned char *)(((unsigned long)(x) >> 24) | (((unsigned long)(x) >> & 0x0000ff00) | (((unsigned long)(x) << & 0x00ff0000) | (((unsigned long)(x) << 24) & 0xff000000))
    #define fnLE_ENET_word(x) (((unsigned short)(x) >> | ((unsigned short)(x) << 8))
#endif

Each should be needed only about 5 times each and then the driver can be controlled by adding or removing the bit define depending on which revision you are building for.

If you want a single code (binary) compatibility in equipment that may or may not have Z parts the non-native (Z-mode) has to be used on all.

Apart from Ethernet you may need to rework Random number generator code (the Z and non-Z parts have different peripherals) and RTC interrupts.

Although NXP dropped Z support a number of years ago in SDK packages it doesn't mean that Z parts don't sometimes turn up in batches of new K60s. Last year this was the case in a production run and in fact I never used the native Ethernet setup for K60 based Ethernet products due to the fact that if that happens a special version needs to be loaded to these boards for Ethernet to be able to operate if the swap setting were used.

Regards

Mark

[mhier]

This kind of tells me we shouldn't by NXP MCUs any more. We need long term support. And it seems, it would have been rather easy to add it. Why is NXP doing this? Just to annoy customers? A statement by NXP would help.

[mjbcswitzerland]

Hi

My guess is that they don't have the resources for maintenance so drop as much of the older parts as possible each time there is a new version of IDE or SDK in order to be able to concentrate on the new parts.

They dropped Processor Expert a few years ago and an insider told me that it was because it had bled millions in development/support cost and never actually became that which they wanted it to be (although there are fans who keep using it today).

The SDK concept is not good from that point of view of it needing a complete package to be maintained for each part - imagine each time there is a bug fix in a code section shared by most - it has to be fixed in every single package.... there are GBytes of code that is 95% copies of the same thing many times over.

It has improved in the last couple of years (but I think content generation has been their answer to get around the main weakness of the concept) but I wonder how much of the silicon parts costs go into maintaining the software tools(?)

Some of this is guessing but I support hundreds of users on almost all Kinetis parts and also maintain Coldfire and i.MX RT, and never needed to drop parts since the concept automatically keeps them all up to date. A new feature or development is inherited by all that have the peripheral set to be able to do it - no extra work needed and so many times more efficient.

Regards

Mark

[mhier]

If they don't support this MCU any more, they should be honest about this. Instead they point me to an SDK which does not work out-of-the-box. Also they still could provide the old SDK which did support the MCU. I am not asking to provide new software for old hardware indefinitely.

On the other hand, the differences seem to be rather minimal, so they actually could have added this support with very little effort. Fixing the byte order once I knew this was the problem was a matter of 5 minutes. Doing this properly so it still uses the feature on newer CPUs would be maybe an hour. Finding out that I have do to that despite NXP gives me the impression the provided software would work for this MCU took me a week.

This is not how a company should treat its customers. Ever.

[mjbcswitzerland]

Hi

If you need fast development that is compatible on all Kinets parts and allows you to develop, test debug and formally validate Ethernet, TCP/IP operation, as well as add new service protocols simply use the open source uTasker project on GitHub (or its supported commercial version with remote desktop support).

It allows you to run a simulated K60 on your PC that emulates the complete chip (interrupts, DMA  and peripherals including Ethernet) and attach the emulated part to the network and test and debug complete code in VisualStudio i(free Community Edition adequate) in real-time.

It also gives you an immediate integrated Ethernet, TCP/IP solution (works on K60 or K60Z) to avoid needing to mix parts from different middle-ware sources and allows project development times to be slashed in comparison to the traditional SDK techniques and HW debugging.

Tutorial for Ethernet based work: https://www.utasker.com/docs/KINETIS/uTaskerV1.4_Kinetis.pdf

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/kinetis/TWR-K60N512.html / https://www.utasker.com/kinetis/TWR-K60D100M.html / https://www.utasker.com/kinetis/TWR-K60F120M.html

[mhier]

Hi Mark,

thanks for replying fast. I have seen you advertising uTasker before here in the forums, so I already had a look. To me it doesn't look like it would support my particular MCU out-of-the box. Also the simulation wouldn't really help be, because I have a real device based on the MCU, not some evaluation board. Finally, I am using Linux, while uTasker seems to assume Windows.

Hence my impression is this is not the solution I am looking for. In any case, I would like to understand what is going on. I am using the SDK which is advertised by NXP for this particular MCU, this should work.

Cheers,

Martin

[mjbcswitzerland]

Hi Martin

Your MCU is supported out-of-the-box and has been used in various industrial K60Z based products since 2011.

The simulation runs the same firmware that operates on the final HW so your custom HW has no restrictions and the project will build an object for your target with various Eclipse based tool chains (including MCUXpresso where NXP otherwise doesn't support your part and KDS). That is, the project is for the HW and the simulation is an extra tool to improve efficiency, but doesn't actually have to be used if one prefers not to.

The project works on Windows, Mac, Linux - VS is also available and free for Linux: https://code.visualstudio.com/download

If I can't change your impression you can simply clone the repository from https://github.com/uTasker/uTasker-Kinetis and build for your target to see real operation. Or follow the tutorial so that you can experience how to improve development efficiency in your actual Ethernet based project.

If there is no way to move you to considering a new approach that could potentially save you weeks of work (and is totally free open source) I have added a register dump from the initialisation in a working system below so that you can continue debugging the solution that you presently have.

Regards

Mark

#md 400c0004 l 2
Memory Display
0x400c0004 0c010000 72780000 ....rx.. [EIR, EIMR ]

#md 400c0010 l 2
Memory Display
0x400c0010 01000000 00000000 ........ [RDAR, TDAR]

md 400c0024 l 1
Memory Display
0x400c0024 f0000112 ....   [ECR]

md 400c0040 l 2
Memory Display
0x400c0040 606e0000 0000002e `n...... [MMFR, MSCR]

md 400c0064 l 1
Memory Display
0x400c0064 40000000 @...   [MIBC]

md 400c0084 l 1
Memory Display
0x400c0084 05ea4106 ..A.   [RCR]

md 400c00c4 l 1
Memory Display
0x400c00c4 00000000 ....   [TCR]

md 400c00e4 l 3
Memory Display
0x400c00e4 00000000 00038808 00010001 ............ [PALR, PAUR, OPD]

md 400c0118 l 4
Memory Display
0x400c0118 00000000 00000000 00000000 00000000 ................ [IAUR, IALR, GAUR, GALR]

md 400c0144 l 1
Memory Display
0x400c0144 00000100 .... [ENET_TFWR]

md 400c0180 l 3
Memory Display
0x400c0180 1fff1ae0 1fff3f40 000005f0 ......?@.... [ERDSR, ETDSR, EMRBR]

md 400c0190 l 9
Memory Display
0x400c0190 00000000 00000000 00000004 00000004 ................ [ENET_RSFL, ENET_RSEM, ENET_RAEM, ENET_RAFL]
0x400c01a0 00000000 00000004 00000008 0000000c ................ [ENET_TSEM, ENET_TAEM, ENET_TAFL, ENET_TIPG]
0x400c01b0 000007ff .... [ENET_FTRL]

md 400c01c0 l 2
Memory Display
0x400c01c0 00000018 00000006 ........ [ENET_TACC, ENET_RACC]

md 1fff1ae0 w 100   [receive descriptor ring]
Memory Display
0x1fff1ae0 0000 8000 1ba0 1fff 0000 0080 0000 0000 ................
0x1fff1af0 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x1fff1b00 0000 8000 2190 1fff 0000 0080 0000 0000 ....!...........
0x1fff1b10 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x1fff1b20 0000 8000 2780 1fff 0000 0080 0000 0000 ....'...........
0x1fff1b30 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x1fff1b40 0000 8000 2d70 1fff 0000 0080 0000 0000 ....-p..........
0x1fff1b50 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x1fff1b60 0000 8000 3360 1fff 0000 0080 0000 0000 ....3`..........
0x1fff1b70 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x1fff1b80 0000 a000 3950 1fff 0000 0080 0000 0000 ....9P..........
0x1fff1b90 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x1fff1ba0 0000 0000 0000 0000 ........

#md 1fff3f40 w 100 [transmit descriptor ring]
Memory Display
0x1fff3f40 0156 0c00 3f80 1fff 0000 7800 0000 0000 .V..?.....x.....
0x1fff3f50 0000 8000 0000 0000 0000 0000 0000 0000 ................
0x1fff3f60 0156 2c00 4570 1fff 0000 7800 0000 0000 .V,.Ep....x.....
0x1fff3f70 0000 8000 0000 0000 0000 0000 0000 0000 ................
0x1fff3f80 ffff ffff ffff 0000 0000 0300 0008 1045 ...............E
0x1fff3f90 4801 0400 0000 1180 0000 0000 0000 ffff H...............
0x1fff3fa0 ffff 4400 4300 3401 0000 0101 0006 aa16 ..D.C.4.........
0x1fff3fb0 bca7 0000 0080 0000 0000 0000 0000 0000 ................
0x1fff3fc0 0000 0000 0000 0000 0000 0300 0000 0000 ................
0x1fff3fd0 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x1fff3fe0 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x1fff3ff0 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x1fff4000 0000 0000 0000 0000 ........

#