Debug only runs once, then requires manual FLASH erase.

[gh78731]

Environment:
iMX RT1050 EVK B, re-strapped for QSPI operation, in place of Hyperflash.
iMX RT1020 EVK running from QSPI
Mode: QSPI XIP, Debug or Release.
MCUXpresso IDE v11.2.1
Windows 10

I have a working application running as QSPI XIP. It is real time signal processing of streaming data, I2S input via edma, ARM DSP.

The program builds and runs OK, but I am having trouble with the Debug or Reset “Termination.”

With a blank QSPI, the debug function works fine one time.

But, when I press “Terminate”, or “Terminate, Build and Debug”, the program does not stop, only resets/restarts immediately. This happens in either “Debug” or “Release.”

Now, the debugger can not access the QSPI erase, it throws errors saying that the LinkServer has a problem, and failed to execute MI command, timeout upon attempt to erase Flash, and also reports no SWD interface to be found.

What could I have done in program coding to prevent the LinkServer from regaining control?
I am not using the watchdog, or low power, or sleep. It is a continuously running program processing a realtime I2S stream. The program itself is running as expected, when I can get it to load.

What other common problems could cause this?

I can regain control of the CPU, by putting it into "Serial Download", performing a manual erase of the QSPI, then returning to QSPI boot. But, as before the apparently working program can only be loaded once, in either Debug or Release Configuration, before loosing ‘Termination’ control from the DAP Link.

If I create a new workspace, move the project there, erase the flash, sometimes I can get everything working for a while, but after a half hour or so of programming, it will loose control, and it seems that workspace is “contaminated”. No amount of fiddling allows me to work again in this workspace without manually erasing the Flash every time.

Needless to say, all of this is stopping progress on my program development. A debugger that can not control the CPU is not useful.

What is going on here?

--- Graham

[kerryzhou]

Hi gh78731，

    Thanks for your interest in the NXP MIMXRT product, I would like to provide service for you.

    As I know, the debugger issues normally still related to the abnormal code, you also can find when you stop the SAI transfer, then the project works again with the debugger.

    So, I have a question, when you code can't use the debugger run it again, whether your app runs normally? Do you have external Segger JLINK? Can you use the external JLINK to debug your project again, whether the same issues? When you use the external Segger JLINK to connect the J21. You also need to disconnect the on board J33. 

    If you still have the same issues, please use the JLINK commander, halt the code, where is it stopping? You can give me some screen shoot.

   Please try it at first.

   Any updated information, please kindly let me know.

Wish it helps you!

If you still have questions about it, please kindly let me know!

Best Regards,

Kerry

-------------------------------------------------------------------------------

Note:

- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored

Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

-----------------------------------------------------------------------------

[gh78731]

Hi Kerry:

Thank you for your response.

I have a Segger, so I will try it as you suggest, in place of the on card OpenSDA Interface.

I also implemented a button on the EVK which the program uses to stop the I2S/SAI/EDMA from executing, and parks the CPU in a simple while(1) loop waiting to be terminated from the IDE. That also works well, and allows me to proceed with program development.

I don't think what I have implemented is unusual, it would be typical for high-end audio application. I2S, 24 bit stereo, streaming at quad sampling rate, into circular buffer. I would not expect this to stress the iMX.  Running just this portion of the program causes the "loss of ability to Terminate" problem.

Do you know if the I2S/SAI/EDMA internal transfer process is byte by byte, int by int, or long-word by long-word? (That is 8 bits at a time, 32 bits at a time, or 64 bits at a time?) I am trying to understand how much bus bandwidth and dma interrupts I am using.

I will let you know the results of using the Segger.

Thank you,

--- Graham

==

[kerryzhou]

Hi gh78731,

   Thanks for your updated information.

   After you test the external JLINK, please let me know your result.

   I have question for your, do you work this case for the your company? If you are working for the company, do you have the company email, you can use the company email to create the new nxp account, then create the question case, and that time, your case will be level up, I can assign more time to help you to test your project. If the JLINK is the same result, I think, we need to put more time to test it.

  BTW, when you do the I2S code, do you modify any JTAG related pin function? i mean, your used SAI pins are also the JTAG related pin, take an example, JTAG_MOD pin is GPIO_AD_B0_08, it should be low, but this pin is also the SAI2_RX_DATA pin. Do you use this type?

If the JTAG related pin function is modified, it will influence the code debugging and downloading.

Any updated information, please kindly let me know.

Best Regards,

Kerry

[gh78731]

I have further information.

If I stop the SAI edma transfer before I use the IDE to "Terminate" the program, then the IDE/DAP_LINK has no problem stopping the program, and maintaining control for the next build, program and Debug cycle.

So it appears that all the bus and interrupt activity associated with the I2S / SAI / edma activity is what is preventing the "Terminate" command from working properly.

I can't think of a way to do this automatically.

I suppose, as a 'hack" I could add a "stop" pushbutton input to the processor and shut down the SAI transfers, before I use the Terminate from the IDE.

Does anyone have a better suggestion or approach?

--- Graham