Variables show wrong value in PIO watch pane

[BenthamSoftwareServices]

If I declare a variable e.g. int count = 0; after starting the debugger count has the value 5 in the PIO watch pane and increments correctly after each pass through loop(). I can avoid this problem by declaring int count = -5; so after starting the debugger it has the wanted value of 0 in the watch pane. Is there any explanation or solution to this issue?

[jdolinay]

Please provide some more info so I could try to reproduce this problem. Ideally the platform IO project folder or at least the source code of the program where this happens. If this happens in some large program, please try some simple program like blinking LED with such variable and see if it works there. From your description it look strange. If this was regular bug in the debugger, I think someone would already noticed and reported this. So my first guess is it could be some problem in the program, like accidentally overwriting the variable somewhere, overflow of some other variable (array), or a wrong pointer... Another reason could be some problem in the PIO debugger plugin in the way it shows the date from the debugger - in this case all other variables would probably show wrong values.

[BenthamSoftwareServices]

Thanks for getting back to me Jan, I have attached the project folder where you can see it is only a simple blink with a couple of variable increments. The addition of 5 to variables happens with both INTs and Floating Points.

VS Code version as follows:

Version: 1.91.1 (system setup) Commit: f1e16e1e6214d7c44d078b1f0607b2388f29d729 Date: 2024-07-09T22:06:49.809Z Electron: 29.4.0 ElectronBuildId: 9728852 Chromium: 122.0.6261.156 Node.js: 20.9.0 V8: 12.2.281.27-electron.0 OS: Windows_NT x64 10.0.22631

PlatformIO is version 3.3.3

The target is a NANO with the standard bootloader for NANOs provided by Arduino IDE version 2.3.2

I noticed something in your user manual about a different bootloader in your hardware folder, I think it is quite old now but should I be using that and could that be the cause of the problem?

Regards

Steve Bennett Debug_test.zip

[BenthamSoftwareServices]

Hi Jan,

I could not get my reply past Gmail's SMTP spam filters, for some strange reason, so I've added it as a comment to your GitHub issues page. If you need more info please let me know.

Thanks

Regards

Steve Bennett

Bentham Software Services

Formerly trading as PCs, TBSU Ltd & Settle Computer Shop

07790 735822 Mobile & WhatsApp

To request copies of your personal information held by Bentham IT Services and to request modification or restriction of its use please contact us.

This e-mail and any attachments transmitted with it, including replies and forwarded copies subsequently transmitted, contains information which may be confidential and which may also be legally privileged. The content of this e-mail is for the exclusive use of the individual(s) or entity named above, if you are not the intended recipient, please note that any form of distribution, copying or use of this e-mail or the information in it is strictly prohibited and may be unlawful. If you have received this e-mail in error please reply to the sender at Bentham IT Services and then delete the e-mail immediately. Any views or opinions presented are solely those of the author, and may not necessarily represent those of Bentham IT Services.

------ Original Message ------ From "Jan Dolinay" @.> To "jdolinay/avr_debug" @.> Cc "Steven Bennett" @.>; "Author" @.> Date 20/07/2024 21:02:00 Subject Re: [jdolinay/avr_debug] Variables show wrong value in PIO watch pane (Issue #55)

Please provide some more info so I could try to reproduce this problem. Ideally the platform IO project folder or at least the source code of the program where this happens. If this happens in some large program, please try some simple program like blinking LED with such variable and see if it works there. From your description it look strange. If this was regular bug in the debugger, I think someone would already noticed and reported this. So my first guess is it could be some problem in the program, like accidentally overwriting the variable somewhere, overflow of some other variable (array), or a wrong pointer... Another reason could be some problem in the PIO debugger plugin in the way it shows the date from the debugger - in this case all other variables would probably show wrong values.

— Reply to this email directly, view it on GitHub https://github.com/jdolinay/avr_debug/issues/55#issuecomment-2241279585, or unsubscribe https://github.com/notifications/unsubscribe-auth/BHE6XAEPM52WU6HYIL6UD63ZNK63RAVCNFSM6AAAAABLF5DXX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBRGI3TSNJYGU. You are receiving this because you authored the thread.Message ID: @.***>

[BenthamSoftwareServices]

An update Jan - I removed the project from the VSC workspace, moved the project folder to a new but close by location, opened the project from the new location and the incorrect variable problem has gone - how strange is that!

[jdolinay]

Hi Steve,

Thanks for the update. It is really strange. I looked at the program and it is so simple there should not be any problem. Maybe it was really something about the project location, though it seems strange. Hopefully it will stay in this working state.

To your question about the bootloader, you do not need to use it. The included bootloader is for Arduino Uno only anyway, so I am not sure if it would work with nano. But for the default configuration of the debugger (called RAM breakpoints in the manual) you do not need to update the bootloader. If you would like to use the "FLASH breakpoints" then you would need to update the bootloader. But you would need to use normal "optiboot" bootloader, not the one included. I don't remember if I ever tried this configuration with Nano, so I am not sure if it would work.

Regards

Jan Dolinay

[BenthamSoftwareServices]

Hi Jan, I spoke too soon, I was getting an error message about source files being missing for two of the four breakpoints listed, which is reasonable as I had moved the project folder. So I deleted all four breakpoints, the original two from before the move and the two new ones following the move, and then created two new ones; and unfortunately the addition of +5 to variables started again, so I'm back to declaring them as -5.

[BenthamSoftwareServices]

Hi Jan, I think I have found a solution. I was using a modern USBC Nano, so I tried an older Mini USB Nano and the variables that should have been 0 appeared as +4, I then tried changing the delay values in the blink main.cpp and got yet different variable values e.g. 1. All this made me think timing issues, so I added a substantial delay(1000); after debug_init(); and now the two variables start at 0 with either Nano and with any blink delay. So this seems like a solution, but I have no idea of a possible cause, but maybe you can suggest what it might be, could debug_init(); be finishing some operation at the same time as the blink code starts to run???

I notice that when I hover over debug_init() I get the following message, does this suggest a cause?

_void debug_init() Initialize the debugger driver ? Is this our version of set_debugtraps ? (see above) But the interrupts are re-directed in compile time, so we do not need such function.

The debugger now seems totally reliable under all conditions of code and target hardware, I can not get it to malfunction now no matter what I do, I'm really happy with your library, many thanks for creating it :)

[jdolinay]

Hi Steve, I cannot see any reason for this strange behavior. The debug_init() should not do any "background" operation which could be affected by the delay. I wonder if the problem is in the memory or in the communication. If you try to print the value using Serial.println() does the variable start at 0 or other number? You would need to comment out the debug_init() because Serial will not work together with the debugger.

Anyway, I am glad that it works now :)

[BenthamSoftwareServices]

Jan, I have now got your library working with a 2560, which as you know has 4 USARTS, as I don't think serial operations will work on a single USART NANO if the debugger library is used? However I can't get the problem with incorrect variable values to occur using the 2560, so doing a print variable test is pointless. I think I will always add 500mS delay after debug_init() whatever MCU I use as it always seems to work perfectly. Thanks for all you help and comments.

[jdolinay]

Hi Steve, you are right, the Serial will not work together with the debugger. The problem with incorrect variable values is really strange and I suspect it is somehow related to the specific hardware. The idea of adding delay() after debug_init() seems good to me. I hope the debugger will now work fine. Regards Jan