PN7642 unable to connect debug after programming and power cycle

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

PN7642 unable to connect debug after programming and power cycle

1,453件の閲覧回数
clittle
Contributor I

We are using the PN7642 on a design. We can connect and debug the MCU on first use, but then on subsequent powerup we can no longer connect the debugger to the MCU. We are using a JLink which appears to identify the processor but cannot halt it.

We have tried multiple prototype boards and multiple jlinks.

 

Any next steps? Debug log below:

===================

Connecting to J-Link...

J-Link is connected.

Device "PN7642" selected.

Firmware: J-Link V11 compiled Dec 4 2023 10:22:45

Hardware: V11.00

S/N: 601018409

Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB

Checking target voltage...

Target voltage: 3.30 V

Listening on TCP/IP port 2339

Connecting to target...

Found SW-DP with ID 0x6BA02477

DPIDR: 0x6BA02477

CoreSight SoC-400 or earlier

Scanning AP map to find all available APs

AP[1]: Stopped AP scan as end of AP map seems to be reached

AP[0]: AHB-AP (IDR: 0x84770001)

Iterating through AP map to find AHB-AP to use

AP[0]: Core found

AP[0]: AHB-AP ROM base: 0xE00FE000

CPUID register: 0x410FD214. Implementer code: 0x41 (ARM)

Feature set: Mainline

Cache: No cache

Found Cortex-M33 r0p4, Little endian.

FPUnit: 8 code (BP) slots and 0 literal slots

Security extension: implemented

Secure debug: disabled

CoreSight components:

ROMTbl[0] @ E00FE000

[0][0]: E00FF000 CID B105100D PID 000BB4C9 ROM Table

ROMTbl[1] @ E00FF000

[1][0]: E000E000 CID B105900D PID 000BBD21 DEVARCH 47702A04 DEVTYPE 00 Cortex-M33

[1][1]: E0001000 CID B105900D PID 000BBD21 DEVARCH 47701A02 DEVTYPE 00 DWT

[1][2]: E0002000 CID B105900D PID 000BBD21 DEVARCH 47701A03 DEVTYPE 00 FPB

[1][3]: E0000000 CID B105900D PID 000BBD21 DEVARCH 47701A01 DEVTYPE 43 ITM

[1][5]: E0041000 CID B105900D PID 002BBD21 DEVARCH 47724A13 DEVTYPE 13 ETM

[1][6]: E0042000 CID B105900D PID 000BBD21 DEVARCH 47701A14 DEVTYPE 14 CSS600-CTI

[0][1]: E0045000 CID B105900D PID 004BB907 DEVARCH 00000000 DEVTYPE 21 ETB

[0][2]: E0045000 CID B105900D PID 004BB907 DEVARCH 00000000 DEVTYPE 21 ETB

[0][3]: E0044000 CID B105900D PID 002BB909 DEVARCH 00000000 DEVTYPE 22 ATBR (?)

[0][4]: E0046000 CID B105900D PID 005BB906 DEVARCH 00000000 DEVTYPE 14 CTI (?)

Halting core...

CPU could not be halted

Halting target device failed. Trying again with reset

ResetTarget() start

ResetTarget: Halting CPU

CPU could not be halted

Target is not halted!

CPU could not be halted

0 件の賞賛
返信
8 返答(返信)

1,043件の閲覧回数
Parmiss
Contributor I

Hi @clittle ,


Have you been able to fix this? I had the same issue with PN76_Common_Wait(50); but on the OM27642 devkit and now my devkit is stuck and cpu cannot be halted.
Do you have any updates @Fabian_R ?

Best regards,
Parmiss

0 件の賞賛
返信

1,036件の閲覧回数
clittle
Contributor I
I never found a fix. I removed the one call to PN76_Common_Wait(50); and that prevented the reset. Our application was for simple evaluation so this was good enough for what we needed.
0 件の賞賛
返信

1,022件の閲覧回数
Parmiss
Contributor I

Thanks for your reply.

I hope you can answer this too. You said that lpuart example was working on EVK for you. Did you connect the UART pins directly to PC and use a serial terminal to send/receive packets? Or did you have the LPC55S16-EVK that is mentioned in the datasheet to host the uart interface?

Regards.

0 件の賞賛
返信

1,020件の閲覧回数
clittle
Contributor I
Connected the UART pins direct to the PC with a USB to TTL serial adapter if I remember correctly.
0 件の賞賛
返信

1,018件の閲覧回数
Parmiss
Contributor I

I did the same and removed the wait function but could get some junk data only. I was even getting interrupts for receiving data but then the receive operation was failing. The baud rate was right so I think an internal clock could be the problem.
But now I can't even use the evk anymore as cpu cannot be halted.

Thanks for your help. Hope I can get some support.

0 件の賞賛
返信

1,432件の閲覧回数
Fabian_R
NXP TechSupport
NXP TechSupport

Hello sir,
This is Fabian, I have been assigned to support your case.
Is it possible that the J-Link isn't able to halt the M33 due to the application? Have you tried to send the HALT directly from the J-Link commander? Also, is possible to put the chip in ISP mode to check if the J-Link can flash it?

Best Regards,
Fabian
0 件の賞賛
返信

1,430件の閲覧回数
clittle
Contributor I

Hi Fabian, thanks for the response.

We are currentrly using the lpuart_polling sdk example to keep it simple. 

I tried using jlink commander and with our board connect works but halt and reset it is not able to do. This also works fine on the devkit. I put the commander output below.

Can you share how to get the PN7642 into ISP mode? I only found mention of it in the datasheet but no details.

Thanks!

 

SEGGER J-Link Commander V7.94a (Compiled Dec 6 2023 16:07:38)
DLL version V7.94a, compiled Dec 6 2023 16:06:16

Connecting to J-Link via USB...O.K.
Firmware: J-Link V9 compiled May 7 2021 16:26:12
Hardware version: V9.20
J-Link uptime (since boot): N/A (Not supported by this model)
S/N: 59200407
License(s): GDB
VTref=3.290V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: PN7642
Type '?' for selection dialog
Device>
Please specify target interface:
J) JTAG (Default)
S) SWD
T) cJTAG
TIF>s
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "PN7642" selected.


Connecting to target via SWD
Found SW-DP with ID 0x6BA02477
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[1]: Stopped AP scan as end of AP map seems to be reached
AP[0]: AHB-AP (IDR: 0x84770001)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FE000
CPUID register: 0x410FD214. Implementer code: 0x41 (ARM)
Feature set: Mainline
Cache: No cache
Found Cortex-M33 r0p4, Little endian.
Cortex-M (ARMv8-M and later): The connected J-Link (S/N 59200407) uses an old firmware module that does not handle I/D-cache correctly. Proper debugging functionality cannot be guaranteed if cache is enabled
FPUnit: 8 code (BP) slots and 0 literal slots
Security extension: implemented
Secure debug: disabled
CoreSight components:
ROMTbl[0] @ E00FE000
[0][0]: E00FF000 CID B105100D PID 000BB4C9 ROM Table
ROMTbl[1] @ E00FF000
[1][0]: E000E000 CID B105900D PID 000BBD21 DEVARCH 47702A04 DEVTYPE 00 Cortex-M33
[1][1]: E0001000 CID B105900D PID 000BBD21 DEVARCH 47701A02 DEVTYPE 00 DWT
[1][2]: E0002000 CID B105900D PID 000BBD21 DEVARCH 47701A03 DEVTYPE 00 FPB
[1][3]: E0000000 CID B105900D PID 000BBD21 DEVARCH 47701A01 DEVTYPE 43 ITM
[1][5]: E0041000 CID B105900D PID 002BBD21 DEVARCH 47724A13 DEVTYPE 13 ETM
[1][6]: E0042000 CID B105900D PID 000BBD21 DEVARCH 47701A14 DEVTYPE 14 CSS600-CTI
[0][1]: E0045000 CID B105900D PID 004BB907 DEVARCH 00000000 DEVTYPE 21 ETB
[0][2]: E0045000 CID B105900D PID 004BB907 DEVARCH 00000000 DEVTYPE 21 ETB
[0][3]: E0044000 CID B105900D PID 002BB909 DEVARCH 00000000 DEVTYPE 22 ATBR (?)
[0][4]: E0046000 CID B105900D PID 005BB906 DEVARCH 00000000 DEVTYPE 14 CTI (?)
Memory zones:
Zone: "Default" Description: Default access mode
Cortex-M33 identified.
J-Link>halt
CPU could not be halted
J-Link>reset
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Reset: ARMv8M core with Security Extension enabled detected.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Core did not halt after reset, halting it manually.
Reset: Core did not halt after reset, trying to disable WDT.
Reset: ARMv8M core with Security Extension enabled detected.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Core did not halt after reset, halting it manually.
Reset: CPU did not halt after reset.
Reset: Using fallback: Reset pin.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via reset pin
Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?).
Reset: Reconnecting and manually halting CPU.
Found SW-DP with ID 0x6BA02477
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FE000
CPUID register: 0x410FD214. Implementer code: 0x41 (ARM)
Feature set: Mainline
Cache: No cache
Found Cortex-M33 r0p4, Little endian.
CPU could not be halted
Reset: Core did not halt after reset, trying to disable WDT.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via reset pin
Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?).
Reset: Reconnecting and manually halting CPU.
Found SW-DP with ID 0x6BA02477
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FE000
CPUID register: 0x410FD214. Implementer code: 0x41 (ARM)
Feature set: Mainline
Cache: No cache
Found Cortex-M33 r0p4, Little endian.
CPU could not be halted
Reset: Failed. Toggling reset pin and trying reset strategy again.
Failed to attach to CPU. Trying connect under reset.
Found SW-DP with ID 0x6BA02477
SWD speed too high. Reduced from 4000 kHz to 2700 kHz for stability
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FE000
CPUID register: 0x410FD214. Implementer code: 0x41 (ARM)
Feature set: Mainline
Cache: No cache
Found Cortex-M33 r0p4, Little endian.
Reset: ARMv8M core with Security Extension enabled detected.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Core did not halt after reset, halting it manually.
Reset: Core did not halt after reset, trying to disable WDT.
Reset: ARMv8M core with Security Extension enabled detected.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Core did not halt after reset, halting it manually.
Reset: CPU did not halt after reset.
Reset: Using fallback: Reset pin.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via reset pin
Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?).
Reset: Reconnecting and manually halting CPU.
Found SW-DP with ID 0x6BA02477
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FE000
CPUID register: 0x410FD214. Implementer code: 0x41 (ARM)
Feature set: Mainline
Cache: No cache
Found Cortex-M33 r0p4, Little endian.
CPU could not be halted
Reset: Core did not halt after reset, trying to disable WDT.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via reset pin
Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?).
Reset: Reconnecting and manually halting CPU.
Found SW-DP with ID 0x6BA02477
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FE000
CPUID register: 0x410FD214. Implementer code: 0x41 (ARM)
Feature set: Mainline
Cache: No cache
Found Cortex-M33 r0p4, Little endian.
CPU could not be halted
CPU could not be halted

****** Error: Failed to halt CPU.

0 件の賞賛
返信

1,415件の閲覧回数
clittle
Contributor I

Some more info.

It looks like the call to LPUART_Init calls  PN76_Common_Wait(50); which causes the lpuart_polling example to reset the board on our proto. This code runs fine on the devkit. 

We took another prototype that had not been programmed yet and put a long for loop before LPUART_Init is called. With this programmed our prototype it would still reset when PN76_Common_Wait is called, but with the loop in there we are able to reconnect the debugger. So it appears that without the loop the proto gets stuck in a tight reset loop and the debugger not get control.

Note we also have a ticket for the LPUART_Init reset issue here: https://community.nxp.com/t5/NFC/PN7642-resets-when-calling-LPUART-Init/m-p/1785561

To resolve we need to figure out why these protos reset when PN76_Common_Wait is called from LPUART_Init but not the devkits. We also need to see if we can recover the protos that are programmed in a tight loop.

Thanks,

0 件の賞賛
返信