Receiving "Error loading >ARP file" on S32K3X4EVB-T172 Eval Board

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Receiving "Error loading >ARP file" on S32K3X4EVB-T172 Eval Board

跳至解决方案
1,578 次查看
hark
Contributor II

I've been flashing example projects on my S32K3X4EVB-T172 Eval Board via the micro-USB header and it's been working up until this morning. All of a sudden, the debugger is no longer able to load the flash algorithm file. I get: `Error loading .ARP file` in the debugging session's output in the Console tab. I am completely power cycling the board between flashing attempts, per the instructions. There was once when I got past this error and had another error, but I have not been able to replicate it.

Note that I cannot program the S32K344 via the 10-pin JTAG header either (using a SEGGER debugger or a PE Micro Cyclone LC). From what I've read in other forum threads, I get the sense that the board is locked up, though I don't have another fresh eval board to test that theory against. Is there a simple way to get it out of this "locked up" state?

Here is the full output in the Console tab for the terminated debug session for Port_Example_S32K344 (using the standard Debug_FLASH_PNE configuration):

Connection from "127.0.0.1" via 127.0.0.1. Connection from port "63814" to 6224
Connection from "127.0.0.1" via 127.0.0.1. Connection from port "63816" to 7224
Searching for Kernel Symbols...
rsp_qC - qSymbol: 5F74785F7468726561645F63757272656E745F707472
_tx_thread_current_ptr not found. ThreadX analysis not enabled.
rsp_qC - qSymbol: 707843757272656E74544342
pxCurrentTCB not found. FreeRTOS analysis not enabled.
Telnet server running on 127.0.0.1:51794
Unable to load libusb0.dll
Copyright 2023 P&E Microcomputer Systems,Inc.
Command Line :C:\NXP\S32DS.3.5\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_5.7.1.202309212104\win32\pegdbserver_console -device=NXP_S32K3xx_S32K344 -startserver -singlesession -serverport=7224 -gdbmiport=6224 -interface=USBMULTILINK -speed=5000 -port=UŒ
PEmicro Interface detected - Flash Version 10.98

CMD>RE

Initializing.
Target has been RESET and is active.
CMD>CM C:\NXP\S32DS.3.5\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_5.7.1.202309212104\supportFiles_ARM\NXP\S32K3xx\nxp_s32k344_1x32x980k_hse_enabled.arp

Initializing.
Initialized.

;version 1.01, 09/23/2022, Copyright 2022 P&E Microcomputer Systems, www.pemicro.com [S32K3x4_hse_enabled]

;device nxp, s32k344, 1x32x980k,desc=hse_enabled

;begin_cs device=$00400000, length=$003D4000, ram=$20400000

Loading programming algorithm ...
Error loading .ARP file : C:\NXP\S32DS.3.5\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_5.7.1.202309212104\supportFiles_ARM\NXP\S32K3xx\nxp_s32k344_1x32x980k_hse_enabled.arp at address 20400002
Error loading programming algorithm - load aborted.
Error occured during Flash programming.

Starting reset script (C:\NXP\S32DS.3.5\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_5.7.1.202309212104\supportFiles_ARM\NXP\S32K3xx\S32K344.mac) ...
REM Enable clocks for selected cores in MC_ME module (the sequence below enables all clocks).
REM Initialize RAM and DMA:
REM Initialize DMA TCD:
REM Copy valid executable code to RAM for each core to be used.
REM Enable required cores in MC_ME:
Delaying for 20mS ...
Done.

Reset script (C:\NXP\S32DS.3.5\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_5.7.1.202309212104\supportFiles_ARM\NXP\S32K3xx\S32K344.mac) completed.

PEmicro GDB Launch Failure : Error during flash programming. Terminating debug session

I've also used all the different flash algorithms that are provided for the S32K344, to no avail.

0 项奖励
回复
1 解答
1,493 次查看
hark
Contributor II

So, I ran into this issue again, but I figured it out! The micro-USB cable which plugs into the eval board CAN'T be plugged into some USB hubs. Debugging the eval board via the USB cable WON’T work when the cable is plugged into:

• Anker 4-to-1 USB type-A hub
• DELL docking station (in my case, this one: https://www.cpumedics.com/dell-k20a001-wd19tb-k20a001-k20a-wd19-thunderbolt-docking-station-with-180...)

It WILL work with:
• Dell USB-A/HDMI to USB-C hub (https://www.amazon.com/Dell-Type-C-Type-Adapter-Component/dp/B08YW13SG3)
• USB-C to USB-A direct adapter
• Of course, plugging straight into a USB-A port directly on the laptop

My problem is that my new laptop only has USB-C ports on it, so I've got a few adapters/hubs to support all the USB-A connections I have. Thankfully I thought to try another one.

Hope this helps someone!

在原帖中查看解决方案

7 回复数
1,238 次查看
Tuong
NXP Employee
NXP Employee

Dear All

I'm having same issue. I directly connect the debugger to my laptop USB port. I tried to change USB cables. I also tried on board debugger and MultilinkFX debugger with no help, the console output is same as Hark printed.

I always receive "Connection closed by the GDB server." and a runtime error pop up warning. It looks like debugger can't halt S32K344.

Please advise me.

Thank you very much.

TuongNguyen

0 项奖励
回复
1,233 次查看
juan_see
Contributor III

Hi @Tuong ,

Please make sure you follow the exact instructions detailed in section 3.2 of the following page:

https://www.nxp.com/document/guide/getting-started-with-the-s32k3x4evb-t172-evaluation-board-for-aut...

The S32K3X4EVB-T172 Eval Board has a very specific power up sequence that when followed properly, it ensures that the FS26 SBC S32K3X4EVB-T172 Eval Board on the  starts with disabled watchdog.

0 项奖励
回复
1,192 次查看
Tuong
NXP Employee
NXP Employee

Dear @Juan 

Thanks for your reply.

I did check all jumpers and power sequence are followed the Getting Started with the S32K3X4EVB-T172 guide.

The issue still remains.

Please help me.

TuongNguyen

0 项奖励
回复
1,494 次查看
hark
Contributor II

So, I ran into this issue again, but I figured it out! The micro-USB cable which plugs into the eval board CAN'T be plugged into some USB hubs. Debugging the eval board via the USB cable WON’T work when the cable is plugged into:

• Anker 4-to-1 USB type-A hub
• DELL docking station (in my case, this one: https://www.cpumedics.com/dell-k20a001-wd19tb-k20a001-k20a-wd19-thunderbolt-docking-station-with-180...)

It WILL work with:
• Dell USB-A/HDMI to USB-C hub (https://www.amazon.com/Dell-Type-C-Type-Adapter-Component/dp/B08YW13SG3)
• USB-C to USB-A direct adapter
• Of course, plugging straight into a USB-A port directly on the laptop

My problem is that my new laptop only has USB-C ports on it, so I've got a few adapters/hubs to support all the USB-A connections I have. Thankfully I thought to try another one.

Hope this helps someone!

1,507 次查看
Nikunj_Patel
Contributor I

I am also facing same issue but while flashing it through simulink. Does anyone who how to change ARP file in Simulink?

0 项奖励
回复
1,554 次查看
juan_see
Contributor III

Hi @hark , 

 

Can you try creating a blank project for the S32K344 and see if you can get past the Reset_Handler? If you are able to reach the main function on your new blank project for the S32K344, can you then go back to original project and remove all breakpoints and see if you can reach the main function?

0 项奖励
回复
1,564 次查看
hark
Contributor II

Update: I was able to get past this error by completely deleting my example project from disk and creating a new example project. There must be some configuration in the old project that was causing this. I recall this happening after I set a breakpoint to debug an issue with the program repeatedly entering the Reset handler. Maybe the breakpoint was causing the issue.

In any case, I ran the default debug configuration (Debug_FLASH) as-is, and started experiencing the "repeatedly entering the Reset handler" issue. I think my error was:

Verify error at address $00400000.
Byte in module is $FF and should be $A5.
Current content of flash does not match application to be programmed


After a little research (see this post), I changed the flash algorithm from "nxp_s32k344_1x32x1012k_hse_disabled.arp" to "nxp_s32k344_1x32x980k_hse_enabled.arp" in Debug Configurations -> PEmicro Debugger tab -> Advanced Options button.

But now I get this message:

...
Loading programming algorithm ...

WARNING - Selected .ARP file has been modified. CRC16 = $CF2E
Done.
Programming sequency is : erase, blank check, program, and verify {default}
CMD>VC
Command is inactive for this .ARP file.
VC is not implemented, falling back to VM

CMD>VM

Verifying.
Verified.

Application verified in memory. No need to reprogram.
...


Same behavior with entering the Reset handler repeatedly. I'm thinking the problem might stem from the flash algorithm. I'm going to experiment with that.

0 项奖励
回复