pyocd / pyocd/pyOCD

Flashing LPC5536

Open
#1,776 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1.5k
Forks
560
Avg merge
1h 41m
Merged PRs (30d)
3

Description

Controller: NXP LPC 5536
Debugger (NXP DAP debugger probe)

Problem Description :
There are actually 2 problems : )

Problem 1 : LPC5536 can be flash only using the target LPC55s36 (same family) using --target lpc5536 simply does not work.
(I can sent a trace, but I know that this target never worked properly to begin with. I have always used lpc55s36 which always worked fine.... until now :-) )

Problem 2 : If the controller is completely new (never flashed) , then the flashing fails(even with -- target lpc55s36) .

03355 D Analyze time: 0.000130 [builder]
0003355 D Using double buffer sector erase program [builder]
[                                                  ]   0%0003355 D halting core 0 [cortex_m]
0003364 D reset, core 0, type=SW_SYSTEM [cortex_m]
0005474 W Core #0 is not accessible after reset [cortex_m]
0005476 D uninit session <pyocd.core.session.Session object at 0x7fc951770b90> [session]
0005476 D uninit board <pyocd.board.board.Board object at 0x7fc9507e66f0> [board]
0005478 E Error during board uninit: [session]

I have noticed that SW_SYSRESET reset fails and I was able to track it until CortexM_LPC5500 > There is a "default reset type". I have set this to SW_CORE or SW EMULATED instead of SW_SYSRESETREQ and it will be able to flash 1 time correctly. Then I must switch back to SW_SYSRESETREQ and the flashing will work as intended.

0000952 D Analyze time: 0.000073 [builder]
0000952 D Using double buffer sector erase program [builder]
[                                                  ]   0%0000952 D halting core 0 [cortex_m]
0000961 D reset, core 0, type=SW_EMULATED [cortex_m]
0000961 D halting core 0 [cortex_m]
0000994 D resuming core 0 [cortex_m]
0000994 D added=[] removed=[] [manager]
0000994 D bps after flush={} [manager]
0000996 D reset: core was halted after non-halting reset; now resuming [cortex_m]
0000996 D resuming core 0 [cortex_m]
0000996 D added=[] removed=[] [manager]
0000996 D bps after flush={} [manager]
0001017 D resuming core 0 [cortex_m]
0001017 D added=[] removed=[] [manager]
0001017 D bps after flush={} [manager]
0001024 D resuming core 0 [cortex_m]
0001024 D added=[] removed=[] [manager]
0001024 D bps after flush={} [manager]
[                                                  ]   0%0001033 D resuming core 0 [cortex_m]
0001034 D added=[] removed=[] [manager]
0001034 D bps after flush={} [manager]
[                                                  ]   0%0001043 D resuming core 0 [cortex_m]
0001043 D added=[] removed=[] [manager]
0001043 D bps after flush={} [manager]
[                                                  ]   1%0001053 D resuming core 0 [cortex_m]

the second time flashing with the SW_CORE / SW_EMULATED

Using double buffer sector erase program [builder]
[                                                  ]   0%0000998 D halting core 0 [cortex_m]
0001007 D reset, core 0, type=SW_EMULATED [cortex_m]
0001007 D halting core 0 [cortex_m]
0001041 D resuming core 0 [cortex_m]
0001041 D added=[] removed=[] [manager]
0001041 D bps after flush={} [manager]
0001043 D reset: core was halted after non-halting reset; now resuming [cortex_m]
0001044 D resuming core 0 [cortex_m]
0001044 D added=[] removed=[] [manager]
0001044 D bps after flush={} [manager]
0001065 D resuming core 0 [cortex_m]
0001065 D added=[] removed=[] [manager]
0001065 D bps after flush={} [manager]
0006067 D halting core 0 [cortex_m]
0006070 D flash operation timed out; IPSR=3 [flash]
0006070 D uninit session <pyocd.core.session.Session object at 0x7027175ba3c0> [session]
0006070 D uninit board <pyocd.board.board.Board object at 0x7027168286b0> [board]
0006071 D resuming core 0 [cortex_m]
0006071 D added=[] removed=[] [manager]
0006071 D bps after flush={} [manager]
0006075 D closing interface [pyusb_backend]
0006076 C flash init timed out [__main__]

now the other reset type will work

0000801 D Analyze time: 0.000130 [builder]
0000801 D Using double buffer sector erase program [builder]
[                                                  ]   0%0000801 D halting core 0 [cortex_m]
0000902 D reset, core 0, type=SW_SYSTEM [cortex_m]
0001044 D reset: core was halted after non-halting reset; now resuming [cortex_m]
0001045 D resuming core 0 [cortex_m]
0001045 D added=[] removed=[] [manager]
0001045 D bps after flush={} [manager]
0001070 D resuming core 0 [cortex_m]
0001070 D added=[] removed=[] [manager]
0001070 D bps after flush={} [manager]
0001079 D resuming core 0 [cortex_m]
0001079 D added=[] removed=[] [manager]
0001079 D bps after flush={} [manager]
[                                                  ]   0%0001089 D resuming core 0 [cortex_m]
0001090 D added=[] removed=[] [manager]
0001090 D bps after flush={} [manager]
[                                                  ]   0%0001100 D resuming core 0 [cortex_m]
0001101 D added=[] removed=[] [manager]
0001101 D bps after flush={} [manager]
[                                                  ]   1%0001111 D resuming core 0 [cortex_m]
0001111 D added=[] removed=[] [manager]


I suppose that if SW_SYSRESETREQ fails, a retry is necessary with SW_CORE in order to work ... but I don't know how to modify the code in order to obtain this behavior.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the CortexM_LPC5500 reset handling and inspect how SW_SYSRESETREQ failures are reported. Reproduce the failure on a blank LPC5536 using the supplied traces, then verify that the reset sequence completes flashing when the fallback behavior is exercised.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
devtools, embedded-iot
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.