[SOLVED] 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.

  • [SOLVED] 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;
    6. // Write 35 bits (32 bits data, 2 bits addr, 1 bit RnW)
    7. u64Value = 0; // Bit0 == 0 indicates write access
    8. u64Value |= (u32RegIndex << 1);
    9. u64Value |= (u32Data << 3);
    10. u32BitPosData = JTAG_StoreDR(u64Value, 35); // Updates Data Register scan chain
    11. JTAG_WriteClocks(1); // Transition from "Update-DR" to "Run-Test/Idle" state of Debug TAP
    12. return u32BitPosData;
    13. }
    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
      6. return JLINK_CORESIGHT_ReadAP(/*3*/JLINK_CORESIGHT_AP_REG_DATA); // Read via DRW register of AP
      7. }


      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

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

    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 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

    • fcr4.JLinkScript

      (32.04 kB, downloaded 441 times, last: )

  • Hello,

    Thank you for providing additional information.
    We discussed this matter internally and found that Fujitsu/Cypress does not maintain these devices anymore.
    However we are planning to add official support for these devices within next month so you won't need any third party scripts but J-Link can handle the device internally.

    Sorry for any inconveniences caused.

    Veit_Kannegieser wrote:

    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.
    Unfortunately we are legally not allowed to ship scripts that have been altered by third parties that are not authorized by Fujitsu/Cypress in this case. However as said before support will be added officially soon so no third party scripts will be needed at all. To stay up-to-date with J-Link software releases you can subscribe here: segger.com/notification/subscribe.php?prodid=7,94

    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 Nino,

    official support sounds very promising.
    Maybe would make it working more stable in Ozone and Embedded Studio too.
    Looking forward for this!

    We will likely keep some extended variant of the script to analyze field return cases, where JTAG debug access is not permitted, but read access to some registers like GPREG1. They indicate the protection/error state of the device, and the step in bootup and kind of exception, as a private extension.