News:

PROTON pic BASIC Compilers for PIC, PIC24, dsPIC33

Main Menu

Debugger

Started by RayEllam, Mar 25, 2021, 12:26 PM

Previous topic - Next topic

RayEllam

Hi All,
I remember (kind of) lots of years back there was some software from Mequanic for a runtime debugger on PICS that worked easily with PDS, you could step through code, look at registers etc etc etc. I have a PICKIT3 but would consider buying PICCKIT4, are there options of doing this without using MPLAB (yak)?

DaveS

Hi Ray
I think you mean P-ICD, by TimB, I will release a new version, after Positron has been released, hopefully.
It has restrictions, it will not work with interrupts in your code, and you need RX and TX pins free for use with the debugger.
Dave

TimB


After a too long delay I'm looking at the monitor code. I'm trying to decode the assembly I wrote 10 years ago  :(

Les is also looking to check that Proton/Positron is handling "On Debug" correctly.

Tim

RayEllam

P-ICD, yes that was it 😀 Many thanks for your hard work guys.

One question, when you say it won't work with interrupts does that mean it will disappear down a black hole if an int occurred or will simply resume to point after the int?

TimB

To give you a better understanding of how P-ICD works

P-ICD uses the a very old system built into Positron that if you use the command ON DEBUG. Positron will insert a call to a routine of our own making after every line of Positron code

eg

a = a+b
a = c+A

Will become
a = a+b
Gosub debugHandler
a = c+A
Gosub debugHandler

When the code runs and debugHandler is called it sends via usart the current stack pointer to the PC application. The PC application then decides what to do and sends the appropriate command back to the debug handler. eg you may have a break point at a section of code you want to check.
The PC program knows by analysing your source code what stack pointer address that will be. So will keep saying skip to the debug handler until it matches.
Then the PC prog may then ask the debug handler to send a variable or bunch of them back to the PC for it to display or take action on.
You can set break points in the code via the P-ICD PC application or I think say to it stop when this variable is > X

What happens with interrupts is that they will still be running what the debug handler is in operation. So for instance any code that is monitoring flags from the interrupt will be totally screwed up as that code will not run correctly timing wise.

Obviously you do not want to bloat your code with gosub debughandler inserted between every line. So you can selectively enable / disable it using Enable Debug and Disable Debug. Just use it around the code your interested in.

One other neat feature from memory is you can change variables externally. E.g Want to see what happens when a variable reaches value? You would Stop before that code point. Change the variable and see what happens.

Like I said I trying to decipher my asm and convert it back to Positron to make the testing easier for Dave.
 
Tim

RayEllam

Hi Tim,
Many thanks for the detailed information. I have used P-ICD many years ago and did find it useful, your description has clarified it's use and i look forward to using it again in the future.

Good luck with the ASM ;-)

Ray

RGV250

Hi Dave,
I was really pleased to hear this announcement, after the compiler it was the most useful thing I have used.
I have the full VSM but that does not do CAN which I find really disappointing and don't see that happening in my lifetime.
A couple of questions.
Will it work with PIC24 (Positron16).
I recall the main problem for me with your last one was the need for a USB serial with DTR pin?, is this still the same.
Regards the interrupt issue, would it work if you turned the interrupt off before the debug statement and back on after.
If so could this be built into the debugger.

Regards,
Bob



TimB


Bob
I know your question was addressed to Dave but I may have some answers.

Ref Positron24 It depends if Les has implemented On Debug. Then a Debug handler would need to be written and adjusted. Eg the current one has the ability to read Eeprom, It may cause a compile error if used on 16bit device. As for the PC side I will leave that to Dave.

Interrupts do not really need to be turned off at all. But if you need to interact with them in a timely manor then yes. But even then It may bite you. Eg you have a Tmr driven interrupt that triggers on roll over. If you disable them before or even in the Debug Handler you will before ever exiting the debugger into the Int handler. May not be an issue but you will need to be aware of it.


TimB


One more thing on interrupts. Obviously you need to turn off the debugger inside the interrupt.


Dompie

I searched the old forum for P-ICD years ago but couldn't find it. It will work much better than the HRSOUT method I am using now. I hope you can create a working version. So I am very interested in this project.

Good luck
Johan