Unable to get basic Platformio sample to work

[hbraasch]

I would REALLY like to get the dw-link based debugger to work. I've followed the instructions as best as possible, but unfortunately hits a problem somewhere at the end. Sorry for troubling you, but would it be possible to help?

When debugging starts, it comes with the error [.pioinit:14: Error in sourced command file]. In your manual FAQ it hints towards something that needs to be corrected in the platformio.ini, which leaves me at a loss.

I guess dw-link has been loaded correctly because the status LED performs as expected, ending up with a rapid flash as soon as GDG complains. I've also installed VSC, PlatformIO on a different machine which has a much simpler setup than my dev machine (more default environment value settings), but it runs into the exact same problem.

Here is the hardware setup. The targer UNO (on the right) has its [reset on] pad cut. It appears to be powered OK by the programmer PIO pin.

Here is the screen grab when GDB complains

Attached is the platformio.ini file i'm using. I've made the three user setting changes, and I think they are working (board type and COM port)

Here is the PlatformIO project screen grab

If there is anything else I can supply, I will be glad to.

[felias-fogg]

Could you compress the entire PIO project folder and send it to me?

Cheers, Bernhard

Von meinem iPhone gesendet

Am 13.02.2022 um 01:43 schrieb Heinrich Braasch @.***>:

 I would REALLY like to get the dw-link based debugger to work. I've followed the instructions as best as possible, but unfortunately hits a problem somewhere at the end. Sorry for troubling you, but would it be possible to help?

When debugging starts, it comes with the error [.pioinit:14: Error in sourced command file]. In your manual FAQ it hints towards something that needs to be corrected in the platformio.ini, which leaves me at a loss.

I guess dw-link has been loaded correctly because the status LED performs as expected, ending up with a rapid flash as soon as GDG complains. I've also installed VSC, PlatformIO on a different machine which has a much simpler setup than my dev machine (more default environment value settings), but it runs into the exact same problem.

Here is the hardware setup. The targer UNO (on the right) has its [reset on] pad cut. It appears to be powered OK by the programmer PIO pin.

Here is the screen grab when GDB complains

Attached is the platformio.ini file i'm using. I've made the three user setting changes, and I think they are working (board type and COM port)

Here is the PlatformIO project screen grab

If there is anything else I can supply, I will be glad to.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.

[hbraasch]

220209-111942-uno.zip Hi Bernhard

Thanks for having a look at it. I’ve attached the zip file.

Regards Heinrich

[felias-fogg]

Hi Heinrich,

the platformio.ini file seems to be to OK. I could replicate the same error message on an Uno, when the RESET EN solder bridge was not cut. So, this would be my best guess now. Did you check with a Multimeter that the bridge has been cut?

Best, Bernhard

[hbraasch]

Thanks for looking into this. I've double-checked the RESET EN and it is cut (also checked it with a Multimeter).

What I find interesting is that, if I hard power the target by taking its +5V pin to the fw-link's +5V pin, I was expecting the status led to do a slow blink, requesting me to do a power cycle. That never happens. It just goes to a fast-blink.

Is there some other way to get some more diagnostics from dw-link?

Thanks and regards

[felias-fogg]

You can get more diagnostics when you use avr-gdb directly. Search for avr-gdb, select and press RETURN. This should start avr-gdb. Then type: set serial baud 115200 target remote com7 monitor dwconnect

The last command should tell the reason why the connection to the target failed.

[hbraasch]

This is what I get after running avr-gdb:

Lock bits set. Any suggestions to get past this?

Regards

[felias-fogg]

Interesting! You could try the command "monitor erase", which will erase the entire chip (including bootloader and the lock bits). The only thing I am not sure about is whether this is possible if the connection is not established yet. I should change that then, I guess. A sure thing to get rid of the lock bits is to use an ISP programmer and issue a "chip erase" command; I believe avrdude has such a command.

In any case, I could have a look tomorrow and will change dw-link so that one can do a chip erase -- if this is not possible yet.

Best, Bernhard

Am 17.02.2022 um 00:01 schrieb Heinrich Braasch @.***>:

This is what I get after running avr-gdb:

Lock bits set. Any suggestions to get past this?

Regards

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.

[hbraasch]

The [monitor erase] command worked like a charm!!! I can now debug using PlatformIO and all is excellent.

Maybe you can now mention this quirk in the manual, or even beter... have dw-link auto clear these bits if set? That will make it unnecessary for the user to install avr-dbg etc to fix the problem. Problem though, some users will not like having their UNO completely cleared... :-(

But thanks a lot for the help. Regards

[felias-fogg]

Cool! I definitely will document this in the manual. And I agree that an automatic erase is probably not what users want.

I guess I should make the following change. Currently "target remote ..." connects to the debugger and then to the target. Unfortunately, this means that I cannot return any error message when the connection to the target fails. I think I should distangle the two connection actions and leave it to the user (or the PIO script) to issue an additional monitor dwconnect command after the target remote .... In this case, the error message will be displayed, even when running it under PlatformIO. I could then add another PIO custom task that can erase the chip.

Cheers, Bernhard

[hbraasch]

Very good! Just want to mention I took a brand-new Nano and got it to work, but I also needed to erase the chip before getting it to work. So it wasn't a once off fluke. Regards Heinrich

[felias-fogg]

I probably had burned new bootloaders into mine and therefore did not experience that. Good to know!

Best regards to Down-Under, Bernhard

Am 17.02.2022 um 12:47 schrieb Heinrich Braasch @.***>:

Very good! Just want to mention I took a brand-new Nano and got it to work, but I also needed to erase the chip before getting it to work. So it wasn't a once off fluke. Regards Heinrich

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.

[hbraasch]

Problem resolved