This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Initialize DMA Rx-Descriptor count typo in Tiva-tm4c129.c = DMA fatal bus error?

Guru 55913 points

Among issues encountered with EMAC0 and DMA debug handling logic;

Murphy's law strikes. Might this typo be driving DMA fatal Buss errors during the handling of receive descriptor PBUF?.

Could typo be causing Rx-Descriptors to randomly Suspend DMA operations in the receiver?

Seems the DMA Rx descriptor may advert in failing to set flag OWN tested for in tivaif_receive() while a packet is in the receiver FIFO.  

We have discovered DMA fatal bus error may lead to undesired MPU reset if the bus error is not reset by software during call to EMAC0 interrupt handler. Seems a bit drastic to reset then reinitialize DMA configuration in that case but the code to do so is posted below. 

Perhaps typo has a systemic time released bomb causing fallouts in EMAC0 DMA engine upon being heavily tasked for many hours. That is of course after tweaking the configuration of the DMA to advert any would be time bombs causing DMA fatal Bus errors.

So far in testing DMA tweaks that only seem to extend the time when the software bomb drops his payload upon the hardware.

Line 287-288 of the {InitDMADescriptors} function incorrectly names  {RxDescList} as the {TxDescList}.

Line 287-288 should read as follows:

  g_RxDescList.ui32Read = 0;  g_RxDescList.ui32Write = 0;

Soft reset DMA engine:

// Check for a DMA fatal bus error status state.
    // A bus error requires soft resetting EMAC0
    // and reinitializing DMA bitfields Reg 52 EMACDMABUSMOD.
    // Reg 57 EMACDMARIS FBI bit signals fatal bus error.
    //
    if(MAP_EMACDMAStateGet(EMAC0_BASE) == EMAC_DMA_ERROR)
	{
        // Reset the MAC regardless of whether the PHY connection changed or not.
        //
        EMACReset(EMAC0_BASE);

		// Wait for EMAC0 DMA to signal it has soft reset.
		// MACDMABUSMOD SWR 1 toggles 0 prior to initializing DMA.
                // 
		while(HWREG(EMAC0_BASE + EMAC_O_DMABUSMOD) & EMAC_DMABUSMOD_SWR)
		{
		}
		// Initialize EMAC0 DMA mode Tx/Rx Bursts size in words.
		// Set Transmit priority weight 2, Mixed Burst priority ratio 2:1.
		// Reg 52 EMACDMABUSMOD
		MAP_EMACInit(EMAC0_BASE, 120000000, //was EMAC_BCONFIG_PRIORITY_FIXED,
				  EMAC_BCONFIG_MIXED_BURST | EMAC_BCONFIG_TX_PRIORITY |
				  EMAC_BCONFIG_DMA_PRIO_WEIGHT_2 | EMAC_BCONFIG_PRIORITY_2_1 ,
				  8, 16, 0); // Tx8 Rx16 0 gap was 4, 4

	 }
  • Reviewing the error trap - the While loop might not allow the (ui32DescEnd) to qualify an (==) in the trap.

    Changed the (else if) line to ( != ui32DescEnd) case the Host (OWN), has control of the descriptor PBUF when the receiver FIFO might stall.

    Added a {UARTprintf } line during RxDMAPoLL to print out if or when that condition might occur if ever.

    That added RxDMAPoll  error trap would normally be skipped asserting the upper (break). Error trap invoked if the host has control of the OWN bit when the hardware believe he should OWN it.

  • Self-annointed "Likes" should be disallowed.      Same declarative sentence (hedged) via terminating, "?".

    Your "?" termination method not (too) common - may register as "aggressive" - and may not (best) encourage response...    (offered as constructive)

  • Should be rewarded for finding that bug. Unsure what or if Bug even causing DMA fatal bus error at all. Spock would say Logic deducts words Fatal and bus in the same sentence might require a phone call into head quarters! Only Murphy knows for sure if industrial espionage is at hand.