Is it normal that operating system get freezed after finish debugging process with jlink.
I am using a UDOO NEO board, which has UDOObuntu.
When I debug from TCM or OCRAM, after finish I stop the session and ubuntu is freezed, even can not access with uboot terminal console so I assume Cortex A9 get freezed.I need to restar the session again for get control and start debugging.
I am almost sure that peripherals used in my code for m4 are not being used in A9. Suspect sometine with WDT or idle power of ubuntu but I am not pretty sure.
Yes, but i am only using uart1 for uboot debugging which is in domain of A9 and SSH trough usb, which also has inA9 domain. In the other side, I am just testing hello world with uart2 from M4 and I checked twice that this was not activated in A9 on device tree.
After all this considerations jlink still halting both cores. Now I read also, that I am using a old version of kernel linux 3.14.58 from udoo team, and also uboot 2015.xx, I read in embedded artist tutorial that the problem is related to RDC initialization for A9 on uboot which is not possible in my actual uboot version. However, for me this statement does not make sense since I was careful selecting, enabling and isolating peripherals.
I do not want to update linux, because is a huge labor. Udoo neo team is not bringing a new version with uboot and linux updated. So I will need to port from NXP official repository, and build my own image from scratch. I am leaving this updating process like my last alternative if every else fault.
However, I was checking the similitude between sabre board and udoo neo board and does not look to different in hardware point of view. Probably I am wrong...
Now I can work debugging without reset the board, but for me, still being a lost of time copy the built project to boot partition and then executing from linux and then debug... It is annoying. I am trying figure out how to flash directly the built project .bin with jlink by connecting to A9 side. It is a huge process also and there is not more information...
BTW, I already read all documentation that you recommend me, I dont know if I am forgetting something and probably I can debug without halt A9 with my actual version of images...
Hi Jefferson
it does not matter if uart1(or any of mentioned modules: CAN, UART, EPIT,
GPT, ENET, PWM,WDOG) is in domain of A9, possible reason of misbehaviour may be that
when M4 enter debug mode it sets debug_req for all modules, below example for uart:
So one can set DBGEN=1 for all modules used by A9, for not going into debug mode
and keep them running.
Best regards
igor
Hi Jefferson
hanging may be caused by that when M4 enter debug mode, the debug_req will also
assert in the peripherals which are used by the A9 system.
Need to configure the DBGEN (*) register in the related peripherals to allow
the peripherals not going into debug mode and keep running even if debug_req is HIGH.
The peripherals which need take care are: CAN, UART, EPIT, GPT, ENET, PWM,WDOG.
Also may be useful to check documents describing M4 usage :
Working with Cortex-M4 on i.MX6 SoloX Board
AN5317 Loading Code on Cortex-M4 from Linux for the i.MX 6SoloX and i.MX7Dual/7Solo Application Processors
https://www.nxp.com/docs/en/application-note/AN5317.pdf
AN5127 How to Run the MQX™ RTOS on Various RAM Memories for i.MX 6SoloX
https://www.nxp.com/docs/en/application-note/AN5127.pdf
Best regards
igor
I find out the solution.
Background of the main problem:
As imx6sx has a core for A9 and other one for M4, when you perform a debug process with jlink, this will halt both of these cores, in consequence after finish you can not only leave halted the processor because this will stay freezed. We want to finish a debug process but we want also still using linux for load other code make something on it. Therefore, we will need to be sure that processor M4 is running (not halted) after push the button "Terminate" on eclipse.
Solution for eclipse:
After catch the bug in the code, we need to disable breakpoints and then run the debugging process. After this we can use the button "terminate" placed in console "debug [GDB SEGGER J-Link Debugging] JlinkGDBserverCL.exe".
If you follow this rule of thumb, you will be able to debug a code without restart the UDOO Neo board.
I have been reading more about the issue. I find a possible cause of the problem. I am using eclipse, gnu arm and eclipse. Thing is that jlink is not stoping correctly the debug process. I mean, it is just finishing without send the order to processor for resum the tasks, so in theory it is just leaving the processor stoping/halted, and in consequence all the system can noy be resumed and it is only possible to restar for starting a new session.
More information about this issue here:
However, this is just a possible cause. If somebody has a more deep knowledge about jlink, gnu and eclipse please confirm this.