AnsweredAssumed Answered

iMX6 GPMI sdk: Branching (?) to address 0x18 when stepping.

Question asked by Philippe Wicker on Nov 27, 2013
Latest reply on Feb 18, 2014 by Philippe Wicker
Branched to a new discussion

Hi all of you,


I've began to experiment - using Eclipse - with the iMX6 SDK 1.1 code, and more specifically with the GPMI driver. The code is running on a PHYTEC board which provides an iMX6Q and a NAND Flash connected to the GPMI. I'm encountering a strange behaviour when the processor reaches the code in file gpmi.cpp, in the gpmi_run_dma, and later in gpmi_wait_dma functions.


I can step into gpmi_run_dma until line 980 which are as follows:


    // Initialize DMA by setting up NextCMD field

    HW_APBH_CHn_NXTCMDAR_WR(r32ChipDmaNumber, (reg32_t)physicalCommandAddress);


    // Start DMA by incrementing the semaphore.

    BW_APBH_CHn_SEMA_INCREMENT_SEMA(r32ChipDmaNumber, 1);


    // Record the time that I started the transaction

    // Used in the NAND_HAL_Dma_Status function below and the ddi_gpmi_wait_for_dma

    // function above to determine timeouts.

    g_gpmi.dmaInfo.uStartDMATime = time_get_microseconds();


    rtStatus = gpmi_wait_for_dma(timeout, chipSelect);


If i try to step into the 3rd line of code then I don't regain the control under the debugger. I have to press the "suspend" button and then the stack is meaningless - to me at least. It shows 2 stack frames around 0x6xx, without displaying any source. I've tried to put breakpoints at the beginning of the memory (a couple of addresses starting at 0). Then the processor stops at PC 0x18. From there I cannot steps into he code, the PC seems to be stucked there.

I think 0x18 is somewhere inside the IVT, the jump to the IRQ_HDLR maybe.

At this point I registered a fake ISR for all interrupts IDs (0 to 0x1FF) and set breakpoints in this ISR and in the GPMI ISRs as well, but I never reaches these breakpoints.


The  gpmi_wait_dma starts with the following code:


    reg32_t     r32ChipDmaNumber = NAND0_APBH_CH; // + chipSelect;

    bool        bTimedOut = FALSE;

    int  rtStatus = SUCCESS;


#if 1 //def RTOS_THREADX

    // Wait for the IRQ to unlock the spinlock.

    int lockResult = spinlock_lock(&g_gpmi.dmaInfo.irqSpinlock, u32usec);



If I set a breakpoint in gpmi_wait_dma before the call to spinlock_lock, it's OK. A break on the spinlock_lock or after fails: I have to suspend the execution and then I get the same kind of meaningless stack as above. I'm probably never going out of the spinlock (no interrupt?).


I have 2 questions:

1- Is it possible to set a breakpoint within an ISR?

2- What could explain that strange stack when I suspend the execution?