search

pyocd / pyOCD

Open source Python library for programming and debugging Arm Cortex-M microcontrollers
https://pyocd.io
Apache License 2.0
1.13k stars 484 forks source link

Musca-B1 reset and halt issue #841

Open flit opened 4 years ago

flit commented 4 years ago

(Issue reported by @danielRep.)

Hi,

I am experience a similar issue with a Musca B1 board. I detect three different behaviours which probably can be related with the same issue that @djj198 reported. One, the gdbserver is initiated and pyocd is connect but the flashing operation doesn't start (it seems stuck), with the DAP LED blinking indefinetly. Second, the debug process passes all stages (w/o any outputted error) but the core seems to be in a wrong state. Third, the pyocd effectively outputs the following error, which is quite similar to @djj198 post.

My pyocd version is 0.24.1-dev15. 

0001283:INFO:gdbserver:GDB server started on port 3333
Started by GNU MCU Eclipse
0001289:INFO:server:Semihost server started on port 4445
0001290:INFO:gdbserver:GDB server started on port 3334
Started by GNU MCU Eclipse
0002328:INFO:gdbserver:One client connected!
0004534:ERROR:gdbserver:Unhandled exception in handle_message: 
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/gdbserver/gdbserver.py", line 379, in handle_message
    reply = handler(msg[msgStart:])
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/gdbserver/gdbserver.py", line 887, in handle_query
    return self.handle_remote_command(cmd)
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/gdbserver/gdbserver.py", line 1009, in handle_remote_command
    self.target.reset_and_halt()
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/coresight/cortex_m.py", line 966, in reset_and_halt
    xpsr = self.read_core_register('xpsr')
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/coresight/cortex_m.py", line 1033, in read_core_register
    regValue = self.read_core_register_raw(regIndex)
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/coresight/cortex_m.py", line 1047, in read_core_register_raw
    vals = self.read_core_registers_raw([reg])
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/coresight/cortex_m.py", line 1107, in read_core_registers_raw
    assert dhcsr_val & CortexM.S_REGRDY
AssertionError
0004546:INFO:gdbserver:Attempting to load Argon
0004547:INFO:gdbserver:Attempting to load FreeRTOS
0004548:INFO:gdbserver:Attempting to load Zephyr
0004549:INFO:gdbserver:Attempting to load RTX5
0006579:ERROR:gdbserver:Unhandled exception in handle_message: 
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/gdbserver/gdbserver.py", line 379, in handle_message
    reply = handler(msg[msgStart:])
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/gdbserver/gdbserver.py", line 598, in v_command
    return self.flash_op(data)
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/gdbserver/gdbserver.py", line 714, in flash_op
    self.flash_loader.commit()
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/flash/loader.py", line 168, in commit
    keep_unwritten=self._keep_unwritten)
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/flash/builder.py", line 417, in program
    self._build_sectors_and_pages(keep_unwritten)
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/flash/builder.py", line 315, in _build_sectors_and_pages
    fill_end_of_page_gap()
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/flash/builder.py", line 259, in fill_end_of_page_gap
    self._enable_read_access()
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/flash/builder.py", line 221, in _enable_read_access
    self.flash.init(self.flash.Operation.VERIFY)
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/flash/flash.py", line 235, in init
    self.target.reset_and_halt(Target.ResetType.SW)
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/core/coresight_target.py", line 387, in reset_and_halt
    return self.selected_core.reset_and_halt(reset_type)
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/coresight/cortex_m.py", line 966, in reset_and_halt
    xpsr = self.read_core_register('xpsr')
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/coresight/cortex_m.py", line 1033, in read_core_register
    regValue = self.read_core_register_raw(regIndex)
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/coresight/cortex_m.py", line 1047, in read_core_register_raw
    vals = self.read_core_registers_raw([reg])
  File "/usr/local/lib/python3.6/dist-packages/pyocd-0.24.1.dev15-py3.6.egg/pyocd/coresight/cortex_m.py", line 1107, in read_core_registers_raw
    assert dhcsr_val & CortexM.S_REGRDY
AssertionError
0006605:INFO:gdbserver:Client detached
0006606:INFO:gdbserver:Client disconnected!
Started by GNU MCU Eclipse

EDIT: I would mention that the DAPLink firmware is version 0242. EDIT2: FYI @flit, the board seems to work properly with older version 0.21.0 EDIT3: @flit after some investigation I can confirm that the commit with id b49611b, which supposedly enables the software reset feature has broken the use of pyocd with the MUSCA B1 board. At least is what I experienced. I just jumped to the release v0.24.0 and removed that code segment, and everything went well again (on v0.24.1 that workaround didn't work).

flit commented 4 years ago

@danielRep

We're using B1 pretty regularly for some development work, using eFlash. Odd that we're not seeing this error.

Without the code to enable RESET_MASK.SYSRESETREQ0, a software reset via AIRCR.SYSRESETREQ is a no-op. Thus it "succeeds" by not causing any change in the device. You also cannot use a hardware reset because that resets debug logic, killing the connection.

The exception shown in your log is caused by a failure to read core registers. It occurs at two points before pyocd bombs out, when it reads xPSR after a reset and halt. First is when gdb sends the "reset halt" monitor command. Second is as the flash algo is initialized. Each case will cause an error to be reported to gdb, which eventually gives up and detaches.

So the question is, why does a reset and halt cause a failure to read registers in your case but not for us?

Are you attempting to run code from QSPI or eFlash? Do you have any code in the other memory?

flit commented 4 years ago

Oops, didn't mean to close…

danielRep commented 4 years ago

First, thank you @flit for opening a proper issue for this, should have done it since the beginning. Since I reported that issue, I have been using pyocd and GNU MCU Eclipse altogether to develop to Musca-B1. I don't use either QSPI or eFlash for now. Even though that I required to run my solution from SRAM memories, I feel that I have a more stable development environment if I don't use flash memories.

So as of now, this is my setup:

Without the code to enable RESET_MASK.SYSRESETREQ0, a software reset via AIRCR.SYSRESETREQ is a no-op. Thus it "succeeds" by not causing any change in the device. You also cannot use a hardware reset because that resets debug logic, killing the connection.

I understand that, and every time that initiate a new debug session, I press the reset button of the board and start the session. I never use the software reset, for that the reason that you mention and since I am still using version 0.25.0

Are you attempting to run code from QSPI or eFlash? Do you have any code in the other memory?

As I mentioned previously I am running my software from the SRAM memories, so I use neither one of the flash memories.

Maybe the details that I provided won't help that much. I can try to upgrade pyocd to the last version and see if I still have any type of issues. I still didn't do that since I am having a more or less stable development setup.

flit commented 4 years ago

Thanks for the info. The major difference between your setup and ours is that you are running out of SRAM.

Do you know if there is any code in eFlash or QSPI? You can check by using pyocd commander and running rw 0x1000_0000 32 (check QSPI) and rw 0x1A00_0000 32 (check eFlash).

I'll see if I can set up a GME project to reproduce. It may take a few days to fit it in.

danielRep commented 4 years ago

Hi @flit ,

I am sorry for the late reply, but I only had the opportunity to check your tip today. The output that I got was:

rw 0x1000_0000 32 10000000: 30000500 00000000 00000000 00000000 0............... 10000010: 100009b0 10000981 100009b1 100009b1 ................

rw 0x1A00_0000 32 1a000000: 30000548 1a000d5d 1a000ced 1a000cb1 0..H...]........ 1a000010: 1a000cb1 1a000cb1 1a000cb1 1a000cb1 ................

Which means that the processor is jumping to those reset handler addresses probably right? I don't know at which point on time, but I suppose that there is something related to it.

PS: in another subject, do you have Musca-A1 ou B1 DAPLink last firmware binaries that you could attach?