-
• #2
I haven't seen this one before I'm afraid... How are you loading the benchmarks in? Using the benchmark script?
One potential gotcha is that the F4 discovery doesn't have USB flow control - so if you paste more information than it can handle then characters will get lost. The Web IDE should (I think) know about this and intentionally throttle the data it sends, but the benchmark won't.
-
• #3
Thanks Gordon. It is fairly reproducible when the code size exceeds
the ~606 byte threshold. I'll try another board, then if it isn't that, go
do some debugging. I loaded the benchmark using either the IDE or
benchmark.py - doesn't matter which, same result. -
• #4
Well, the first thing I tried was carefully cutting/pasting the simple_loop4.js code
into the board while in minicom. I think you're right about flow control - the
simple_loop4.js code works when entered this way. I'll try hooking up a USB/serial
adapter with flow control, and see if that helps. Thanks again - Rick -
• #5
And, the CC3000 web server example works properly when fed in by
hand via minicom. So this is related, as you suspected, to flow control. -
• #6
The bug for it is here: https://github.com/espruino/Espruino/issÂues/21
Hi - I'm working with Espruino on the STM32F4Discovery, and seem to have found
a bug. I first noticed the issue when trying to run the LED web server example
in the CC3000 tutorial. The simple example of connecting to the hello world web
site worked fine, but the LED example seems to crash the STM32 board. I started
to debug the problem, and found that javascript code > ~606 bytes seems to hang
the Espruino. For example, if I run the benchmark.py program with simple_loop1.js,
simple_loop2.js, or simple_loop3.js, all < 606 bytes, the benchmark runs to completion.
Yet when I run simple_loop4.js, length 1079 bytes, the benchmark never completes.
I am running an image compiled from the latest pull from the git archive.
Anyone else run into this problem?