Notifications
Clear all
Components & Programming
8
Posts
3
Users
0
Likes
757
Views
Topic starter
2021-01-12 2:44 pm
I've been spending a lot of time debugging something that works fine when connected to a laptop running Arduino IDE or the Mu-editor for Circuitpython, yet fails when running in the stand alone world. In my case I'm using the deep sleep mode so I can save battery power since the sensor readings are not needed constantly. You can't debug what happens in deep sleep when the IDE or USB debug are connected since you'd lose that connection.
So what do people use to debug without an IDE serial monitor? UART? How is that done. I have the USB-Serial cable and have used it to play with on Raspberry Pi, but It seems to be different in MCUs since a UART port is used for the USB debug port. Not sure how you setup the software to do this. I'm assuming it's back to debug by printf 😀
If your code won't compile, have another glass of bourbon. Eventual the problem will be solved.
2021-01-12 3:20 pm
So what do people use to debug without an IDE serial monitor? UART? How is that done.
Never heard of SSH clients such as: "putty" or "WinSCP", etc...?
I personally use "putty" all the time... just download it (a small client), and while you're at it, download "puttygen" (an SSH key generator) to create secure passwordless logins.
In putty, just select the serial option and appropriate COM port that you are working with, and it's as simple as that! Your python print() statements will write to it, as will Arduino's Serial.print() statements.
😉
Topic starter
2021-01-12 3:34 pm
@frogandtoad So I get the use of putty but normally Serial.print or python print goes to the serial port setup for IDE or mu. How is that changed when the UART is connected. I know for my Metro ESP32-S2 board it specifically says that print does not work with the Debug UART port.
For the Seeeduino Xiao they have examples where they use SerialUSB.begin vs. Serial1.begin to talk to the TX and TX pins on the Xiao. If I look at the ESP32-S2 datasheet it says any pin can be setup as a TX or RX for one of the 2 uarts. However, they have this Debug UART that seems to be special for the Espressif IDE. So that is where I'm confused. I think for CircuitPython I can make my own build with DEBUG=1 set in the makefile and get a CP build that will use the debug port. Not sure I want to become that knowledgeable on CP debugging.
If your code won't compile, have another glass of bourbon. Eventual the problem will be solved.
2021-01-12 3:54 pm
For the Seeeduino Xiao they have examples where they use SerialUSB.begin vs. Serial1.begin to talk to the TX and TX pins on the Xiao.
In CircuitPython, you don't need to declare or connect to those... just use the python print statement to print to the putty serial.
[edit]
My bad, I Just noticed you said while not connected to computer 😀
I'll check back tomorrow... my bed time has arrived!
2021-01-12 4:06 pm
@jfabernathy in the days before every cpu came with serial data hardware we used spare registers (unused pins) for debugging. We would have a pin change state when a section of code was entered. Attach an LED to the pin for visibility if you don't have an oscilloscope. Better yet, get a 'scope if you don't have one 🙂 Granted you can't pass on as much information, but it was often enough to find the problem.
HTH
Dale
--
Dale
Topic starter
2021-01-12 4:34 pm
@dale You're dating yourself 😀 Back before we could just clip onto a pin without having a tech roll out an O-scope, open up the cabinet that contained the I/O, we just turned off the watchdog timer and put branch-to-selves in every memory location that the code should not be taking. Then when the machine locked up you just looked at the P-counter to see where you stopped. For those who remember the branch to self was opcode O14040000 in the GE 4020.
If your code won't compile, have another glass of bourbon. Eventual the problem will be solved.
2021-01-12 6:00 pm
@jfabernathy Yep. We had it easy. When things got out of hand we plugged an HP logic analyzer between the CPU and the board. Then, after programming the break points and triggers, just read the disassembled code on the HPs screen. I never got to work on a big frame computer. Although did have a PDP-11 at my high-school. It was likely the hook that got me started in computing.
Your post did have me going for a while. I read the first character of that opcode as a zero. A 30 bit CPU? Hahaha.
Any progress on your debugging problem?
--
Dale
Topic starter
2021-01-12 7:11 pm
Your post did have me going for a while. I read the first character of that opcode as a zero. A 30 bit CPU? Hahaha.
Any progress on your debugging problem?
Yeap that was an Oh and not zero. A 24 bit CPU.
I played with the UARTs on a number of MCUs today. I did get the UART working on my Metro ESP32-S2. Turns out the documentation is not quite as easy to navigate since it's a relatively new board. I got help on the Adafruit discord channel and their forum. I also found enough errors that could be trapped with try/except blocks to just have the board go into deep sleep but for only a few seconds and then reset again. 99% of the time it comes out the offending problem and recovers without any intervention. That's the goal. Self healing. So if the WiFi AP is working and the server is up, the sensor data gets sent. So I'm real close to having this done.
BTW, the weirdest CPU I worked on was a 16 bit built with 4 * 4 bit AMD2901 bit slices processor and some registers. We controlled a military jet engine with it. It didn't have interrupts because management didn't' trust them. So we ran on a hard 10 msec timer. Code ran until it was done and looped on itself until the 10 msec timer went off. Very strange. But the software was genius. That control was an 11 manipulated variable inverse Nyquist matrix.
If your code won't compile, have another glass of bourbon. Eventual the problem will be solved.