This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Debugging Cortex-M3 on HiKey Board with DS-5 and Dstream

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?

Parents
  • 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.

    Regards,

    Stuart

Reply
  • 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.

    Regards,

    Stuart

Children
No data