The PIO documentation regarding this Heltec board infers (doesn’t it?) that debugging using PIO is possible. I believe this is not the case because GPIO14 is used to reset the integrated OLED., and GPIO15 is SCL for the OLED. I don’t think it is possible to re-assign these pins is it?
Can anyone confirm there is not a simple workaround please?
If it is not suitable for debugging then maybe the docs should be a little more explicit so folks know not to buy this system if they want to debug?
PlatformIO generally supports debugging of the platform (e.g. see Atmel AVR) or not
If it generally does, the board either has an on-board debugging probe and is thus “ready for debugging”, or
it doesn’t have such a debugger probe, but one can be externally attached (“need to buy external probe”).
This is inferred from the JSON definition of the baord. If it has debug section, it’s generally debugabble with the tools described in the section or the platform, if it declares an onboard_tools, it has an on-board tool.
PlatformIO has surely not checked every single board which doesn’t have an on-board debugging probe whether the actual schematics of the board have all free signals for debugging. I guess there can be a 4th state with “we could generally debug this board with the tools for the platform, but the board’s schematics doesn’t allow it by default”.
Thanks for the quick response, and explanation. Managing docs for all these boards must be a huge challenge! I was just flagging a possible point of confusion in case others wondered.
I was using 3 different external debuggers (Olimex, JTAG and ESP-prog), and futzed around with the radio and OLED disabled (I think) but didn’t make progress. Since debugging w/o those two components seemed to invalidate the whole purpose of the board I… went to bed.
Anyway - it’s great being able to use the same tool to debug a bunch of different processors (STM, ESP, AVR and NRF so far), It’s a giant leap.