stdio bug - no, QuickStart Quirk

mindrobots

I'm simple, so I'm starting my testing simply.

hello.c on 64KB Quickstart
built with windows v0_1_7

>propeller-elf-gcc -o hello hello.c
>propeller-load -p com4 hello -r -t -e

#include <stdio.h>
int main()
{
        printf("Hello World.\n");
        return 0;    
}

Output as seen in PuTTY (screen display and PuTTY.log)

[B]PuTTY screen: connected to Quickstart - 5 resets of Hello.c[/B]

Hello World.
             "Hello World.
                          D2    Hello World.
                                            20Hello World.
                                                          !`HHello World.
                                                                         @ 3



[B]PuTTY log file of all session output:[/B]

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2011.11.09 12:56:49 =~=~=~=~=~=~=~=~=~=~=~=
Hello World.
       "    Hello World.
      D  2  ‘  €      Hello World.
  ‰    ˆ 2   0  Hello World.
    !  ` H  ™     ‰ Hello World.
     @     3 

Excess characters being generated in the literal string or the string is not being properly terminated or printf unable to determine string length or ??

Similar "extra" output seen using propeller-load terminal.

jazzed

Hi Rick.

I've seen something like this on QuickStart boards before.
No other board that I've tested has this problem.
It is not clear what is happening, but I have ideas.

Please add while(1); before return 0; in your code.
Let me know if the crazy output stops.

#include <stdio.h>
int main()
{
  printf("Hello World.\n");
  [COLOR=#008080]while(1);[/COLOR]
  return 0;
}

mindrobots

Steve,

Thanks! Putting the while(1) at the end of the routine "solves?" the output issue.

I'll try it on something other than a QuickStart when I get home.

I've seen other reset/load quirks on the QuickStart at times.

jazzed

mindrobots wrote: »

Steve,

Thanks! Putting the while(1) at the end of the routine "solves?" the output issue.

I'll try it on something other than a QuickStart when I get home.

I've seen other reset/load quirks on the QuickStart at times.

Good to hear this. Normally one "can/should/would/maybe" end an embedded program with a loop.
However I in GCC we have a way to "finalize" a program so that this should not be necessary.

My current theory is that because we are stopping the main cog, the QuickStart
74*125 buffer input "flaps" briefly which makes garbage characters.

I've changed the "end" code so that the cog does not stop and I no longer see the problem.
Most likely we should add a "sleep loop" instead of stopping the COG at program end.
We can always restart the COG later if necessary.

Thanks.
--Steve

Phil Pilgrim (PhiPi)

jazzed wrote:

My current theory is that because we are stopping the main cog, the QuickStart 74*125 buffer input "flaps" briefly which makes garbage characters.

And that is because TX on the QuickStart board has no pullup resistor.

Note to Parallax: TX and RX should always have pullups to Vdd. (Hey, at least you put a buffer in this time! )

-Phil

mindrobots

The while(1) is inelegant but acceptable!

I'm assuming there is a SPIN stub that launches the propgcc main routine. would it be reasonable for the return in main() to actually perform the return and have the stub close things up nicely? This could anticipate the future when some other program (let's not call it an OS but a supervisor of sorts) would actually launch a program at main() and possibly be able to handle a return value from main for further processing decisions. (PropII)

Kudos to Phil (once more) - I've been seeing this on the QuickStarts but wasn't smart enough to know why. It's annoying (unplug and replug usually fixes it) but not mission critical.

David Betz

In LMM or XMM mode, once the C program has started running there is no Spin code running on the Propeller chip. The LMM/XMM kernel is written in assembly language. It is started by a loader process which has a little Spin in it but that Spin is gone by the time the LMM/XMM kernel starts.

mindrobots

Thanks David! I guess there's no place to return to. With your response and rereading Steve's last response, it sounds like it should be taken care of in most cases. I'll go looking for more non-bugs!

Tor

A loop at end of execution could be hidden in exit() (which is called not only if you call 'exit()', but also with return() from main()). Or maybe better in _exit() which is what exit() calls, but _exit() can also be called by the programmer, so _exit() sounds like the place. (This would be part of the runtime support then, if it turns out to be a good idea).

If your program has 'exit()' calls here and there then the loop at end of main() doesn't work anyway, if so you could for now handle that with a call to atexit(), something like this:

#include <stdlib.h>

static void forever (void)
{
    while (1);
}

in main (void)
{
    atexit(forever);
    /* your code ..*/
    return (0);
}

(assuming that 'atexit()' is supported in the alpha version - I haven't tested the above on my QS yet)

-Tor

Ariba

I think the best way to solve this problem is to add a pullup resistor. It was the first I've done after receiving my Quickstart and saw this random characters sent over USB.
The floating TX line after the end of the program is only a part of the problem. The more worse part is that the pin also floats after reset for 100ms until the bootlader detects an upload and after the upload has finished until the serial driver starts. I think this also causes the ViewPort problems with the Quickstart.

Here is simple hardware solution:

Andy

mindrobots

@Tor: atexit() is supported and clears up the problem of adding the infinite loop when main() returns. The garbage characters went away without any hardware modifications.

@Andy: You're hardware upgrade solves the garbage character problem also. It also corrects the load/reload problem with the QuickStart that has been plaguing everyone.. I think some resistors may get soldered to my QuickStarts today.

With both of them, the QuickStart is back to being near bulletproof!

Thank you, Gentlemen!

Hanno

Hi Ariba,
Can you provide more details on what happens with the quickstart if you don't add the pull-up resistor? The ViewPort conduit cog runs continually once it has been started, so data shouldn't be corrupted. It seems it's possible that garbage data can be introduced after load but before the Prop is running? The conduit does use markers to help ViewPort do error correction on received data, so even this shouldn't affect it.
Hanno

Ariba

Hi Hanno

I myself don't use ViewPort, but there was a thread about problems with the Quickstart:
http://forums.parallax.com/showthread.php?133625-QuickStart-board-and-ViewPort-problem

I think the FT232 can receive some random data before the Conduit is started, and this data maybe disturbs the baudrate regognizing or something else.

Andy

Hanno

ViewPort works with Quickstart. The issue in the thread you pointed to was caused by Parallax's non-standard retractable USB cable. Changing to a standard cable resolved the issue.
Thankfully they're no longer shipping that.
Hanno