Hello, all.
I'm trying to attach Dstream JTAG debugger to a Cortex-M3 core on HiKey Board with DS-5 v5.23.0 Ultimate Edition on Windows.
I tried the following procedure but it took more than one minute to connect to the target.
That is too slow to be compared to other platforms (for example, Cortex-A53_SMP on the same HiKey board takes less than 5 seconds to be connected.)
1. Use "Debug Hardware Config" tool to "Auto Configure" and export a platform file. This tool found 8 Cortex-A53 and a Cortex-M3.
2. Use cdbimporter to import the platform file
3. Rebuild the database on DS-5
4. In Debugging perspective, open debugging configuration and select the imported platform -> "Bare Metal Debug" -> "Cortex-M3" and connect to the target
5. More than one minute (about 70 to 100 seconds) later, I cound debug the core.
I also tried the new Eclipse-integrated 'Platform Configuration Editor' (PCE) but the tool could not find the Cortex-M3 core.
Additionally, the configuration for HiKey Board pre-installed in DS-5 also has no Cortex-M3 core.
Does anyone know why it takes so much time (waiting for timeout of something?) and how can I fix it?
Hi,
Firstly I must apologise for the delay in you getting a response to your issue.
Next, I can reproduce both the issues you report, namely :
i) that PCE does not detect the Cortex-M3 whereas dbhw_config does, and
ii) that connecting to the Cortex-M3 on the HiKey board takes at least 45s....but only when the core is running!
I have raised a defect for the DS-5 Engineering team to look at and also for the 2nd issue. As the 2nd issue is what you are concerned about, I am also trying to look into this.
Also I tried removing all the other Cortex processors & trace infrastructure on the device, so there was just the Cortex-M3 but this made no change.
It still took a long time.
I have a log that shows all the memory accesses that DS-5 makes along with timing information so I shall continue to look into this. It is very peculiar.
We shall continue to look into this and let you know of any updates.
Regards,
Stuart
Hi again,
We have a deeper look into this and it looks the core is taking around 0.5s to respond to each memory or register access when it is running the code that is in ROM.
It believed that there is some power control (perhaps Deep Sleep) that is going on, and each time the core is woken up, services the request then goes back to sleep again.
As I mentioned yesterday, once connected, if you then halt the core, disconnect and then re-connect, you will connect very quickly.
To test the theory that it might be code running that is influencing this behaviour, I patched some code into the stack space and set the PC to that code and then set the core running.
There is some internal RAM at address 0x3000 and it looks like this is filled with ASCII 'U' (0x55). If you patch in the following assembler :
0x3601 ;ADDS r6, #1
0xE7FD ; B {pc}-2
into a half-word aligned location (I used 0x3010) and then set the PC to the address of the ADDS instruction and set the code running and then disconnect....
When you reconnect you will see that the connection time is <5s (typically about ~1s).
So it looks like it is the code that is being run from ROM in conjunction with a aggressive power-saving regime that is causing the slow connection.
As the device is not from ARM, ARM are not able to comment on how this issue might be resolved as clearly it would need knowledge of the device which we do not have.
I hope this answers your question as to the excessive time taken to connect and I must apologise again for the time taken to get an answer for you.
Hi, Stuart,
Thank you for your reply. Your answer resolved my question.
I tried your infinite loop code to make Cortex-M3 keep awake and it worked as expected.
(Just "0xE7FE ; B {pc}" was enough.)
Shunsuke SASAKI