BasicMicro - Forums

I don't know if this is a bug of the PIC's hardware UART or in the Atom BASIC compiler or some combo.

I wanted to test some devices at work with one of ELProduct's OEM Atom Module development system boards. I wanted to do long term power-on tests where a string of ASCII characters go through a chain of devices one way, then the same string gets sent the other way. Since there is at most a few microseconds delay from the transmit pin to the receiving pin I couldn't use a software bit-bang serial port. I had to use the internal UART with it's ability to just snag incoming characters and stuff them into a buffer without intervention on the processor's part.
The heart of the code is:

After initializing the hardware UART to work at 19200 Baud, we do
FOR X = 33 TO 122 'all recognizable ASCII character values
CHAR = X 'assign an ASCII character to the transmitted character
HSEROUT [CHAR] 'send the character out
HSERIN [CHAR_RCV] 'get the character in using a different variable
SEROUT s_out, I57600, [DEC CHAR, " ", DEC CHAR_RCV, " "] 'display characters out/in in terminal display
IF CHAR_RCV <> CHAR THEN _Err_Report
NEXT 'Do 90 characters

This sits in a MAIN routine which contains other support code and is looped back to continuously. After this series finishes, direction of flow is reversed and then we do this all over again.

So, on the display, we EXPECT to see a string of ASCII characters (two of each) marching across the screen, over and over. What we get is an immediate error that shows the original character, something totally different from the original, and the error message showing these characters again and a blinking red LED. No amount of carefully spaced, constantly increased, pauses will fix this situation. First character out - and - BAM!

So, I simplify and troubleshoot.
What about one value? Send out Hex55 (digital technicians will know why this value was chosen). An o-scope trace shows the proper voltage levels, in the sequence expected, in the proper pulse widths. But, after turning off error reporting, the terminal display shows the first 26 characters received back to the UART don't match the Hex55 out. Consistently. In fact most are zero?! But after that the results are good. I suspect that the hardware being tested is contributing to this phenomena. So a 'pump priming' loop is run first, THEN we run a loop where the error report is turned on. Only to find that THAT first loop fails somewhere in the 20 characters, but not usually the first character. So another IF conditional is added that skips the error detection for the first loop. After that everything works as expected. Now some other key Hex values (0, FF, and AA) are tried, by themselves, with no problems. So, it's time to try ASCII again.

A short FOR - NEXT loop, 33 TO 42, is tried. Once again it fails. But the results are recognizable ASCII values, consistent and perhaps indicative of the nature of the problem. Unfortunately I never recorded the results so I can't repeat them here exactly. But the strings were the same, even the characters in error.

Eventually I settled on a string of alternating 55/AA/55/AA/... This suffices for now. I dropped all the pauses and upped the transmission speed to 57600. Everything runs fine - if I limit the chain to four devices.

After reading the latest Atom manual and Chuck's Atom book I have no idea where the problem comes from. Comments? Ideas? Suggestions? I would REALLY like to stress test this equipment and a full ASCII string would be best here for my purposes.

Later!
kenjj

Kenjj,

You might want to think about clearing the input buffer before you send (HSERSTAT 0), then testing to see if there's anything in the input buffer (HSERSTAT 3, GoToSomeLabel) before reading it. Also, consider a way to ensure the input buffer doesn't over flow before you get around to reading it.

Good luck,
Don

Neverrr minnnd. I figured it out.

My loop takes a fairly constant stream from the board under test and sends it to the Atom's terminal window. The loop is basically a HSERIN followed immediately by a SEROUT, with a few conditionals and GOSUBs thrown in. The Atom's HSER# stuff has a buffer and uses interrupts. I added another SEROUT in this loop to tweak a missing message from the test board. But, these two messages conflict somehow, and garbage gets printed to the screen as long as the tweak message is being sent. Once that ends, things display normally. I moved the tweak message to a subroutine outside the loop and things work as desired.

Sigh. I do _SO_ love programming.

Later!
kenjj

Thanks for the input, Don. I finally gave up on the big ASCII string, but I have a problem now for which you may have supplied an answer.

Well, it is 27 days later. I gave up trying to do an ASCII string in the earlier program. I settled for a stream of 55s and AAs (hex) and got on with it. The effort found one intermittent board that would have never been caught in the standard test setup, so it was worth the effort, to my thinking. At the end of 100 hours of burn in in a chain of ten units, I tested these "good" boards two at a time in the standard test station, with 4920 feet (1.5kilometers) of fiber optic cable. This proved to be the real stress test, as I found two that failed over that distance. But I digress.

I am now creating a new test situation. We have a series of intelligent boards with a serial port that brings up a diagnostic menu of several tests. I usually laboriously sequence through all relevant commands on a simple terminal looking for problems. I want to do a limited test situation where the Atom on my development board exercises the board(s) over a 100 hour period by sending single-letter commands and then parse the responses sent back. That is, I want to "automate" the test sequence during burn in, as opposed to starting a single test and watch to see if a single LED keeps blinking. As usual, I have run into a "huh?!" moment using serial commands.
It seems I have one too many SEROUTs or something. I have been building my programs in small workable modules and/or additions. The latest program consists of HSERIN/OUTs and SEROUTs. The HSER# stuff is for test-board/devel-board communications, while the SEROUTs largely issue test updates to the Atom's Terminal1 window for the operator's attention. In the middle of this effort I inserted an interrupt-driven clock which allows me to track the elapsed time of tests. The number of test loops was added to the time print out later. I wanted to add one more reported variable in these messages, but...now...the test is off in space. When I start the test I hit the test board's reset and let the devel board monitor the login message for two ">"s. When these are seen, it turns around and sends out the password, and away we gooo... Except, since I added the latest of many SEROUTs, it simply starts with the "HIT THE RESET' message, then sits there dumb. I remove that SEROUT, we're back in business.

Could I have a stack problem here? Is the interrupt-driven clock contributing to my problem? Moving the SEROUT in and out of the normal test loop is a no-go, as is removing other SEROUTs . Once again, any input, suggestions, comments, etc? If I get a concrete solution, or at least a workaround, I'll report it here.

In the mean time, I must say, despite the problems encountered, the Atom has proven to be a great tool to develop quick ways to implement testing at the bench.

Later!
kenjj