Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
search inside all forums
Recover S32K148 with USB-ML-ACP after JTAG Pin Reassignment
Stephan d. Dec 18, 2017 at 05:10 PM (17:10 hours)
Staff: Juan S.

  • In an attempt to lower power consumption on my NXP S32K148 I inadvertently reassigned and disabled some JTAG pins (see below).  Since flashing the device with this software load I have not been able to reconnect to the device using my USB Multilink ACP in NXP's S32 Design Studio.

    Is there a method of recovering the device?
    At the moment the device is bricked to me.

    The connections I am using to the MCU are the following.

    PTA4 JTMS_SWDIO (now disabled)
    PTC4 JTCLK_SWDCLK
    PTA10 JTDO (now disabled)
    PTC3 JTDI
    PTA5 nRST (now disabled)

    I see there is a "Kinetis Recovery Utility" with the description "Utility that attempts to restore debug functionality to NXP Kinetis processors where the RESET pin is disabled or not connected."

    I was unsuccessful getting this utility to work for me but maybe the effort was futile since the I have a S32K1xx device.

    Any help or information is appreciated.
    Stephan




    Comments

  • Hi Stephan, 

    In your code, how is the nRST signal being disabled? Is your code switching the functionality of the reset pin to a GPIO? or was the FOPT byte programmed to disable reset pin?

    • I believe the pin was disabled.  The code I used was:
      PORTA->PCR[5] = PORT_PCR_MUX(0);   // RESET_b

      Which equates to
      PORTA->PCR[5] = 0;

      The MUX field controls the pin function and 0 disables the pin.

      From the NXP Reference Manual
      Pin Mux Control
      Not all pins support all pin muxing slots. Unimplemented pin muxing slots are reserved and may result in
      configuring the pin for a different pin muxing slot.
      The corresponding pin is configured in the following pin muxing slot as follows:
      000 Pin disabled (Alternative 0) (analog).
      001 Alternative 1 (GPIO).
      010 Alternative 2 (chip-specific).
      011 Alternative 3 (chip-specific).
      100 Alternative 4 (chip-specific).
      101 Alternative 5 (chip-specific).
      110 Alternative 6 (chip-specific).
      111 Alternative 7 (chip-specific).

      Thanks,
      Stephan

  • Hi Stephan, 

    Essentially what's happening is that your code is disabling the debug signals before the USB-ML-ACP has a chance to take control of the S32K148.

    Does your board have a reset button for the S32K148? One strategy would be to hold the reset button, hit debug in NXP's S32 Design Studio, wait half a second to a second, and then release the reset button.

    The goal is to prevent any of the code on the S32K148 to execute prior to the USB-ML-ACP forcing the S32K148 into debug.

    Please try the strategy I just outlined, it may take a few tries.

    • Hi Juan,

      I have tried what you suggested (using the power supply instead of a reset button) and after several minutes of trying I was able to access the MCU and reflash with fixed firmware.

      Thanks for your help.

      Stephan

  • Awesome! I'm glad the issue is resolved.

Add comment


   Want to comment? Please login or create a new PEMicro account.







© 2018 P&E Microcomputer Systems Inc.
Website Terms of Use and Sales Agreement