K81 execution fails with UART attached

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

K81 execution fails with UART attached

2,062 Views
deniscollis
Contributor V

My K81 project firmware communicates to a PC-hosted application via LPUART2 through an FTDI USB-to-Serial_TTL cable.

If I run in debug - i.e. Segger J-Link attached and under control of MCUXpresso's debug environment - with or without the serial cable attached, then everything works.

If I reset the K81 board with the serial cable DETACHED, then everything works.  If I attach the serial cable while the board is running, then everything continues to work.

But...   ...If I reset the K81 board with the serial cable ATTACHED, the K81 is usually unresponsive, but occasionally works.

Note: No semi-hosting (using libcr_nohost_nf.a) 

Any ideas on how to track and solve this problem?

Labels (1)
0 Kudos
Reply
9 Replies

1,731 Views
deniscollis
Contributor V

The 'occasionally works' is now deterministic.  I've discovered that:

  1. The board always runs if reset immediately after connecting the serial cable
  2. The board always fails if reset without disconnecting and reconnecting the serial cable.

So, there appears to be something coming from the PC serial port that is destabilizing the LPUART.   I also noticed in the circuit schematic that there are no external pull-up resistors on the board.  There aren't any in the USB-to-Serial cable either.  I manually patched the board by adding a pair of weak 470K pull-ups to the TX and RX lines.  That did not help at all: I probably need something a bit stronger, say, 70K-100K?

I have no idea why the problem does not manifest in debug mode.

0 Kudos
Reply

1,731 Views
bobpaddock
Senior Contributor III

Serial data on particular UARTS can send the part into the bootloader at power up.
See enabledPeripherals in the bootloader BCA in the bootloader manual.

I've run into this in the past myself. :-(

0 Kudos
Reply

1,731 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Denis Collis,

    Please add the 4.7K to 10K pull up in your NMI pin, then try it again.

    From your description, it seems your chip enter the ROM bootloader mode.

    So, make sure when your reset the chip, the NMI pin is high.


Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------


----------------------------------------------------------------------------------------------

0 Kudos
Reply

1,731 Views
deniscollis
Contributor V

Hi Kerry,

I meant that there are no external pull-up resistors on the LPUART pins on the board.  As you can see, the 10K pull-up on NMI is designed in, so I do not think we have entered ROM bootloader mode.  

NMI_pullup.jpg

Theory:
There is an immediate bus hard-fault when the MCU starts, most likely because K81 POR takes place before the hardware (power and comms) is fully stable.  In the debug environment the MCU is reset within fully stable hardware, and so the problem does not manifest.

To test theory:

  1. Connect temporary MCU reset button. (currently this is stabilized with a 4.7K pull-up and 0.001uF to GND)
    -AND- / -OR-
  2. Modify HardFault_Handler() to force a system reset after a short delay.
    #include "core_cm4.h"
    :
    __asm("nop");
    __asm("nop");
    __asm("nop");
    __asm("nop");
    __NVIC_SystemReset();

In the interim I have a procedural solution for the user:  "The device should be powered up before inserting the USB-to-serial cable into the PC host."

0 Kudos
Reply

1,731 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Denis Collis,

   Thank you for your updated information.

   I don't think the pull up in the UART pin is the key point, but the TTL-USB really influence your MCU work.

  Now, please check these points.

1. Please add the LED blinking or the GPIO toggle code, just check when your UART can't work, whether your other code, eg, LED blinky can work?

    Just make sure whether the code is stopped anywhere.

2. Please modify your FOPT, the flash address is 0x40d, you can change the code boot from the internal flash directly, instead of boot from the ROM after rest.

  pastedImage_1.png

Then download your code again.

Check whether the problem still happens or not?

3. When you connect the TTL-USB, please add the GND connect to your board GND.

4. Please also use the oscilloscope to check your NMI pin during the reset. Whether it has the pull low problem or not?

Please try it again.

If you still have question about it, please kindly let me know.


Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
Reply

1,731 Views
deniscollis
Contributor V

Hi Kerry,

Everything looks normal, except a slightly noisy power-up:

  1. OK: LED blinker working
  2. OK: BOOTSRC_SEL is 0
  3. OK: TTL_USB GND connected to board GND
  4. OK: Scope shows NMI is stable high, with about 100μs transitioning ramp from 0V to 3.3V.  However, the first 50μs of the ramp is a bit noisy.

There's no need for me to pursue this any further.  I am satisfied that I now understand how the system behaves, and this is sufficient for my immediate development needs.  The final production version will not have a serial connection to the PC (that's for the Device Test Environment only), the K81's power will be controlled by a supervisor MCU, and the entire system will be battery powered. I expect the production behavior to be stable and predictable.    

Thanks for your help, and best regards,

Denis

0 Kudos
Reply

1,731 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Denis,

    Thanks a lot for your updated information.

    So, do you mean the LED blinker working, just the TTL-USB? If yes, I suggest you also add the oscilloscope to check the UART TX pin, if the have the wave, the problem may in your TTL-USB tool side, not the MCU side. Because your MCU is still working, not blocked.


Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
Reply

1,731 Views
deniscollis
Contributor V

Hi Kerry,

What I meant is that the LED mechanism is working - it blinks when the system runs, and does not blink when the system fails.

Regards,

Denis

0 Kudos
Reply

1,731 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Denis,

   You said, your reset pin have 4.7K pull up and 0.001uF  capacitor to ground, is it right?

   If yes, please check the 0.001uF  capacitor to 0.1uF capacitor, then remove the debugger from the JTAG interface and try it again. 0.001uF  is too small.


Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
Reply