General Tree
Member
Hello,
I was working with the maple, when suddenly, the PC stopped recognizing the maple to be connected. The maple still works, the led flashes while the bootloader is running, and the PC recognizes the Maple while in bootloader mode, but as soon as the board switches over to my program, the PC thinks the Maple is no longer connected, and i can't burn anything on it, or even see that the appropriate port exists.
Any ideas on why this could have happened?
poslathian
LeafLabs
As long as your bootloader is still being recognized, you can still recover everything using the permanent bootloader mode. Simply hit reset, then immediately press and hold the BUT button, until the LED switches from the few fast blinks to the short blinks. The board should now stay it bootloader mode and you can upload new code.
Its possible that you uploaded a sketch that somehow disabled the auto-reset feature needed to put the board back in bootloader mode for programming. This can happen in loads of ways, for examples:
1) calling SerialUSB.end(), without ever calling SerialUSB.begin()
2) spending so much time in some high priority interrupt (like a timer) that there is no time left to service the USB interrupt
3) code was corrupted on uploaded (were fixing this via CRC checks in future versions)
4) interrupts were somehow disabled
5) code hard faulted in some unrecoverable way.
Try using permanent bootloader mode to upload some simple blinky code. Also, in most cases you dont really need to use permanent bootloader mode, you can just hit reset on the board right around the time the IDE finishes compiling and tries to upload.
I have had similar problems with the maple. The problem you may have is that windows does not know what driver should go with the maple. check the windows device manager. if you see an unknown device there than you have to reinstall the drivers.
The maple appears as two USB devices. A DFU device when it starts up and when it's downloading programs to the maple, and a serial port when it is up and running. you can stay in the DFU mode by pressing and holding the boot button just after releasing the reset button. the blue light will flash when it's in DFU mode.
cheers.
poslathian
LeafLabs
Were making a single driver version of the bootloader, where it will be in serial mode all the time, and always enumerated to the OS. New code will be uploaded over serial, everything should present very similar to arduino. Eventually the plan is add a second chip entirely to drive the USB, in a scheme very similar to arduino uno. Either way, the current DFU/Serial scheme is on the outs!
Thanks to the serial bootloader, it should be very easy to upgrade to the new version once its out.
General Tree
Member
@poslathian
How can i upload code while in bootloader mode? To be able to select the port to upload to, the PC has to see that the maple is connected as a serial port, not as a "LibUSB win 32", which is what is shown in the device manager while in bootloader mode.
And if the auto reset feature was really turned off due to some corrupted code or whatever, how can i turn it back on?
@wilsonjc
Drivers are not the problem. The drivers are installed and maple was working fine for several days, until this problem occured.
The DFU device still appears, but the serial port doen not, hence mmy inability to burn new code.
@gbulmer
The character's name is Mr Hanky, and its a talking piece of shit that appears in christmas.
-----
Also, is it possible that this problem occured due to physical damage the board sustained? can physical damage disable the serial "part" of the board, but not the DFU "part"?
Thanks a lot for the help!
gbulmer
Moderator
poslathian - have you got any estimate for when the PH (Post-Hinky :-) bootloader may become available? Will it be this year, or 2011?
General Tree - Yeah, I know who the character is, just really thought I'd heard "Mr Hinky". I suppose it sounded logical!-)
But I do have trouble with a couple of accents. I had a friend who seemed to pronounce "Mary", "marry", and "merry", identically; I couldn't tell the difference between them (in Charlotte NC). These words are clearly distinct to my ear in Britain.
I think it is just about possible that damage could cause the board to get 'stuck' in one type of USB device.
There are a couple of pins used to detect USB, and signal for USB enumeration, so maybe something happened there.
I have also recently had problems with Maple not being recognised correctly on Mac OS X. Sometimes there is no USB device showing up in the Tools->Serial Port menu for it, yet it uploads fine, and then the serial port shows up.
poslathian
LeafLabs
generaltree:
code is uploaded via DFU! That is, the device that enumerates via libusb. So you should be ok...the serial port is used in user mode, to transmit whatever you want via SerialUsb.print()
what happens when you drop into bootloader mode via button mashing and then hit upload?
gbulmer:
We wanted to have a throwaway prototype of the new bootloader done..err...already. So its coming quick. We expect to be shipping with the new bootloader by christmas. The alternative scheme with an additional USB chip, while not permanently abandoned, was put off until at least rev7. rev6 will have the new serial bootloader and some other known changes. Maple mini will likely use only the serial bootloader.
gbulmer
Moderator
We expect to be shipping with the new bootloader by christmas.
Thaaaank yooooouuu Santaaaa! Brilliant!
Please announce on the forum when we can download from github.
Since Maple 0.8, I have had different upload behaviour, and want to get to something more robust.
I have had to reinstall the drivers three times on the same machine over the course of a month. For whatever reason windows just decided that it didn't want to use the drivers I had installed anymore. it usually happened after several rapid restarts. Another problem I found is when I restart with the serial terminal running. Maple will ether choose another serial port, I guess it thinks the present serial port is busy. On occasion I have found that the serial port won't even connect if the serial terminal is running, and I have to reset maple.
poslathian
LeafLabs
Glad to hear it! In retrospect the whole two-driver scheme was not the best decision we ever made. Were currently experimenting with a single-driver serial only version. This "single driver" isnt really a driver either, since each OS already has built in serial drivers. Were trying to avoid the need for building a custom windows driver at all costs. I spoke with mbed about the dual-purpose usb issue (such as DFU+ serial, or serial+mass storage, or whatever). Due to the same problems being described in this topic, they ended up going with a custom driver that simultaneously provided the mass storage and serial support. This is particularly annoying since linux and mac both natively and easily support compound USB devices, its just windows that is biting us on this issue.
gbulmer
Moderator
Were trying to avoid the need for building a custom windows driver at all costs.
That is the killer for me. Many UK schools can't/won't install a special driver. End of story.
If you guys decide to remain with a special host-side driver for windows, please tell me ASAP, because I will have to change my plans. I will probably use LUFA or the ST USB serial source along the lines I emailed.
I spoke with mbed about the dual-purpose usb issue (such as DFU+ serial, or serial+mass storage, or whatever). Due to the same problems being described in this topic, they ended up going with a custom driver that simultaneously provided the mass storage and serial support.
AFAIK, mbed have the resources of ARM behind them. They can probably afford solutions which are impractical for smaller companies. (Sun Tzu might say use their strengths to defeat them :-)
Sadly, a single USB serial device is likely the only viable solution across all the platforms.
It *must* be serial so that a running program has comms, and so a bootloader *must* use serial too. IMHO not too difficult to work out, once you've got past a few basic assumptions.
Every other solution I've thought of either needs the board to detect the host platform (:-(, or specialised programs on the host. The later option destroy many of the intersting options, like using Processing, or even shell scripts, to communicate with the board. You get into supporting a load of platform specific programs which squanders resources, and will never be enough to satisfy all customers, or prospective customers.
FOCUS is key.
This is particularly annoying since linux and mac both natively and easily support compound USB devices, its just windows that is biting us on this issue.
In my world, those windows machines aren't going to be upgraded in the next few years, so they are the ones to get working on. Everything needs to be as simple as possible (but no simpler :-)
poslathian
LeafLabs
serial only is the direction were going now, for the default configuration. Obviously we want to be able to support alternative configurations eventually, mass storage and hid and what not. But we agree the default should be a no-custom-driver, COMM port enumeration.
In terms of mbed, mbed *is* ARM. I think the story is that an ARM engineer started it as a side project and eventually got ARM to let him turn it into his job. Which is pretty awesome! But yeah, windows drivers is one of those problems you really can just throw money at and they go away....like the windows 7 driver signing issue....
gbulmer
Moderator
In terms of mbed, mbed *is* ARM.
That is my impression too. ARM own the domain, the servers are hosted within ARM address ranges, ...
If I were one of the other ARM IP licensees (i.e. everyone except NXP), I would be extremely annoyed. (So I think I can hazard a guess about possible future directions)
Given that mbed is ARM, it would be seem to be suicide to copy them.
I think the story is that an ARM engineer started it as a side project and eventually got ARM to let him turn it into his job.
I don't think it was just any old ARM engineer.
An analogy might be, "then Bill Joy got Sun to let him design a processor", but I may be wrong.
You must log in to post.
