i.MX RT106x: enhanced tx buffer descriptors + hardware checksums...?

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX RT106x: enhanced tx buffer descriptors + hardware checksums...?

Jump to solution
293 Views
np
Contributor III

On the i.MX RT106x, I'm trying to combine enhanced buffer mode (for 1588 timestamps) and the IP accelerator (for hardware calculation of both IP header checksums and IP protocol checksums). In my tests, it seems that these two features work separately, but then fail when combined. :-(

As per the reference manual, I'm setting:

  • Setting PROCHK in ENETx_TACC
  • Setting IPCHK in ENETx_TACC
  • Setting STRFWD in ENETx_TFWR
  • Setting PINS in the enhanced tx buffer descriptor (offset +0xA)
  • Setting IINS in the enhanced tx buffer descriptor (offset +0xA)

According to Wireshark, however, all the checksum fields still end up as 0x0000, so it seems that something is wrong. :-(

My question: Was the PINS/IINS enhanced tx buffer descriptor feature implemented on the i.MX RT106x?

I specifically ask this because even though NXP's drivers/fsl_enet.h includes #defines for the other two bits in the same enhanced transmit buffer descriptor field (at offset +0xA)...

  • #define ENET_BUFFDESCRIPTOR_TX_INTERRUPT_MASK 0x4000U /*!< Interrupt mask. */
  • #define ENET_BUFFDESCRIPTOR_TX_TIMESTAMP_MASK 0x2000U /*!< Timestamp flag mask. */

...it includes no #defines for PINS and IINS (bits 12 and 11 respectively of the same field, according to Table 40-38 on p.2283 of the IMXRT1060RM reference manual). All of which makes me suspect that something might be wrong with this.

Alternatively, if anyone has got this feature working, please say (and hopefully tell me what trick I'm missing)!

Thanks very much, Nick

Labels (1)
0 Kudos
1 Solution
158 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Nick Pelling,

  After you set the PINS and the IINS, do you debug the code, and check the related address is really set or not?

  After you make sure it is really set, could you please also share the wireshark test result picture, which the checksums in the packets are all 0x0000.

  BTW, do you use the RT official board and the SDK test it? If yes, you also can tell me the detail steps to reproduce it, then I can test it and check with our internal related department.

Best Regards,

Kerry

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
------------------------------------------------------------------------------

View solution in original post

0 Kudos
5 Replies
158 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Nick Pelling

   Seems we are not using the same RT1060RM version, do you use the rev.2?

https://www.nxp.com/webapp/Download?colCode=IMXRT1060RM 

  I didn't find your mentioned content, please check the newest the RM, and point out the location again.

  BTW, when you combined and failed, what's the detail phenomena you are meeting? Do you debug it? Any hardfault issue?

Best Regards,

Kerry

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
------------------------------------------------------------------------------

0 Kudos
158 Views
np
Contributor III

Hi Kerry,

Thanks for the link to the updated manual, much appreciated!

In the Rev 2 version of the reference manual, the table I am referring to is Table 41-38 ("Enhanced transmit buffer descriptor field definitions (continued)") on p.2187, specifically the two lines beginning "Offset + A /  12 PINS" and "Offset + A" / 11 IINS". These are the enhanced transmit buffer descriptor bitfields that enable hardware checksum calculation for the IP protocol checksums and IP header checksum respectively.

When I set these two enhanced transmit buffer descriptor bitfields, I expect to see the IP header and IP protocol checksums (e.g. ICMP checksum for a ping) being set correctly by the IP accelerator. However, when I debug this in Wireshark, the checksums in the packets are all 0x0000.

There are no crashes or exceptions: the only issue is that the checksums aren't being set.

The system architecture we are working on is based around using both 1588 timestamps and hardware checksum acceleration at the same time. So this is a big deal for us. :-(

Thanks for your help, Nick

0 Kudos
159 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Nick Pelling,

  After you set the PINS and the IINS, do you debug the code, and check the related address is really set or not?

  After you make sure it is really set, could you please also share the wireshark test result picture, which the checksums in the packets are all 0x0000.

  BTW, do you use the RT official board and the SDK test it? If yes, you also can tell me the detail steps to reproduce it, then I can test it and check with our internal related department.

Best Regards,

Kerry

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
------------------------------------------------------------------------------

View solution in original post

0 Kudos
158 Views
np
Contributor III

Hi Kerry, I've rebuilt all the code from scratch and it now works properly. I have no idea what the difference was, it's now working in Wireshark, so the problem is (sort of) solved. Sorry to have taken up any of your time, thanks for your help, Nick.

0 Kudos
158 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Thanks so much for your updated information.

  You are always welcome!

  Any new questions in the future, welcome to create the new case, thanks.

Best Regards,

Kerry

0 Kudos