cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F107 Ethernet DMA TBUS bit always set and not other useful info

LPala
Associate II

Hi,

i'me trying to develop a firmware for STM32F107RCT with a 4 port Microchip switch.

The switch has 3 port with phy and 1 port in MAC/PHY mode. I've set it in MII PHY mode.

It get's the 25MHz clock from MCO1 pin (set HSE that use a 25MHz quartz) and gives back RXC and TXC to MII MAC iface of 107.

The switch has not MIIM interface (I use SPI interface to control it). So HAL ethernet init was set to disable autoneg and 100mbit/s FD static status.

The RX from ethernet is working fine. Debugging I can find ARP request coming in and ARP response ready to be transmitted. Both RX and TX buffer are correct. TX buffer contains a valid ARP answer.

The problem is that when the frame shoud be transmitted (HAL_ETH_TransmitFrame), it finds the TBUS bit set in DMASR register. The HAL code successfully reset it and restart DMA TX buffer polling. DMA TX should now wait for OWN bit to set in TDES0. In next HAL_ETH_TransmitFrame call it finds again TBUS bit set, and so on. So it never transmits the frame.

No other useful bits are set in register or TDEF0 to get errors (TDEFs are update just after having set the OWN bit).

I'm thinking that it was and HW bug, but everything seems to be right as I've checked alla signals and are right (even if I can check only RX signal as TX are never be used for this problem).

Reading the reference manual, TBUS bit should be set only in case of buffer underrun or in case of OWN bit not set in TDES0. In first case I should have some bit set in TDES0 indicating and error, but I've not got them. In second case, I should have AIS or TU bit set in DMASR reg, But I've not any of them set.

Can you suggest whats setting TBUS bit other than these two cases?

Thanks

Luca

2 REPLIES 2
Piranha
Chief II

> DMA TX should now wait for OWN bit to set in TDES0.

No, it doesn't wait for anything. It checks the TDES0 of next descriptor and, if OWN bit is not set, suspends and sets TBUS status bit.

Bit 2 TBUS: Transmit buffer unavailable status

This bit indicates that the next descriptor in the transmit list is owned by the host and cannot be acquired by the DMA. Transmission is suspended. Bits [22:20] explain the transmit process state transitions. To resume processing transmit descriptors, the host should change the ownership of the bit of the descriptor and then issue a Transmit Poll Demand command.

Have you read section 29.6.7 of RM0008? To me it seems that you are interpreting TBUS as some bad error, but it really is a normal status bit meaning "there are no more frames to transmit". When you transmit only a single frame, TBUS is set immediately after the frame has been transmitted as there are no other frames to transmit. Therefore, while there are no transmission ongoing, DMA Tx sits suspended with TBUS set. It is absolutely normal state and you un-suspend it up only when you've prepared (everything ready and OWN bit is set) at least one frame to transmit.

LPala
Associate II

Hi Piranha,

you are right. Maybe I've misinterpreted the unavailable status and thought that it was an error status.

Really I'm not able to see output on TXD[0:3] or TXEN MII lines. So something else must be wrong. Have you any idea why it can block txing?

Luca