I'm using the Helloworld_demo application to experiment with the platform.
Debugging appears to be working correctly and breakpoints work correctly including breakpoint at app_start, however breakpoints once the program has entered the thread created by "Result = qurt_thread_create(&Thread_Handle, &Thread_Attribte, HelloWorld_Thread, NULL);" , don't ever get hit but the program is running as the serial port shows the correct output.
The Console shows this:
Error: address + size wrapped (0xfffffffe, 0x00000004)
Error: JTAG-DP STICKY ERROR
Kindly make sure you have followed the instructions on Section: 3.7.2 JTAG debug mode from document QCA402x (CDB2x) Development Kit User Guide 80-YA121-140.
Kindly reset the device and try debugging again with J31 pin 1 and 2 connected.
I have just run through the instructions again, and still debugging is entered correctly hits the breakpoint at app_start, then when I press continue it continues to run and never hits the breakpoint set in the function HelloWorld_Thread(). An output can be seen on the serial port and as such I'm sure it's running past the breakpoint I have set.
I can also confirm that I have reset the device and that J31 pin 1 and 2 are connected.
Could it be an issue relating to the PATH, I do have highlighted issues about things not being able to be resolved in the code editor but this hasn't effected building the program.
The Console shows this:
Error: address + size wrapped (0xfffffffe, 0x00000004)
Error: JTAG-DP STICKY ERROR
Error: Failed to read memory at 0xfffff000
Error: address + size wrapped (0xfffffffe, 0x00000004)
Error: JTAG-DP STICKY ERROR
Error: Failed to read memory at 0xfffff000
The above error traces occur when the path is not valid such as different demo path being processed during debug scenario.
In such cases, the hashed elf fails to match the original Quartz.elf instruction address and breakpoint results in failed to read memory.
invalid command name "speed"
invalid command name "endian"
invalid command name "jtagconf"
The above "invalid command name" are warning traces, they are part of the GDB server configuration and can be ignored
Kindly check the Path settings and make sure appropriate path location has been set for build/flash and debug.
I've just deleted everything and started again, I followed the development getting started guide and I'm still getting the same issue. I'm quite stuck here... I believe all the paths match that of the development guide.
Is the Flashing Script working okay? Here is an extract:
From the provided log, the flashing of device is successful.
Can try the manual way of debugging on terminal prompt to confirm if there if there is an issue with debug setup irrespective of IDE.
Refer to Section: 3.7.2.2 Debugging through GDB of document QCA402x (CDB2x) Development Kit User Guide 80-YA121-140.
Hey there, I attempted to debugging in command promt and this is what happened after I continued the debug a number of times:
From the provided information, the Openocd-JTAG debugging is failing in both command line and Eclipse IDE:
Breakpoint 2, sbl1_main_ctl (pbl_shared=0x10032f78) (gdb) c
Continuing.
Invalid ACK (7) in DAP response
Program stopped.
(gdb)
The reason for above error "Invalid ACK (7) in DAP response" could be an issue with jumper settings.
Can you provide us your setup images in any shared link to verify the jumper connections and also let us know the hardware version you are using ?
Sorry for the delay, had to move onto another project for a while, please find the image of how the board is currently setup at the following link: https://imgur.com/TgDKeZ0
Any ideas? I'm starting to get pressed on the project again!
Kind Regards
Unable to view the attachment. Could you share the image vis google drive ?
Here you go https://drive.google.com/file/d/1FkC6yfUOYFzbngNy_Kkm1T9INLyMuNZ6/view?u...
The jumper settings are good as expected and there should be any issue while debugging using GDB session.
Could you check with new jumper pins and wires for the connection again to confirm no issues with the connection setup.
As sometimes, we have seen similar issue when the cables are loose or jumper pins are broken inside.
Kindly rebuild the image, flash and try to debug with the replaced jumper connections.
I replaced all the jumper connection with new jumpers and have attempted to rebuild, reflash, and debug, with no joy the same output as last time so far as I can tell.
here is an short extract:
The only suspect is the devcfgSleepData not turned off.
Can you confirm the instructions listed in Section 3.7.2 JTAG debug mode of QCA402x(CDB2x) Development Kit User Guide are followed ?
Please execute below instrucitons and let me know your observations:
build.bat clobber
build.bat prepare 4020
Modify DevCfg_master_devcfg_out_cdb.xml and turn off "devcfgSleepData".
build.bat t 4020 cdb
flash the image.
Install jumper on J31 "1 and 2".
Execute "openocd -f qca402_openocd.cfg" on terminal
Open another terminal and run "arm-none-eabi-gdb -x v2\qcartzcdb.gdbinit"
on the gdb screen try to set "p g_sleepAllowLowPowerMode =0" and run continue.
Try to enable required break point and verify if you are able to hit the break point.
I am having exactly the same problem,
the breakpoint is not hit
the last one, which is effective, is inside App_Start, when building with ThreadX, for FreeRtos it does not stop even there
btw the variable is g_sleepAllowLowPowerModes, but it does not help either
BR
Hello,
Has this issue been solved. I am having the exact same problem in this thread an a solution would really help me get going in the right direction.
thanks
No, the issue is still not solved
Debugging from command line GDB is not a solution for me.
It takes too much effort, the same counts for flashing image each time, it takes many minutes.
For the older chip there was on option to laod code directly to RAM which was fast. It is apparently not available here.
Working with this platform is a pain
Ok, thank you for your feedback.
Just out of curiosity then. What is the best way to debug this evaluation Kit. It seems like there is no real way of debugging applications on this board. Is this correct? Someone somehwere must have this working
Regards,
Gian