topic Re: Process for porting lpcxpresso54018 SDK examples to an LPC54018JBD208 package in LPC Microcontrollers

Process for porting lpcxpresso54018 SDK examples to an LPC54018JBD208 package

mitchkapa — Thu, 21 Jul 2022 21:03:47 GMT

We are working on a project where we have been doing our development on LPCXpresso54018 eval board. Yesterday we got in our custom PCBs which use the LPCXpresso54018 as a reference design (same external flash, same SDRAM, same LCD) however our custom PCB uses the *208 package. I attempted to run some of the basic SDK example programs (hello_world, gpio_led_output) on our custom PCB after changing Project Settings>MCU>package to match our part but so far have failed to get any of those to run. I can only successfully run code on our custom PCB if I use create a New Project and have the *208 selected from the start.

Are there step by step directions available for how to successfully modify an SDK example program so that it can run on the LPC54018JBD208? Thanks.

Re: Process for porting lpcxpresso54018 SDK examples to an LPC54018JBD208 package

ZhangJennie — Fri, 22 Jul 2022 04:49:54 GMT

MCUXpresso IDE user guide documents how to change MCU package type.

then go to pin config, make sure pin mux configuration correct for the new package.

I suggest you testing it with a simple led blinky demo code first, to make sure the procedure correct. If still fails, we need to connect and debug code to position where is the problem.

Thanks,

Jun Zhang

Re: Process for porting lpcxpresso54018 SDK examples to an LPC54018JBD208 package

mitchkapa — Sat, 23 Jul 2022 14:50:53 GMT

I once again tried to start from a simple SDK example (drivers->gpio_led_output) and then make all of the necessary changes (package, pin configuration) to match our processor. I am still having the same result of not being able to successfully run the code on the processor. Here is an example message that I get after running Debug:

"Break at address "0x300084c" with no debug information available, or outside of program code."

I feel like there must be one other location where a change needs to be made that is missing.

Also of note is that even after changing the package through the IDE the old package still appears within the Preprocessor Defined Symbols:

CPU_LPC54018JBD208
CPU_LPC54018JBD208_cm4
__REDLIB__
CPU_LPC54018JET180=1
XIP_IMAGE
MXL12835F
CPU_LPC54018
__USE_CMSIS
W25Q128JVFM
SERIAL_PORT_TYPE_UART=1
SDK_DEBUGCONSOLE=1
CR_INTEGER_PRINTF
PRINTF_FLOAT_ENABLE=0
__MCUXPRESSO
DEBUG

I am not sure if this is an error or is intentional. I have tried removing that entry but it does not impact the results.

Re: Process for porting lpcxpresso54018 SDK examples to an LPC54018JBD208 package

ZhangJennie — Mon, 25 Jul 2022 03:30:15 GMT

You met error when launch debug window or during debug?

Please send all the error message displayed in console window. I will check.

Thanks,

Jun Zhang

Re: Process for porting lpcxpresso54018 SDK examples to an LPC54018JBD208 package

mitchkapa — Mon, 25 Jul 2022 13:54:01 GMT

I get the error after launching Debug. It goes through the initial process but then there is never an option to Resume or Step through any code. Below I will show a screenshot of what appears in the IDE after pressing Debug and also I will paste the Console Debug messages.

Console Debug:

MCUXpresso IDE RedlinkMulti Driver v11.5 (Apr 7 2022 16:04:36 - crt_emu_cm_redlink build 11)
Found chip XML file in C:/Dev/nxp/MCUXpressoWorkspace/MCUXpressoIDE_11.5.1_7266/workspace/lpcxpresso54018_gpio_led_output/Debug\LPC54018.xml
Reconnected to existing LinkServer process.
Probe Firmware: MCU-LINK (r0FF) CMSIS-DAP V2.263 (NXP Semiconductors)
Serial Number: 42WFEAQ1VQLYB
VID:PID: 1FC9:0143
USB Path: \\?\hid#vid_1fc9&pid_0143&mi_00#9&ecd45f7&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Using memory from core 0 after searching for a good core
On debug connection - use system reset, stalling when 0x40000040 is accessed
Retask read watchpoint 1 at 0x40000040 to use for boot ROM stall
Waiting for target to stop...
Warning - processor did not halt - gave up waiting
debug interface type = CoreSight DP (DAP DP ID 2BA01477) over SWD TAP 0
processor type = Cortex-M4 (CPU ID 00000C24) on DAP AP 0
number of h/w breakpoints = 6
number of flash patches = 2
number of h/w watchpoints = 4
Probe(0): Connected&Reset. DpID: 2BA01477. CpuID: 00000C24. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Enabled.
Content of CoreSight Debug ROM(s):
RBASE E00FF000: CID B105100D PID 04000BB4C4 ROM (type 0x1)
ROM 1 E000E000: CID B105E00D PID 04000BB00C Gen SCS (type 0x0)
ROM 1 E0001000: CID B105E00D PID 04003BB002 Gen DWT (type 0x0)
ROM 1 E0002000: CID B105E00D PID 04002BB003 Gen FPB (type 0x0)
ROM 1 E0000000: CID B105E00D PID 04003BB001 Gen ITM (type 0x0)
ROM 1 E0040000: CID B105900D PID 04000BB9A1 CSt TPIU type 0x11 Trace Sink - TPIU
ROM 1 E0041000: CID B105900D PID 04000BB925 CSt ETM type 0x13 Trace Source - Core
NXP: LPC54018
DAP stride is 4096 bytes (1024 words)
Inspected v.2 External Flash Device on SPI LPC540xx_SPIFI_SFDP.cfx
Image 'LPC540xx_JEDEC_SFDP Apr 11 2022 10:50:30'
Opening flash driver LPC540xx_SPIFI_SFDP.cfx
Using SOFT reset to run the flash driver
rst - Boot ROM stall address was not accessed (but we entered debug on Halt anyway)
Flash variant 'JEDEC_SFDP_EF7018' detected (16MB = 256*64K at 0x10000000)
Closing flash driver LPC540xx_SPIFI_SFDP.cfx
Connected: was_reset=false. was_stopped=false
Awaiting telnet connection to port 3330 ...
GDB nonstop mode enabled
Opening flash driver LPC540xx_SPIFI_SFDP.cfx (already resident)
Using SOFT reset to run the flash driver
Flash variant 'JEDEC_SFDP_EF7018' detected (16MB = 256*64K at 0x10000000)
Writing 15240 bytes to address 0x10000000 in Flash
10004000 done 100% (16384 out of 15240)
Sectors written: 1, unchanged: 0, total: 1
Erased/Wrote sector 0-0 with 15240 bytes in 412msec
Closing flash driver LPC540xx_SPIFI_SFDP.cfx
Flash Write Done
Flash Program Summary: 15240 bytes in 0.41 seconds (36.12 KB/sec)
Starting execution using system reset and halt target with a stall address
Retask read watchpoint 1 at 0x40000040 to use for boot ROM stall
Boot ROM stalled accessing address 0x40000040 (restoring watchpoint 1)
Stopped (Was Reset) [Reset from Unknown]

Re: Process for porting lpcxpresso54018 SDK examples to an LPC54018JBD208 package

mitchkapa — Tue, 26 Jul 2022 21:52:19 GMT

We have an update to this problem. It appears to specifically be a problem with the SDK_2.xLPCXpresso54018 (installed version 2.8.2). If I select examples from SDK_2.x_LPCXpresso54S018 (installed version 2.11.1) I can successfully import SDK examples and change the processor package and run those examples on our custom hardware. For our project this is an acceptable solution.

Re: Process for porting lpcxpresso54018 SDK examples to an LPC54018JBD208 package

ZhangJennie — Wed, 27 Jul 2022 02:31:09 GMT

So the problem was on old SDK package. New version fix the issue. Thanks for the sharing.

Re: Process for porting lpcxpresso54018 SDK examples to an LPC54018JBD208 package

mitchkapa — Wed, 27 Jul 2022 13:22:17 GMT

Is the "non-S" SDK considered to be an older package than the S version? I have been viewing both SDKs as separate and valid. If that is not the case I think there should be some messaging or documentation to help make sure that people end up with the "S" version of the SDK. Otherwise I think people like myself who purchase the LPCXpresso54018 development board end up with the "non-S" SDK by default.

Re: Process for porting lpcxpresso54018 SDK examples to an LPC54018JBD208 package

ZhangJennie — Thu, 28 Jul 2022 03:15:26 GMT

Do you mean SDK for LPC54018 and LPC54S018?

These are two parts, not related with old or new.

S version has security feature while non-S doesn't. besides this feature, others are the same.LPC54018 can run on LPC54S018 without issue.

See below:

Thanks,

Jun Zhang

Re: Process for porting lpcxpresso54018 SDK examples to an LPC54018JBD208 package

mitchkapa — Thu, 28 Jul 2022 03:36:01 GMT

Yes that is my point although we personally do not need a corrective action for our project (because we can use the LPC54S018 SDK) I believe NXP may want to investigate and confirm if the LPC54018 SDK has some bug that prevents changing the MCU package.

Re: Process for porting lpcxpresso54018 SDK examples to an LPC54018JBD208 package

ZhangJennie — Thu, 28 Jul 2022 08:51:05 GMT

Hi mitchkapa

LPC54018 SDK hasn't been updated since SDK2.8.2

I will report it.

Thanks for bringing this problem to our attention.

Jun Zhang