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

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Jump to solution
673 Views
philippewicker
Contributor II

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?

Thanks

0 Kudos
1 Solution
384 Views
adrian_alonso
NXP Employee
NXP Employee

Hi James,

Inside ISR is typically prefer to set a logging mechanism instead of setting break points to debug;

usually ISR should be simple implementation that there is no need to debug.

Regards

Adrian

View solution in original post

0 Kudos
10 Replies
385 Views
adrian_alonso
NXP Employee
NXP Employee

Hi James,

Inside ISR is typically prefer to set a logging mechanism instead of setting break points to debug;

usually ISR should be simple implementation that there is no need to debug.

Regards

Adrian

0 Kudos
384 Views
philippewicker
Contributor II

I agree with you. This idea of breaking into the ISR was just a quick and dirty way to get informations about what is going wrong. I also tried to write from the ISR into a global variable, which is the simplest logging mechanism I can think of. Bot with no success, this global variable is never modified.

Thx

0 Kudos
384 Views
YixingKong
Senior Contributor IV

Philippe, is your issue resolved? If yes, please close the DI. We will close it if no activity happens in 3 days.

Thanks,

Yixing

0 Kudos
384 Views
philippewicker
Contributor II

Hi Yixing,

No, my issue is still unresolved. For the moment I can workaround by disabling the interrupt request bit in the last DMA component in a sequence (the Terminator in the SDK). I'll have at some point to reenable this interrupt.

Thanks,

Philippe

0 Kudos
384 Views
YixingKong
Senior Contributor IV

Philippe

We are going to close the DI since no reply from you. If you issue still stexists, please keep working with Adrian.

Thanks,

Yixing

0 Kudos
384 Views
philippewicker
Contributor II

I found the reason of the crash when interrupts are enabled.

I work with an eclipse project which was not correctly set. I had to apply 2 modifications:

1- add the ivt.c file. The compilation of this file generates a bunch of data that are located into the ivt section by the linker (around line 145 in the script basic_sdk_app.ld.S). These data are not explicitly used by the code so the linker wasn't complaining when this file was absent.

2- uncheck the "remove unused sections" in the Linker properties. Compiling the ivt.c is not enough because the default settings of the linker is to remove unused sections.

However I still don't understand why this section is OK when the binary is compiled using the makefile delivered with the SDK. I have seen the ivt.c file in the sources list, but no command that could force this unused section to not be removed (I'm not a pro of the makefile, so nothing surprising here :smileywink:).

0 Kudos
384 Views
YixingKong
Senior Contributor IV

Philippe

Have not heard from you fo rsome time. Plase keep working with Adrian for your issue.

Thanks,

Yixing

0 Kudos
384 Views
YixingKong
Senior Contributor IV

Philippe

Thank you for your reply. Plase keep working with Adrian for your issue and try to get things done before Christmas holiday.

Thanks,

Yixing

0 Kudos
384 Views
jamesbone
NXP TechSupport
NXP TechSupport

We are working investigation the issue,  but we do not have a Phytec Board, so can you please give us some steps to reproduced it?.  What are the steps that you are following?

0 Kudos
384 Views
philippewicker
Contributor II

Hi,

Thanks for answering my question.

I have narrowed - but not solved yet - the problem since. Here are the steps I follow until the problem occurs:

- I compile under eclipse (in debug mode) the gpmi_test and link my code to a version of the SDK which I modified to compile it for the PHYTEC board (I had to generate a specific iomux_config with the IOMux.exe tool). By the way, this recompiled SDK includes the "MMU and cache enable" patch that has been post a few months ago on this forum. I have some problem with debugging as soon as the cache and/or the MMU are enabled, but this is another story (I'll start later a specific thread on that topic), so I have to comment the MMU and L2 cache enable codes in the patched platform_init() (lines 52 and 57).

- I run the gpmi_test until the first call to gpmi_nand_reset

- there I can either step or run unto the code at line 975:

    BW_APBH_CHn_SEMA_INCREMENT_SEMA(r32ChipDmaNumber, 1);

- if I've well understood this line effectively starts the DMA by setting the semaphore to 1

- from now on if I step into the line 980, or try to break any where after this point, then the PC get lost in addresses near 0 (ROM addresses?). I get a message on the eclipse console which says I'm trying to go or to access 0xdeadfeec address. "0xdeadfeec'" is 0xdeadfeed truncated to an even value. It seems that "someone" has used an uninitialised value on the stack, but who?. I'm unable to trace what has happened because the stack trace is broken and shows only a couple of addresses with values like 0x6fc or so.

What I've seen is that the "crash" is related to the setting of the interrupt completion bit which is set in the Terminator::success and  Terminator::failure apbh_dma_t members.

This bit is set by the macro "success.cmd.U = (BF_APBH_CHn_CMD_IRQONCMPLT(1)...." (line 134 of gpmi_dma_components.cpp. If I reset this bit to 0 then the problem disappears. So I'd say that the crash is the result of the interrupt generated at the end of the DMA sequence. Unfortunately I've been unable to break on an ISR. As a temporary workaround I have disabled this interrupt request bit and I check the DMA completion by polling the semaphore until it reaches 0.

This is where I am for now.

Thx

0 Kudos