Attempt to flash or erase LPC55s28 triggers an assert

[yaraya-BR]

I hit the assert below while attempting to flash or simply erase an LPC55s28 (LPCXpresso55S28 dev board). pyOCD GDB server runs without a problem.

Attempted pyocd versions: 0.24.0, 0.25.0, and 0.26.1. (the log below is from 0.25.0)

pyocd erase -t lpc55s28 --chip -Osmart_flash=0 -vvv
0001919:DEBUG:session:Project directory: C:\Users\u106788
0002132:DEBUG:pack_target:Loading target 'lpc55s28' from CMSIS-Pack
0002151:INFO:board:Target type is lpc55s28
0002156:DEBUG:dap_access_cmsis_dap:CMSIS-DAP probe FTA0CQAR firmware version: 1.10
0002161:DEBUG:sequencer:Running task load_svd
0002186:DEBUG:sequencer:Running task create_flash
0002187:DEBUG:sequencer:Running task pre_connect
0002281:DEBUG:sequencer:Running task dp_init
0002375:DEBUG:dap:Default wire protocol selected; using SWD
0002380:DEBUG:dap:Sending deprecated SWJ sequence to select SWD
0002411:INFO:dap:DP IDR = 0x6ba02477 (v2 rev6)
0002411:DEBUG:sequencer:Running task power_up
0002415:DEBUG:sequencer:Running task find_aps
0002422:DEBUG:sequencer:Running task create_aps
0002424:DEBUG:sequencer:Running task create_ap.0
0002430:INFO:ap:AP#0 IDR = 0x84770001 (AHB-AP var0 rev8)
0002432:DEBUG:ap:AP#0 default HPROT=3 HNONSEC=0
0002434:DEBUG:ap:AP#0 implemented HPROT=f HNONSEC=1
0002439:DEBUG:sequencer:Running task create_ap.2
0002443:INFO:ap:AP#2 IDR = 0x002a0000 (proprietary)
0002443:DEBUG:sequencer:Running task find_components
0002446:DEBUG:sequencer:Running task init_ap.0
0002453:INFO:rom_table:AP#0 ROM table #0 @ 0xe00fe000 (designer=015 part=000)
0002457:INFO:rom_table:[0]<e00ff000:ROM class=1 designer=43b part=4c9>
0002457:INFO:rom_table:  AP#0 ROM table #1 @ 0xe00ff000 (designer=43b part=4c9)
0002462:INFO:rom_table:  [0]<e000e000:SCS-M33 class=9 designer=43b part=d21 devtype=00 archid=2a04 devid=0:0:0>
0002465:INFO:rom_table:  [1]<e0001000:DWT class=9 designer=43b part=d21 devtype=00 archid=1a02 devid=0:0:0>
0002468:INFO:rom_table:  [2]<e0002000:BPU class=9 designer=43b part=d21 devtype=00 archid=1a03 devid=0:0:0>
0002470:INFO:rom_table:  [3]<e0000000:ITM class=9 designer=43b part=d21 devtype=43 archid=1a01 devid=0:0:0>
0002475:INFO:rom_table:[1]<e0040000:TPIU-M33 class=9 designer=43b part=d21 devtype=11 archid=0000 devid=0:0:ca0>
0002475:DEBUG:sequencer:Running task create_cores
0002477:DEBUG:coresight_target:Creating SCS-M33 component
0002481:INFO:cortex_m_v8m:CPU core #0 is Cortex-M33 r0p3
0002488:INFO:cortex_m:FPU present: FPv5-SP
0002495:DEBUG:sequencer:Running task set_default_reset_type
0002495:DEBUG:sequencer:Running task create_components
0002495:DEBUG:coresight_target:Creating DWT component
0002499:INFO:dwt:4 hardware watchpoints
0002499:DEBUG:coresight_target:Creating BPU component
0002503:INFO:fpb:8 hardware breakpoints, 1 literal comparators
0002503:DEBUG:fpb:fpb has been disabled
0002504:DEBUG:coresight_target:Creating ITM component
0002510:DEBUG:coresight_target:Creating TPIU-M33 component
0002512:DEBUG:sequencer:Running task check_for_cores
0002513:DEBUG:sequencer:Running task halt_on_connect
0002514:DEBUG:cortex_m:halting core 0
0002518:DEBUG:sequencer:Running task post_connect
0002518:DEBUG:sequencer:Running task notify
0002518:INFO:eraser:Erasing chip...
0002523:DEBUG:cortex_m:halting core 0
0002526:DEBUG:cortex_m:set reset catch, core 0
0002527:DEBUG:cortex_m:halting core 0
0002532:DEBUG:cortex_m:reset, core 0, type=SW_SYSRESETREQ
0004560:DEBUG:session:uninit session <pyocd.core.session.Session object at 0x000001F25DEE53C8>
0004560:DEBUG:board:uninit board <pyocd.board.board.Board object at 0x000001F25D2B4748>
0004564:DEBUG:cortex_m:cannot resume: target not halted
0004569:DEBUG:pywinusb_backend:closing interface
0004569:CRITICAL:__main__:uncaught exception:
Traceback (most recent call last):
  File "c:\programdata\anaconda3\lib\site-packages\pyocd\__main__.py", line 360, in run
    self._COMMANDS[self._args.cmd](self)
  File "c:\programdata\anaconda3\lib\site-packages\pyocd\__main__.py", line 555, in do_erase
    eraser.erase(addresses)
  File "c:\programdata\anaconda3\lib\site-packages\pyocd\flash\eraser.py", line 76, in erase
    self._chip_erase()
  File "c:\programdata\anaconda3\lib\site-packages\pyocd\flash\eraser.py", line 97, in _chip_erase
    region.flash.init(region.flash.Operation.ERASE)
  File "c:\programdata\anaconda3\lib\site-packages\pyocd\flash\flash.py", line 235, in init
    self.target.reset_and_halt(Target.ResetType.SW)
  File "c:\programdata\anaconda3\lib\site-packages\pyocd\core\coresight_target.py", line 398, in reset_and_halt
    return self.selected_core.reset_and_halt(reset_type)
  File "c:\programdata\anaconda3\lib\site-packages\pyocd\coresight\cortex_m.py", line 966, in reset_and_halt
    xpsr = self.read_core_register('xpsr')
  File "c:\programdata\anaconda3\lib\site-packages\pyocd\coresight\cortex_m.py", line 1033, in read_core_register
    regValue = self.read_core_register_raw(regIndex)
  File "c:\programdata\anaconda3\lib\site-packages\pyocd\coresight\cortex_m.py", line 1047, in read_core_register_raw
    vals = self.read_core_registers_raw([reg])
  File "c:\programdata\anaconda3\lib\site-packages\pyocd\coresight\cortex_m.py", line 1107, in read_core_registers_raw
    assert dhcsr_val & CortexM.S_REGRDY
AssertionError

[flit]

That assertion indicates that the CPU is still running because pyocd failed to halt after a reset. The LPC55xx series has a boot ROM that requires some custom logic to handle this particular sequence. Since the LPC552x devices aren't supported yet by pyOCD, this logic isn't being used.

As a temporary workaround, you might try telling pyocd that the target is an LPC55S69: -tlpc55s69. This will enable the boot ROM handling code, which is common for the entire LPC55xx series.

For a real solution, there are two possible paths:

1. Support debug sequences in CMSIS Packs. This will allow pyocd to execute any custom debug logic included in the device descriptions in CMSIS Packs.
2. Add a builtin target for LPC552x devices.

I'm already working on debug sequences, so this will happen at some point. It may not be necessary to have a builtin target if debug sequences work well enough.

[yaraya-BR]

Thanks @flit for the quick reply! I attempted using lpc55s69 as target and ended up hitting a different problem. Is there anything I can do on the command line to get around this one?

pyocd erase -tlpc55s69 --chip -Osmart_flash=0 -vvv 0001289:DEBUG:session:Project directory: C:\Users\u106788 0001291:INFO:board:Target type is lpc55s69 0001295:DEBUG:dap_access_cmsis_dap:CMSIS-DAP probe FTA0CQAR firmware version: 1.10 0001299:DEBUG:sequencer:Running task load_svd 0001300:DEBUG:sequencer:Running task create_flash 0001300:DEBUG:sequencer:Running task pre_connect 0001302:DEBUG:sequencer:Running task dp_init 0001324:DEBUG:dap:Default wire protocol selected; using SWD 0001326:DEBUG:dap:Sending deprecated SWJ sequence to select SWD 0001345:INFO:dap:DP IDR = 0x6ba02477 (v2 rev6) 0001347:DEBUG:sequencer:Running task power_up 0001352:DEBUG:sequencer:Running task find_aps 0001367:DEBUG:sequencer:Running task create_aps 0001368:DEBUG:sequencer:Running task create_ap.0 0001373:INFO:ap:AP#0 IDR = 0x84770001 (AHB-AP var0 rev8) 0001377:DEBUG:ap:AP#0 default HPROT=3 HNONSEC=1 0001381:DEBUG:ap:AP#0 implemented HPROT=f HNONSEC=1 0001414:DEBUG:sequencer:Running task create_ap.2 0001418:INFO:ap:AP#2 IDR = 0x002a0000 (proprietary) 0001420:DEBUG:sequencer:Running task find_components 0001422:DEBUG:session:uninit session <pyocd.core.session.Session object at 0x0000027582B843C8> 0001424:DEBUG:pywinusb_backend:closing interface 0001428:CRITICAL:main:uncaught exception: 'init_ap.1' Traceback (most recent call last): File "c:\programdata\anaconda3\lib\site-packages\pyocd__main.py", line 360, in run self._COMMANDSself._args.cmd File "c:\programdata\anaconda3\lib\site-packages\pyocd__main__.py", line 550, in do_erase with session: File "c:\programdata\anaconda3\lib\site-packages\pyocd\core\session.py", line 299, in enter__ self.open() File "c:\programdata\anaconda3\lib\site-packages\pyocd\core\session.py", line 415, in open self._board.init() File "c:\programdata\anaconda3\lib\site-packages\pyocd\board\board.py", line 83, in init self.target.init() File "c:\programdata\anaconda3\lib\site-packages\pyocd\core\coresight_target.py", line 163, in init seq.invoke() File "c:\programdata\anaconda3\lib\site-packages\pyocd\utility\sequencer.py", line 208, in invoke resultSequence = call() File "c:\programdata\anaconda3\lib\site-packages\pyocd\utility\sequencer.py", line 131, in self._calls[name] = lambda : wrapper(orig()) File "c:\programdata\anaconda3\lib\site-packages\pyocd\target\builtin\target_LPC55S69JBD100.py", line 174, in _modify_ap1 ('set_ap1_nonsec', self._set_ap1_nonsec), File "c:\programdata\anaconda3\lib\site-packages\pyocd\utility\sequencer.py", line 160, in insert_before raise KeyError(beforeTaskName) KeyError: 'init_ap.1'

[flit]

Ah, that makes sense. Sorry I forgot about that! This is caused by the LPC552x being single-core instead of dual-core. Unfortunately there's no workaround from the command line. Let me see if I can put together a fix for you, but I might not get to it until the coming weekend.

[yaraya-BR]

Great, thank you for doing this!

[yaraya-BR]

I applied the changes in #884 pull request to target_LPC55S69JBD100.py of version 0.25.0 and below is what I got. It goes further than before but then hangs. Just putting it out there in case it helps, as this may not be valid since I don't have all the other changes currently in the head.

>pyocd erase -tlpc55s69 --chip -Osmart_flash=0 -vvv
0001517:DEBUG:session:Project directory: C:\WINDOWS\system32
0001519:INFO:board:Target type is lpc55s69
0001523:DEBUG:dap_access_cmsis_dap:CMSIS-DAP probe FTA0CQAR firmware version: 1.10
0001527:DEBUG:sequencer:Running task load_svd
0001528:DEBUG:sequencer:Running task create_flash
0001528:DEBUG:sequencer:Running task pre_connect
0001528:DEBUG:sequencer:Running task dp_init
0001551:DEBUG:dap:Default wire protocol selected; using SWD
0001553:DEBUG:dap:Sending deprecated SWJ sequence to select SWD
0001569:INFO:dap:DP IDR = 0x6ba02477 (v2 rev6)
0001572:DEBUG:sequencer:Running task power_up
0001576:DEBUG:sequencer:Running task find_aps
0001592:DEBUG:sequencer:Running task create_aps
0001593:DEBUG:sequencer:Running task create_ap.0
0001597:INFO:ap:AP#0 IDR = 0x84770001 (AHB-AP var0 rev8)
0001600:DEBUG:ap:AP#0 default HPROT=3 HNONSEC=1
0001604:DEBUG:ap:AP#0 implemented HPROT=f HNONSEC=1
0001613:DEBUG:sequencer:Running task create_ap.2
0001617:INFO:ap:AP#2 IDR = 0x002a0000 (proprietary)
0001646:DEBUG:sequencer:Running task find_components
0001647:DEBUG:sequencer:Running task init_ap.0
0001660:INFO:rom_table:AP#0 ROM table #0 @ 0xe00fe000 (designer=015 part=000)
0001670:INFO:rom_table:[0]<e00ff000:ROM class=1 designer=43b part=4c9>
0001671:INFO:rom_table:  AP#0 ROM table #1 @ 0xe00ff000 (designer=43b part=4c9)
0001706:INFO:rom_table:  [0]<e000e000:SCS-M33 class=9 designer=43b part=d21 devtype=00 archid=2a04 devid=0:0:0>
0001752:INFO:rom_table:  [1]<e0001000:DWT class=9 designer=43b part=d21 devtype=00 archid=1a02 devid=0:0:0>
0001797:INFO:rom_table:  [2]<e0002000:BPU class=9 designer=43b part=d21 devtype=00 archid=1a03 devid=0:0:0>
0001811:INFO:rom_table:  [3]<e0000000:ITM class=9 designer=43b part=d21 devtype=43 archid=1a01 devid=0:0:0>
0001813:INFO:rom_table:[1]<e0040000:TPIU-M33 class=9 designer=43b part=d21 devtype=11 archid=0000 devid=0:0:ca0>
0001813:DEBUG:sequencer:Running task create_cores
0001817:INFO:cortex_m_v8m:CPU core #0 is Cortex-M33 r0p3
0001823:INFO:cortex_m:FPU present: FPv5-SP
0001829:DEBUG:sequencer:Running task enable_traceclk
0001833:DEBUG:sequencer:Running task create_components
0001833:DEBUG:coresight_target:Creating DWT component
0001837:INFO:dwt:4 hardware watchpoints
0001838:DEBUG:coresight_target:Creating BPU component
0001842:INFO:fpb:8 hardware breakpoints, 1 literal comparators
0001842:DEBUG:fpb:fpb has been disabled
0001843:DEBUG:coresight_target:Creating ITM component
0001846:DEBUG:coresight_target:Creating TPIU-M33 component
0001848:DEBUG:sequencer:Running task check_for_cores
0001848:DEBUG:sequencer:Running task halt_on_connect
0001849:DEBUG:cortex_m:halting core 0
0001851:DEBUG:sequencer:Running task post_connect
0001851:DEBUG:sequencer:Running task notify
0001851:INFO:eraser:Erasing chip...
0001852:DEBUG:cortex_m:halting core 0
0001864:DEBUG:cortex_m:reset, core 0, type=SW_SYSRESETREQ
0001907:DEBUG:cortex_m:resuming core 0
0001908:DEBUG:manager:added=[] removed=[]
0001909:DEBUG:manager:bps after flush={}
0001919:DEBUG:cortex_m:resuming core 0
0001920:DEBUG:manager:added=[] removed=[]
0001920:DEBUG:manager:bps after flush={}

[flit]

Thanks for testing! It looks like it's hanging while waiting for the chip erase to complete.

This might not be specific to the LPC55S28. There have been reports of some lingering issues with flash programming in certain cases, and I think I saw this same hang a couple days ago. Unfortunately it's been very intermittent and difficult to reproduce. (I just tried a bunch of chip erases on my LPC55S69 without issue.)

I'm not sure if this will change anything, but you might try other flash operations like sector erase and programming something.

[yaraya-BR]

I updated to head and tried again. No luck with sector erase or flashing attempt. It all fails at the same place, and every time. I guess there is some difference b/n LPC5528 and S69 with regards to erase. Is there another issue that is open for the erase hang? The halt failure is resolved so closing this particular issue. Thanks for the great support.

[flit]

Fyi, I went ahead and added LPC55S28 support in #885. I also updated the flash algo used for LPC55S69 to the latest from NXP.

It turns out that the flash algos for '28 and '69 are almost exactly the same (just for the code). There's only 1 byte that differs between the two. Hopefully the new version of the algo will fix the hang, but if not then it must be that intermittent bug.

[flit]

Fyi, I went ahead and added LPC55S28 support in #885. I also updated the flash algo used for LPC55S69 to the latest from NXP.

It turns out that the flash algos for '28 and '69 are almost exactly the same (just for the code). There's only 1 byte that differs between the two. Hopefully the new version of the algo will fix the hang, but if not then it must be that intermittent bug.