Error: invalid response while writing the register 0x0d (count = 1, value = 7)

[UweBonnes]

Running on the MIMRXT1060, some register access fails fatal: Debugger: 1.10 (S) Clock frequency: 16.0 MHz

Breakpoint 1, dap_write_reg (reg=reg@entry=5 '\005', data=data@entry=1073829888) at dap.c:413 413 error_exit("invalid response while writing the register 0x%02x (count = %d, value = %d)", (gdb) bt

0 dap_write_reg (reg=reg@entry=5 '\005', data=data@entry=1073829888) at dap.c:413

1 0x0000000000401a83 in dap_read_word (addr=addr@entry=1073829888) at dap.c:470

2 0x0000000000405fe0 in target_select (options=0x60e180 ) at target_st_stm32g0.c:182

3 0x00000000004028d1 in main (argc=, argv=) at edbg.c:496

(gdb) n Error: invalid response while writing the register 0x05 (count = 0, value = 7)

In my BMP setup using dbg_xxx.c and dap.c, accesses to 0x400xyyyy also fail fatal. These accesses happen when the probe tests for the STM32F0. STM32L0 and LPC43 Idcode registers. I have not found a way to recover after that failure. Do you have any idea?

[ataradov]

What is the actual target device? Is reset line connected as well?

Value =7 means that that SWDIO line was high all the time. This can happen for a lot of reasons including actually missing or incorrect connections to the target device.

[UweBonnes]

I am quite sure the connections are right. My CMSIS variant of the BMP can do a lot of transactions and scan the ROM Table. Hoewever similar errors happen whensome memory in the 0x400xyyy region is read. Another indication is, that pyocd can access the device ROMTABLE though the same on board cmsis debug access

I know that transaction may fail, but a way to recover from that situation is needed.

[ataradov]

edbg is not designed to be a long-running application. It stops on the first detected error. This is by design and will not change.

If this memory region on the target does not contain useful memories/peripherals, the failures are to be expected.

I'm working on a standalone debugger that would properly handle situations like that, but it is a lower priority project at the moment.

[UweBonnes]

Hello,

I can fix the problem by sending an abort message when a fault happens: diff --git a/dap.c b/dap.c index f0e1afb..663e84b 100644 --- a/dap.c +++ b/dap.c @@ -331,7 +331,10 @@ uint32_t dap_read_reg(uint8_t reg) buf[2] = 0x01; // Request size buf[3] = reg | DAP_TRANSFER_RnW; dbg_dap_cmd(buf, sizeof(buf), 4);

• if ((1 == buf[0]) & (buf[1] == DAP_TRANSFER_FAULT)) {
• dap_write_reg(SWD_DP_W_ABORT, DP_ABORT_STKCMPCLR | DP_ABORT_STKERRCLR | DP_ABORT_ORUNERRCLR);
• buf[1] = DAP_TRANSFER_OK;
• }

[UweBonnes]

B.t.w, Blackmagic Debug probe is a stand alone debugger. I get my cmsis_dap variant, using your dbg and dap, to recognize the LPC845 M0+. A "pyocd gdb" run after plug is mandatory, due to the other issue. Attaching to the target does not work yet.

[ataradov]

Again, I know how to recover from the error. This is just not what edbg is designed to do. edbg is not a debugger, it is a programmer. A programmer should never write into locations that cause error. This is ensured by the design of the programming code.

Feel free to use this project as a starting point for whatever you do, but those changes will not be accepted into the main project.

[ataradov]

Also, what is the point of just clearing the error? Your read has still failed and you don't have the correct value. The calling code will still fail.

[UweBonnes]

But I use dap and dbg , not edbg. It would be usefull, if dap can handle that fault. It would be up to edbg to act appropriate.

[ataradov]

Well, this is a complete project and it only includes parts that are necessary for its purpose. Just adding unnecessary functionality is how you get bloat that you need to maintain later.

I do have a WAY more robust version of this code for the debugger project. That will be released at some point. But this project will remain as it is right now, unless it is necessary for the programming.

[UweBonnes]

A debugger that tries to detect an unknown target probes at different memory addresses. E.g. to detect a LPC11xx it probes LPC11XX_DEVICE_ID0x400483F4. The RT1062 chokes on that probe. And b.t.w, BMP on PC hosted platforms now can act as command line programmer, without -t target on the command line.

[ataradov]

There is no detecting for a programmer. The target is explicitly specified in the command line. This is by design and will not change. If this does not work for you, then this is a wrong project.

[UweBonnes]

Well, I use dbg and dap in the context of another debugger (BMP). It does detect the target.

I neither want to change your edbg or your debugger. But if we can avoid the need of a fork of dbg and dap, I think this will will help both sides.

[ataradov]

I don't see how it helps this project at all. It just introduces additional code that will never be used.

[UweBonnes]

You can try https://github.com/UweBonnes/blackmagic/tree/multi . "make PROBE_HOST=hosted" should compiled to a PC executable when libusb1, libftdi and libhidapi are available. I should detect CMSIS-DAP , BMPs, Stlinkv2/3, JLink and with hints libftdi dongles and either provide a gdb server at :2000 or with additional arguments allows to e.g. detect attached device (blackmagic -t) or flash (blackmagic .bin). As high level CMSIS DAP commands are used, speed is decent. On MIXRT10xy boards I read about 80 kB/s from the device. I dropped libhid as the approach with libhidapi allowed me to fix memory leaks much faster.

Maybe some of devices supported by edbg are not yet supported in BMP, but pull request to BMP are welcome.

[ataradov]

@InnovativeIdeas What is the specific error message?

All SAMD10 devices are supported, so in this case "Invalid response received" has nothing to do with part support. It is a low level message indicating general connectivity error with the part.

[InnovativeIdeas]

thanks

whats interesting is the utility works fine on the ATSAMC21 explorer board and does not work at all on the ATSAMD10 explorer mini , Equally this board doesn't work properly with openocd ( its fails to reset the board ) . While both are supposed to be mEDBG, I read somewhere that they may actually be different formats

great repository regards

Dave

On 13 May 2020, at 16:11, Alex Taradov notifications@github.com wrote:

@InnovativeIdeas https://github.com/InnovativeIdeas What is the specific error message?

All SAMD10 devices are supported, so in this case "Invalid response received" has nothing to do with part support. It is a low level message indicating general connectivity error with the part.

[ataradov]

mEDBG is using the same protocol. This tool works on my board.

I've seen some reports of other tools struggling with D10-XMINI too. So this may be something that changed on the newer boards.

One thing I would try is to increase the value in sleep_ms(10); in the function dap_reset_target_hw() to 100 and add another sleep_ms(100); at the very end of the function. See if that changes anything.

And once again, you have not told what is the actual error is.

[InnovativeIdeas]

from the D10 mini I get this message on every command “ Invalid response received “ , ie from this line I presume " check(hid_buffer[0] == cmd, "invalid response received”);”\

if I plug in the C21 explained pro , it works fine ( changing the -t target value accordingly )

dave

On 13 May 2020, at 22:00, Alex Taradov notifications@github.com wrote:

mEDBG is using the same protocol. This tool works on my board.

I've seen some reports of other tools struggling with D10-XMINI too. So this may be something that changed on the newer boards.

One thing I would try is to increase the value in sleep_ms(10); in the function dap_reset_target_hw() to 100 and add another sleep_ms(100); at the very end of the function. See if that changes anything.

And once again, you have not told what is the actual error is.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ataradov/edbg/issues/87#issuecomment-628242944, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAT2DBXUF7PM56LXXSZGKA3RRMC5HANCNFSM4JSGNCWA.

[ataradov]

"invalid response received” is a totally different issue. This looks like some sort of an error in the EDBG firmware. It is possible that something has changed in the protocol, of course, but it would not be CMSIS-DAP compliant.

Can you try to trace what the value of "cmd" is?

Also, please remove the message you are quoiting from the response. It all appears on GitHub, and it is just noise. Or reply directly on GitHub.