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
Solved! Go to Solution.
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
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
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
Philippe, is your issue resolved? If yes, please close the DI. We will close it if no activity happens in 3 days.
Thanks,
Yixing
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
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
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:).
Philippe
Have not heard from you fo rsome time. Plase keep working with Adrian for your issue.
Thanks,
Yixing
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
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?
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