J-Link scripts for Cypress FCR4 no longer work

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

    • J-Link scripts for Cypress FCR4 no longer work

      For the __int64 removal
      [SOLVED] Error while compiling J-Link script file,
      the *.JlinkScript files for FCR4 and others have been changed.

      example:
      JLink_V612i\Samples\JFlash\ProjectFiles\Spansion\MB9DF125.JLinkScript

      C Source Code

      1. unsigned int _WriteAPDPReg(unsigned int u32RegIndex, unsigned int u32Data)
      2. {
      3. unsigned __int64 u64Value; // We need 35 bits: 32 data, 2 bit addr, 1 bit RnW
      4. unsigned int u32BitPosData;
      5. // Write 35 bits (32 bits data, 2 bits addr, 1 bit RnW)
      6. u64Value = 0; // Bit0 == 0 indicates write access
      7. u64Value |= (u32RegIndex << 1);
      8. u64Value |= (u32Data << 3);
      9. u32BitPosData = JTAG_StoreDR(u64Value, 35); // Updates Data Register scan chain
      10. JTAG_WriteClocks(1); // Transition from "Update-DR" to "Run-Test/Idle" state of Debug TAP
      11. return u32BitPosData;
      12. }
      Display All


      JLink_V632c\Samples\JFlash\ProjectFiles\Spansion\MB9DF125.JLinkScript

      C Source Code

      1. int _StoreWriteAPDPReg(unsigned int RegIndex, U32 Data) {
      2. U32 v;
      3. int BitPos;
      4. //
      5. // Write 35 bits (32 bits data, 2 bits addr, 1 bit RnW)
      6. //
      7. v = 0; // 0 indicates write access
      8. v |= (RegIndex << 1);
      9. JLINK_JTAG_StartDR();
      10. BitPos = JLINK_JTAG_WriteDRCont(v, 3);
      11. v = Data;
      12. JLINK_JTAG_WriteDREnd(v, 32);
      13. JTAG_StoreClocks(8);
      14. return BitPos;
      15. }
      Display All


      however, this make the script no longer working.

      case 6.12i:

      --- FSEU script --- OK: Debug port powered up
      ...
      --- FSEU script --- MCU reset
      --- FSEU script --- OK: ARM JTAG-DP detected (JTAG IDCODE: 0x4ba00477)
      --- FSEU script --- OK: SCCFG_STAT2_DBGRDY is set, whole MCU can now be accessed (if unsecured))
      --- FSEU script --- OK: MCU is unsecured
      --- FSEU script --- OK: Core is halted now
      --- FSEU script --- OK: Watchdog configured
      --- FSEU script --- OK: System RAM wait cycles changed
      Found 1 JTAG device, Total IRLen = 4:
      #0 Id: 0x4BA00477, IRLen: 04, IRPrint: 0x1, CoreSight JTAG-DP (ARM)
      Cortex-R4 identified.
      01000000 = 00 F0 20 E3 2D 00 00 EA 00 F0 20 E3 46 4C 42 48
      01000010 = 00 00 00 00 00 0E 8B 1C 35 30 34 30 30 30 31 30
      01000020 = 30 31 30 34 00 00 00 00 00 00 00 00 00 00 00 00
      01000030 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8C


      while 6.32c:

      --- FSEU script --- ERROR: Could not power up debug port (time-out reached)!
      ...
      Memory zones:
      Default Default access mode
      AHB-AP (AP0) DMA like acc. in AP0 addr. space
      APB-AP (AP1) DMA like acc. in AP1 addr. space
      Cortex-R4 identified.
      Memory access: CPU temp. halted: wiki.segger.com/Memory_accesses#Legacy_stop_mode

      **************************
      WARNING: CPU could not be halted
      **************************

      my questions are:
      • can you please try to reproduce?
        there seem to be more Scripts that got changed. I can find similar changes in
        MB9DF125.JLinkScript
        MB9DF126.JLinkScript
        MB9EF126.JLinkScript
        MB9EF226.JLinkScript
        CogentCSB740Board_OMAP3550.JLinkScript
        DigiConnectCoreWi-iMX51.JLinkScript
        ScriptBeagleBoard_OMAP3530.JLinkScript

        problematic also seem to be:

        C Source Code

        1. // Trigger read from RDBUFF register to shift out the wanted read data
        2. _SelDP();
        3. u32BitPosData = _StoreTriggerReadAPDPReg(3);
        4. u32Data = JTAG_GetU32(u32BitPosData + 3);


        in old versions the returned bit position was 13, now it is 0.

      • i tried to replace the helper functions to JLINK_CORESIGHT_(Read|Write)(AP|DP):

        C Source Code

        1. unsigned int _ReadViaAhb(unsigned int u32Address)
        2. {
        3. JLINK_CORESIGHT_WriteDP(/*2*/JLINK_CORESIGHT_DP_REG_SELECT, 0x00000000); // Bank 0x0 of AHB-AP (0x00) selected
        4. JLINK_CORESIGHT_WriteAP(/*1*/JLINK_CORESIGHT_AP_REG_ADDR , u32Address); // Set TAR register of AP
        5. return JLINK_CORESIGHT_ReadAP(/*3*/JLINK_CORESIGHT_AP_REG_DATA); // Read via DRW register of AP
        6. }


        this seem to help, in some cases it failed. Could be that i am using an car dashbord instead of eval board.

      • i could not find any reference in UM8001.pdf to 'defines' of the form:

        C Source Code

        1. /* Registers */
        2. __constant U32 FP_CTRL_ADDR = 0xE0002000;
        3. __constant U32 FP_COMP0_ADDR = 0xE0002008;


        are they going to stay?

      • in one case (ONSemiconductor_RSL10.JLinkScript) there seem to existed global variables?

        C Source Code

        1. /* Global variables */
        2. U32 fp_ctrl_old; /* Used to restore previous fp_ctrl value */
        3. U32 fp_comp0_old; /* Used to restore previous fp_comp0 value */
        4. U32 entry_point; /* Stores application's entry point and is set by ResetCatchSet */


        i guess that is obsolete?

      • UM8001.pdf descriptions for JLINK_JTAG_WriteDR*()
        6.12.2.29 JLINK_JTAG_WriteDRCont()
        6.12.2.30 JLINK_JTAG_WriteDREnd()
        are very similar. An example would help here, especialy for the usage of the returned bit position.

      • mostly seen with IAR: tight while loops in scripts seem to cause 'out of memory' errors in scripts.
        i have the impression that adding "SYS_Sleep(10);" to the loop body removes these problems.



      The " AHB-AP (AP0) DMA like acc. in AP0 addr. space" lines look promising for the usage of RTT/SystemView.
      Files
    • New

      Hello,

      Thank you for your inquiry.
      In J-Link software version V6.32b a Scriptfile timeout has been added to make sure that Scriptfiles can't get stuck in endless loops as some get executed on J-Link hardware.
      Could you try the FCR4 script with V6.32a and see if the behaviour changes?

      are they going to stay?

      The __constant defines are going to stay as the standard "global" defines.
      We will see if we can improve documentation in that regard.

      i guess that is obsolete?

      Yes the "old" notation will not work.


      UM8001.pdf descriptions for JLINK_JTAG_WriteDR*()
      6.12.2.29 JLINK_JTAG_WriteDRCont()
      6.12.2.30 JLINK_JTAG_WriteDREnd()
      are very similar. An example would help here, especialy for the usage of the returned bit position.

      Thank you for the feedback, we will improve our documentation in that regard.

      mostly seen with IAR: tight while loops in scripts seem to cause 'out of memory' errors in scripts.
      i have the impression that adding "SYS_Sleep(10);" to the loop body removes these problems.

      Related to the timeout that is now working properly since V6.32b.
      We are planning to add a script file function so you can increase the maximum timeout value.
      Currently it is fixed to 2 seconds.
      The shipped script files will also be updated in that regard.

      Sorry for any inconveniences caused.

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      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 contact us per e-mail.
      The following contact form can be used for this: segger.com/about-us/contact-us/

    • New

      Hello Nino,

      thank you for the answers regarding __constant, and documentantion.

      SEGGER - Nino wrote:


      In J-Link software version V6.32b a Scriptfile timeout has been added to make sure that Scriptfiles can't get stuck in endless loops as some get executed on J-Link hardware.
      Could you try the FCR4 script with V6.32a and see if the behaviour changes?

      A script timeout is very reasonable.

      However in this case the problem is that the script should not reach the timeout.
      Reason for this is that the result of the called helper function is not evaluated correctly (see the other post)
      And i have the impression the replacement functions to transfer 35 bits are not correct.

      We will add a script file function so you can increase the maximum timeout value.
      Currently it is fixed to 2 seconds.
      The shipped script files will also be updated in that regard.

      2 Seconds is a good value too, i would not change it.

      I attached a proposal of a (much changed script) that should be compatible with previous versions of J-Link software.
      Works nice with an dashboard ECU, i have no access to an eval board currently.
      Files