[SOLVED] Problems with loading firmware with IMX6S, CPU hang after load.

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] Problems with loading firmware with IMX6S, CPU hang after load.

    We're using JLink PRO and JLinkGDBServer on Linux to connect to our IMX6 (MCIMX6S7 CPU), however when uploading code to RAM it locks up trying to run it with a SIGTRAP on the load address.
    It needs a power cycle before JLink can connect to it again.
    The error message on failure to connect reads:

    Source Code

    1. ERROR: Could not read CP15 register.
    2. ERROR: Could not connect to target.


    The JLinkGDBServer is started with the following parameters:

    Source Code

    1. JLinkGDBServer -speed 20000 -device MCIMX6S7


    We connect with GDB use a script to setup the DRAM timings and IOMUX pad settings, in addition we run 'monitor reset' and disable the watchdog with 'monitor WriteU16 0x020bc000 = 0x30' and enable all clocks.
    After the RAM is set up we issue a 'load' command in GDB to upload the code to ram. Then use 'continue' to start the application. This is where everything crashes when using the MCIMX6S7 device parameter.

    I've read on this forum and elsewhere that we really should use the correct device with IMX CPUs, however when using 'cortex-a9' as the device type. The first load works without issues, but in order to reset the device (with 'monitor reset'), the DRAM settings and code upload must be performed twice in order to avoid the CPU jumping back into ROM code.

    So I'm thinking the restart issue might be fixed if we're able to use the correct deivce target, but we cannot get it to work.

    Any suggestions?

    The post was edited 1 time, last by KnutT ().

  • Hello,

    Thank you for your inquiry.
    Such an issue is not known to us.
    What J-Link Software versions are you currently using?
    Does updating to the latest version solve the issue?
    Are you using an eval board or custom hardware?
    If eval board, which one?
    Do you run your setup from a Windows, Linux or Mac?

    Could you provide a log file when the error happens?
    How to is described here: wiki.segger.com/Enable_J-Link_log_file

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello.

    We are currently using version 6.22d and running on Linux.

    Our hardware is custom, but we had the issue with VAR-SOM-SOLO from Variscite as well, although the symptoms were somewhat different.

    I've linked to a log file with the device set as MCIMX6S7. I find it strange that it is able to upload the binary, but then fails to read from the same addresses right after that. It terminates with a SIGTRAP on the load address right after running 'continue' in GDB.

    drive.google.com/file/d/1SkDgZ…NeVfbAwX/view?usp=sharing

    That you for your assistance.
  • Hello,

    Thank you for providing the log and additional setup info.
    I tried to reproduce the issue with a RIoTboard which has a MCIMC6S5 on it.
    For testing I used the J-Link Commander and our IDE Embedded Studio and both worked well with my J-Link.
    So I assume this issue is not related to any J-Link problem but a general setup issue.

    We're using JLink PRO and JLinkGDBServer on Linux to connect to our IMX6 (MCIMX6S7 CPU), however when uploading code to RAM it locks up trying to run it with a SIGTRAP on the load address.


    Does the issue persist when using only internal RAM?

    We connect with GDB use a script to setup the DRAM timings and IOMUX pad settings, in addition we run 'monitor reset' and disable the watchdog with 'monitor WriteU16 0x020bc000 = 0x30' and enable all clocks.


    When do you do the init and when do you do the reset? If you first init then reset, all registers will be restored to default values.
    To make sure this does not happen use the script file function AfterResetTarget() described in the J-Link user manual and add the init steps there as well.

    I've read on this forum and elsewhere that we really should use the correct device with IMX CPUs, however when using 'cortex-a9' as the device type. The first load works without issues, but in order to reset the device (with 'monitor reset'), the DRAM settings and code upload must be performed twice in order to avoid the CPU jumping back into ROM code.


    This sounds like the "generic" Cortex-A9 reset does not work on that device and this time it did not reset the external RAM init.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello, and thank you for your reply.
    Does the issue persist when using only internal RAM?
    We have only tried software in external RAM, so I do not know. I will see if I can create a small binary and test in internal RAM.
    When do you do the init and when do you do the reset? If you first init then reset, all registers will be restored to default values.
    To make sure this does not happen use the script file function AfterResetTarget() described in the J-Link user manual and add the init steps there as well.
    We do the reset before the init of course, but we have not tried the AfterResetTarget() script file function. I will take a look at it and see if it helps.