Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 6 of 6

Thread: Debugging with the serial port, issues..

  1. #1

    Debugging with the serial port, issues..

    I put Serial.println("bla bla"); lines all over in my code trying to trace my program flow. I'm seeing them get skipped over. Is this a known issue? If so is there a way to force them to block 'till they output their data?

    I'm sorry, I don't have a simple case to show. But I figured I wouldn't be the first to hit this, so I'm asking.


    -jim lee

  2. #2
    Senior Member
    Join Date
    Dec 2016
    Montreal, Canada
    definately a code issue, of which we cannot see. An example would definately help us point you in the right direction

  3. #3
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Printing too much too often from Teensy ( not noted which one ? ) can easily overwhelm the USB transfer to PC and it ability to process and display the data.

    Add a way to regulate the amount printed - don't print if unchanged, or print a simple single character signifier.

    Perhaps make a function() to call with your strings and have that function do all the printing and using doc here : do Serial.send_now() or .flush() in some controlled fashion to pause at times, perhaps a bool to the function() to say when to wait.

    Including any sort of example of runnable code that exhibits the issue allows for better understanding and feedback

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    If you print from both main program and interrupts, or from multiple interrupts running with different priority levels, the Serial.print code is *not* safe to use. Usually it will work anyway, where data loss is usually the worst problem. Lockups or really bad problems are extremely rare. But if the interrupts happen at just the wrong moment while a main program or lower priority interrupt is doing Serial.print, you can get data loss when the interrupt changes variables that were in use by the main program. It's a known issue for that use case.

    Many times I've considered trying to make it safe for interrupts and main program. But doing so could impose a pretty substantial interrupt blocking time on all uses. It's also a pretty low priority compared to so many other things...

    However, the is safe to use Serial.print within interrupts if all the interrupts using it run at the same priority. It's also safe if the interrupt never occurs while the other uses are in progress.

    There may also be issues for causes with large bidirectional data flow, where fast incoming data and high-latency reading by user code starves the rest of the USB stack for buffers.

    Of course, something in your code could be causing trouble. A very common issue we see on this forum is a buffer overflow, like writing 1 place past the end of an array (usually due to a "<=" check which should have been "<"). Corrupting the memory causes problems later which appear to be unrelated bugs when other code runs needing that memory.

    Could be other stuff too. Nobody can even begin to guess without seeing your code. But here's an informal list covering pretty much all the scenarios we usually see on this forum.

  5. #5
    It looked like I was just overrunning the output buffer. I was doing something like a stack crawl by having a serial output in each function both in and out. It would work if I had a better understanding on how to make the serial prints block. It did work after a fashion, and was able to pinpoint where I screwed up my code. But it was iffy. Sometimes I'd only get lie 20% or so. At first this totally freaked me out because I thought I was crashing only about 20% into my code and those places were in tried and true libraries.

    As for interrupts, I almost never use them. So that's not really an issue.

    Anyway, after I found the last issue and turned off the stack crawl, everything works fine.

    I read the stuff on the last link, but I didn't really get a definite answer from it. How to make a print() be blocking or does flush() really work and how?

    Thanks agin for replying. It's really good to know there's people out here that can re-point me in the right direction.

    -jim lee

  6. #6
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Great you made headway. Teensy USB is true 12 Mbit hardware not 'serial' gated by a baud rate through a secondary chip to PC.

    That page link to the .flush() and .send_now() should be a way to force a flush or wait at key points. You could drop one of those in loop() perhaps or in at the point loss was showing after over writing.

    Without any example code it isn't even clear on which teensy and which Serial or Serial# the output is going so providing example fixes or better ideas is beyond speculation.

    All of that can affect program flow and speed and with no idea of the process underway that leaves it up to best guess on your end.

    I've posted initial start of debug_t3 lib a few times - it allows recording program flow in some fashion in an internal array that can be exposed as desired to minimize printing until needed or triggered - and it pops up if the processor ever faults.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts