leaflabsandy
Member
How can I tell if both USB and serial windows (XP) drivers are correctly installed?
Being able to upload a program correctly to the Maple should verify this?
My problem is the simple SerialUSB.println("Hello World!") doesn't show up on the serial monitor window @ 9600 baud?
Normally, on opening the serial window, the serial monitor should/will reset the Maple?
leaflabsandy
Member
Here is the upload info ...
C:\DOCUME~1\HP_ADM~1.H_A\LOCALS~1\Temp\build3818953286292282619.tmp\HelloWorld.cpp.bin :
section size addr
.data 10256 0
Total 10256
Binary sketch size is reported above. Check it against a 100000 byte maximum.
Loading via dfu-util
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]...
Found it!
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="DFU Program FLASH 0x08005000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=205
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
poslathian
LeafLabs
hmm, if autoreset is working (
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]...
Found it!
)
then serial should be working too. In the tools->serial port menu do you see some options? Usually com 1 and 2 are gobbled up by default things like built in serial ports. Maple is usually com 7 for me. With that selected, then something like:
void loop() {
SerialUSB.println("hi");
}
should work. Can you dump your sketch?
perry
Administrator
leaflabsandy:
Just to clarify, so your maple DOES reset when you hit upload, and properly resets and uploads, but nothing ever shows up on the serial monitor when you send?
The USB serial port has been non-stop pain for us trying to get it working on every platform. ugh...
poslathian
LeafLabs
I noticed that the main.cpp.example file that comes in the libmaple repo only write SerialUSB.println("hello") in the setup, not in the loop. So if youre using that, chances are you missed the print, since it only happens once in the beginning. If thats the case, than add a print statement to your loop. Otherwise, more debugging!
leaflabsandy
Member
That is correct. The Maple resets and uploads properly. The serial monitor should
reset the Maple again upon activation?
Most of the platforms in the world are probably xp 32 so a concerted
effort should be made to make the USB serial port work.
Also, on a very simple program, why does it take over two minutes to upload "hello world" ?
leaflabsandy
Member
Quote: "So if your using that, chances are you missed the print, since it only happens once in the beginning. If thats the case, than add a print statement to your loop. Otherwise, more debugging!" I
I already inserted the same statement in the main loop and does not work.
Also, like I said, when activating the serial monitor window it should also reset
the Maple -- just like the Arduino did. This should alway pick up any print statement
before the main loop.
perry
Administrator
Hey andy,
sorry for all the trouble. haven't seen that problem before. Can you give us the exact sketch you're trying to run, which version of windows xp, and what your hardware specs are?
I'll try to reproduce it when I find a windows machine some time this weekend...
Unfortunately the serial monitor/reset thing is a bit of a chicken and egg problem. On the Arduino, there's no native USB peripheral, so it relies on the FTDI USB->Serial chip. Since the maple has native usb, the serial monitor can't be opened until the usb peripheral enumerates and presents itself, but if the serial monitor resets the chip, then we can't open the serial port on the PC side!
I haven't come up with a satisfactory solution to this problem. We could potentially make the maple wait until a serial monitor is attached, but then the maple would block and not do anything if the serial monitor isn't attached...
Any suggestions are welcome, I'm sure we'll work out all the kinks. Thanks for bearing with us at this early stage.
leaflabsandy
Member
-------------
Computer info
-------------
HP Pavilion 061
System Model: ER189AA-ABA s7410n
BIOS Version: American Megatrends Inc. 3.06
Microsoft Windows XP Professional
Version: 5.1.2600
Service Pack: 3.0
Location: C:\WINDOWS
PID: 76487-OEM-0011903-00803
Hot Fix: KB981793
Capacity: 1 GB
Intel(R) Celeron(R) M processor 1.70GHz
Version: x86 Family 6 Model 13 Stepping 8
Speed: 1697 MHz
System Name:
Domain: HOME
Time Zone: Eastern Daylight Time
Connection: Workstation (standalone)
Proxy Server: None
IP Address: <----------------- deleted for security
IPX Address: Not Enabled
-----------------
program/sketch
-----------------
/* Blink without Delay
Turns on and off a light emitting diode(LED) connected to a digital
pin, without using the delay() function. This means that other code
can run at the same time without being interrupted by the LED code.
The circuit:
* LED attached from pin 13 to ground.
* Note: on most Arduinos, there is already an LED on the board
that's attached to pin 13, so no hardware is needed for this example.
created 2005
by David A. Mellis
modified 17 Jun 2009
by Tom Igoe
http://www.arduino.cc/en/Tutorial/BlinkWithoutDelay
*/
// constants won't change. Used here to
// set pin numbers:
const int ledPin = 13; // the number of the LED pin
// Variables will change:
int ledState = LOW; // ledState used to set the LED
long previousMillis = 0; // will store last time LED was updated
// the follow variables is a long because the time, measured in miliseconds,
// will quickly become a bigger number than can be stored in an int.
long interval = 50; // interval at which to blink (milliseconds)
void setup() {
// set the digital pin as output:
pinMode(ledPin, OUTPUT);
}
void loop()
{
// here is where you'd put code that needs to be running all the time.
// check to see if it's time to blink the LED; that is, is the difference
// between the current time and last time we blinked the LED bigger than
// the interval at which we want to blink the LED.
if (millis() - previousMillis > interval) {
// save the last time you blinked the LED
previousMillis = millis();
// if the LED is off turn it on and vice-versa:
if (ledState == LOW)
ledState = HIGH;
else
ledState = LOW;
// set the LED with the ledState of the variable:
digitalWrite(ledPin, ledState);
}
SerialUSB.println("Hello World!"); <------------- for the serial monitor test
}
-----------------------------------------------------------------------------------------
Additional Notes: There seems to be a memory leak using the Maple IDE?
By rebooting the PCI was able to speed up the compile time by a least one minute?
On the serial monitor problem - you cannot force users to only put print statements in
the main loop because there are many others, like me, insert diagnostic print statements
on bootup or reset. This bug will be hard one to fix.
poslathian
LeafLabs
good point about serial debug in setup(). The problem is simply that you cant open the serial port until after the chip has jumped to user code, but once you get it open, setup has probably already finished and you miss the print statements. Some OS's buffer the serial port such that even if you dont read the serial port until later, you can still see old prints in the buffer. Windows doesnt do this. Its a weird problem, but I agree there should be some way to use serial debug in setup...hmm. Perhaps you could (and this is really crappy) insert a delay as the first item in setup giving you time to open the port. Or even better, use the BUT button to reset the user code, but not reset the whole board, or something simpler like wait in setup() until you hit the BUT button (the BUT button, by the way, is pin 38, aka GPIOC-9)
Obviously none of that solves your problem at hand and is non optimal.
You mentioned earlier about opening the serial window resets the board? This should not happen. I have a suspicion that the problem is related to the blocking conditions on the SerialUSB. Currently, data will not be sent over the pipe with a SerialUSB call unless one of DTR or RTS is high. In the lab, this worked on all flavors of nix and mac, and winxp home 32, 64. We found that it did not work in windows 7. We didnt add those conditions, however, until IDE 5.0, try ide 4.0, and see if that works, youll have to upload new code from IDE 4.0 to get the change loaded onto the chip.
leaflabsandy
Member
Perry ...
Did some further troubleshooting and here is what I came up with:
I got a third party serial terminal program "Tera Term v4.63" and
intercepted the serial port (in my case com9) and
the SerialUSB.println("Hello World!"); command Hello World! showed up.
Seems like the serial monitor in the IDE does not work?
Also, all print commands from bootup to the main loop still does not work
because of your "chicken/egg" discussion above.
poslathian
LeafLabs
sounds like its definitely the DTR/RTS issue discussed above. I have a patch in mind for 0.1.0 that might fix this. If you want to hack on it you have 3 options.
1) use ide version 0.0.4 (0.0.5 is a lot better for a lot of reasons, so this is suboptimal)
2) go to the maple-ide/hardware/leaflabs/cores/maple directory and edit the file usb.c, in usbSendBytes theres a switch:
if (bDeviceState != CONFIGURED || (!usbGetDTR() && !usbGetRTS())), try removing the usbGetDTR and usbGetRTS from that line. Its possible that this will cause your sketches to halt on calls to SerialUSB.print if you have no terminal open to read it. This might actually be helpful if youre trying to readback pring statements from setup()
3) recompile the IDE such that DTR is manually set high upon opening the serial port window. I dont know the exact line of code where this change needs to go, its the "patch" i was talking of making earlier.
hope that helps
leaflabsandy
Member
Perry ... also, I have noticed that, by closing the tera termainal third party program down, it also halts the Maple.
There has to be a way to do a software reset from the IDE on the Maple. By always pressing the manual reset, there is a great probability that a static discharge will kill the Maple board and or ruin the small tac switch.
What I have been seeing is inconsistent uploads to the Maple, from the "dual driver" windows XP platform.
poslathian
LeafLabs
Let me see if I can get a winxp pro service pack 3 going. I believe in this case, the service pack totally matters, and the problem is definitely related to how windows has decided to handle DTR and RTS control lines over the virtual com. Since the software reset from the IDE is based around toggling DTR/RTS, and these lines also control whether or not calls to SerialUSB.print will block, or fail gracefully (assuming the data wasnt read out by the host PC, which it isnt if you dont have a serial terminal open), then pretty much all the problems youre describing - forced manual reset, halt on serial window closing, usb print statements not printing...well they all trace back to that issue.
p.s. - poslathian != perry ;)
You must log in to post.