while(((EMACSwizzleData(curr_bd->flags_pktlen)) & EMAC_BUF_DESC_OWNER) == EMAC_BUF_DESC_OWNER);

Hello Arne Staessen,

I just had a quick look at your code and typically I had seen this problem with code porting from bigendian to little, but everything seems fine with that since its in little endian the SwizzleData does nothing.

Ill request one of our EMAC experts to have a look at your project.

This could be a pinmux problem, because if the packet is just sitting in the buffer memory and the MAC doesn't process it - a reason would be that there's a problem on the MII/RMII port. For example see e2e.ti.com/.../426102

That post is specific to HalCoGen 4.04.00. In 4.05.00 there is now a separate checkbox on the special pin muxing tab that needs to be checked for MII mode.

There are 2 different selections going on:
a) which pins / balls on the part are used for the ethernet signal. (Input/Output Mux tabs select this)
b) which mode the EMAC works in (MII or RMII). (Special Pinmux tab selects this)

If the device is an RM57L or TMS570LC the pinmux has one additional complication which is you need to know which balls the MII/RMII interface is connected to. These parts have 2 options whereas the RM48 / TMS570LS have only one option.

On the RM57L / TMS570LC if you use an HDK - this is the same board as the RM48 / TMS570LS HDK, and the MII interface uses the location where MII is the secondary function. So you would check all the MII options on the output pinmux tab.

However, on the Launchpad, the RM57L/TMS570LC launchpad is designed to use the new (primary/default) set of pins for MII/RMIO. So for a launchpad, you *do not* select the MII pins on the pinmux output tab, because those are the *secondary* locations for MII. There aren't any checkboxes for the primary location.
You do need to make sure the 'Default' column on the input mux tab is selected for the MII pins.

Hi,

I am also having this problem on the RM46L852PGET package.  In Halcogen 4.05 the only drivers / pinmux enabled are MIBSPI3, MII, and SCI, with MIBSPI3NCS_1 conflict cleared and MIBSPI3NENA cleared (as opposed to CS_5).

MDIO and MDCLK are checked.

I am using UDP mode on LWIP, and if the host computer sends one UDP packet per cycle (i.e. the packet gets handled in a timely fashion) there are no symptoms, whereas if two UDP packets are sent sequentially without being processed by the ISR, the code gets stuck in the

"  while(hdkif_swizzle_data(curr_bd->flags_pktlen) & EMAC_BUF_DESC_SOP) {" 

section of code.

flags_pktlen is a big number (3942645758).

Any thoughts?

Josh

I installed an older version of Halcogen (04.01.00) to generate my code and now everything works flawless. The example on the wiki page was made with 04.00.00 and that one did the job as well. But now I use the 04.01.00 because FreeRTOS is included for the RM57L843.

Arne