AnsweredAssumed Answered

Just solved the most perplexing BF issue I've ever had

Question asked by kbrafford on Feb 16, 2012
Latest reply on Mar 2, 2012 by PrasanthR

Wow!

 

Our team just figured out the most amazing lingering intermittent issue I've ever seen.  We've had on again, off again issues for years.  Because of the dynamic configuration capability of our system we've always been able to come up with McGuyverisms to work around them. But we won't have to do that any more (I hope!)

 

It's a BF532 system, in bypass mode.  Starts up running a boot app written 6 years ago.  I look for a code load in the proper place and do a CRC that's compared to a field in a header.  If everything checks out I set up DRAM, and then boot the image. 

 

To boot it, I use the code for the Edinborough Boot Rom that was in the VDSP 3.1, modded to do a boot stream from 16-bit flash on the async bus.  That has worked phenomenally well for several projects over many years.

 

Turns out there's one little catch in the Edinborough boot code of that era that ended up biting us:

 

W[P1+LO(MDMA_D0_CONFIG)] = R4; // Set Destination DMAConfig = DMA Enable,

                               // Memory Write, 8-Bit Transfers, 1-D DMA,

                               // Flow = Stop, Interrupt on Completion

IDLE;                  // Wait for DMA to Complete

W[P1+LO(MDMA_D0_IRQ_STATUS)] = R3;    // Write 1 to clear DMA interrupt (R3 = 1)

 

The MDMA is configured for IRQ on completion, but there is no ISR registered.  The result  is that ILAT[13] is set because an IRQ is requested, and the default setting in SIC_IAR for MDMA0 is ik_ivg13.

 

That happens over and over again for the various memory blocks in the boot stream...ILAT[13] stays asserted.  The end result is that out of that boot process, ILAT[13] is high.

 

Most of the time it doesn't end up mattering.  The problem shows up when a code load does two things:

 

  1)  installs an ISR into ik_ivg13 with register_handler(), or register_handler_ex() with "turn the irq on" mode used

 

and

 

  2)  has code or data loaded in memory that is about to be destroyed when the ISR that isn't supposed to be triggered gets triggered one time

 

In our application the workaround is to check for the ILAT[13] condition at main code startup, and clear it before continuing.  But if this boot code is still used by other people I think it should be modified to do something to prevent the issue altogether:

 

W[P1+LO(MDMA_D0_CONFIG)] = R4; // Set Destination DMAConfig = DMA Enable,

 

                               // Memory Write, 8-Bit Transfers, 1-D DMA,

 

                               // Flow = Stop, Interrupt on Completion

 

 

 

IDLE;                  // Wait for DMA to Complete

 

{ do proper things here to make sure ILAT[13] isn't still asserted }

 

W[P1+LO(MDMA_D0_IRQ_STATUS)] = R3;    // Write 1 to clear DMA interrupt (R3 = 1)

 

HTH,

--Keith Brafford

Outcomes