Maple Mini DFU and Serial

Hi, I’ve got MM (and BP). Original Bloader.
The “driver” from Arduino_STM32 installed (install_drivers.bat). Win7 64b.
DFU mode works with MM fine, I’ve uploaded my test sketches and they work fine via serial1 uart.

However, I cannot get serial over usb working. Reading topics here it seems the serial should start when I reset while but pushed down.
I cannot see the new serial port in device manager. I see “Maple” in “Other devices” with exclamation mark – driver not installed.
Any hint plz?

Remember, the bootloader serial is separate from the sketch serial. So, being able to load code to the MM does not mean that the sketch USB will automatically be recognized.

I think you should be able to use Device Manager and select the Maple device and reinstall the driver through the GUI.

I move over to Linux Mint late last year because of the Windows driver-signing nonsense. I’m an ex-MCSE and I would never go back to Win-anything.

Ray

No luck with serial. After several attempts reinstalling the driver (via device manager too) I cannot get it working. Sometimes I can see it as COM2x in usbdeview (not connected however), but not in device manager under Ports.
Anybody using it under win7 64bit??

Maple mini works fine on W7 64bit
I use it in 3 different W7 64 machines with different motherboard chipsets

Did you upload a Blink sketch that also includes Serial.begin and Serial.print ?

Unless you load a sketch that uses USB serial, the USB serial device does not always appear.

Did you select the correct board type?

>Did you upload a Blink sketch that also includes Serial.begin and Serial.print ?
Yes, all my sketches include Serial.begin or Serial.print (or Serial1.begin or Serial1.print).
Using Serial1 via uart – works fine.
Maple DFU works fine.

>Did you select the correct board type?
Maple Mini, Original 17k ram 108k flash.

Umm.

Board settings seem OK.

Do you see an unrecognized device when the sketch is running.

When the sketch was running I saw “Maple” with exclm mark in “Other devices”.
After messing with the drivers I got once Maple inside “Ports” as “Maple” only (no COMxx indication).
I observed the stuff with usbdeview – I saw Maple serial driver there with ie COM25, but not active/connected. The usb dev info seems to be ok.
Tried to force a driver via Zadig, always got error with installation (3 drivers offered).

When I connect MM to Win it recognizes DFU (I see the DFU driver shortly in DevMan) then after a second it tries with Serial but ends up with no luck. I ran the driver_install.bat few times, I did also with manual installation out of the win driver folders.
I will try again this evening.

Let me recap to be sure I do it right :
1. the MM is disconnected from USB
2. Install drivers_install.bat (ne error indicated, I tried with MM connected and disconnected during the install)
3. connect MM to USB (my sketch had been uploaded before via DFU, it includes a) Serial.begin() or b)Serial1.begin() etc., works fine via serial Uart)
4. the sound of connecting, I see DFU driver shortly in DevMan, then it disconnects from DFU after a second
5. the sound of connecting again to Serial, in DevMan I see “Maple” in “Other devices” with yellow triangle – a driver problem.

@Pito,

You may need to use Device Manager to delete completely the MM and Plug&Play association. In the process, you may wish to clean up some of your phantom comm connections … unless you really have 20+ USB serial devices. The process is here: I summerize below…
The trick was to open the Command Prompt as administrator and start the Device Manager from the same command prompt.
1. Right-click “Command Prompt” in Accessories and choose “Run as Administrator”
2. Enter “set devmgr_show_nonpresent_devices=1″ – without the quotes obviously
3. Enter “start devmgmt.msc”
4. In the box that opens, select “Show hidden devices” in the ‘view’ menu.
Now if you expand the section on COM ports, all the COM ports that have ever
been created will be displayed, the non present ones being in grey. You can
uninstall away anything that you don’t want (right click, select uninstall).
http://www.fettesps.com/how-to-remove-c … re-in-use/

Specific to MM, when asked about deleting the driver physical copy, respond ‘yes’. Then use the .bat file to reinstall the association.

Good luck,

Ray

The same. Enclosed the usbdeview report on both Maple DFU and Serial after cleaning and fresh install the association via .bat
Installed from trunk. While DFU data seem to be complete, some Serial info is missing.

Perplexing. I’m not USB savvy ’nuff to really know how the enumeration should look, I’m generally inclined to compare outputs from similar machines, but in this case, all of my Arduino stuff has moved from Windows to Linux. If you give a reference to download the specific tool you are using, maybe one of our Windows members can do a compare.

Ray

http://www.nirsoft.net/utils/usb_devices_view.html
http://www.softpedia.com/get/System/Sys … view.shtml
For 64bit take the 64bit version.
If you want to uninstall the usb devices you have to go Help->Run as admin.

Try on a different computer and also with a different cable

And of course your Maple Mini board could be faulty e.g. some sort of USB reset hardware issue

RogerClark wrote:Try on a different computer and also with a different cable

And of course your Maple Mini board could be faulty e.g. some sort of USB reset hardware issue

I will try with the second one
On the other hand the cable and DFU and basic MM hardware seems to be working (my test sketch via Serial1 and uart1):
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=2139
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode

Hello World!

x= 3444444444445555555555666666.6666678
y= -56666666666677777777777788.888888888

z=x+y= 3387777777778877777777888877.7777789
3.387777777778878e+27
elapsed: 42 us

z=x-y= 3501111111112233333333444455.5555567
3.501111111112233e+27
elapsed: 45 us

z=x*y= -1.9518518518528641975309276666666673E+53
-1.951851851852864e+53
elapsed: 93 us

z=x/y= -60.784313725497885428683223790246607
-6.078431372549789e+01
elapsed: 314 us

z=cos(0.7)= 0.76484218728448842625585999019186493
7.648421872844884e-01
elapsed: 6665 us

Tried my second MM (Baite). 2 different cables, 4 diff ports. The same behavior as above.
Luckily at least the DFU mode works

You could try replacing the old bootloader which comes preinstalled with the new one.

Its not going to be any worse than what you have now.

Flashed maple_mini_boot20.bin via stlink.
Board set MM with bootloader 2.0.
Sketch under Arduino 1.6.5.:
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
}

void loop() {
// put your main code here, to run repeatedly:
Serial.println("Hello");
}

Click on the yellow icon (in other devices) and install the maple serial driver.
Arduino_STM32\drivers\win\win_xp_legacy\maple-serial\usb_device.inf

Error installing driver – the name is already in use.
I see now a “COM9” in “Other devices” with ! in yellow triangle however
Using win7 64bit btw.

Install Zadig http://zadig.akeo.ie/downloads/zadig_2.2.exe
Zadig is a Windows application that installs generic USB drivers, such as WinUSB, libusb-win32/libusb0.sys or libusbK, to help you access USB devices.

I did with zadig 2.1. (see my post above), I got 3x error while installed the offered drivers for Maple. But I will try again..
OK I have installed the USB CDC driver from the zadig 2.2.689 and now I can see Maple in Ports..
Hello via USB Serial.JPG

I told you
Well done!

Now, before people start to desolder their chips or reinstall their Win7 , what is the right way to install the drivers??

Normally the bat file works OK.

I’m not sure why it didnt work for you.

Basically from Windows 7 onwards, Windows only allows “signed” drivers to be installed. To get drivers signed by Mirco$oft costs $$$$ and is basically a non-starter for Open Source or non commercial projects.

But drivers can be self signed.

Luckily we are not the only group that needs drivers, so there was existing code to simpify the self signing process

https://github.com/pbatard/libwdi

One of the community members wrote a custom version of libwdi to support the Maple drivers.

Anyway, I think libwdi works for most people, but it doesn’t seem to work for everyone, and I’ve no idea why this is.

I must admit I can’t recall if installing the drivers before or after connecting the Maple mini is the best option – but someone else may know.

I think that signed driver policy began with Win 10; could be wrong.

Are self-signed drivers the same as the widely know awkward procedure to install unsigned drivers in win 10?

@stevech

I’m pretty sure that driver signing came in with W7.

XP didnt have it. We still have the legacy XP drivers, but they can’t be used on W7 or newer.

Luckily W10 seems to be basically the same as W7,8,and 8.1, and the libwdi still seems to work on W10.

RogerClark wrote:@stevech

I’m pretty sure that driver signing came in with W7.

I can confirm that installing drivers from bat file in stm32duino drivers folder didn’t install the driver properly and I had exactly the same symptoms as pito had. I had to install usb CDC driver via zadig tool – though not using maple board, but generic blue pill, but I don’t think it makes much difference here.
My OS is Win7 Professional, SP1, x64

jaromir wrote:I can confirm that installing drivers from bat file in stm32duino drivers folder didn’t install the driver properly and I had exactly the same symptoms as pito had. I had to install usb CDC driver via zadig tool – though not using maple board, but generic blue pill, but I don’t think it makes much difference here.
My OS is Win7 Professional, SP1, x64

Maybe it is like a doctor giving a vaccination; you know, sometimes the vaccination “takes” and other times, the vaccination does work as expected.
Imagine IT would work that way

I am not sure why some people need to use zdiag.
I have never needed to use it, and I have installed on many different W7 machines, and also on W8.1 and W10

So either not all versions of W7 Pro are the same, or there are differences in the function of the USB host drivers (inside Windows)

Note. I have heard of people having problems when connecting though USB hubs, and its also possible that USB 1 ports behave differently to the newer USB versions.

I went through .inf files and compared the VID/PID combinations to be the same as my device enumerated to – and it was the same, of course. The bat files and inf files looked sane. I have no idea why it didn’t install correctly.

jaromir wrote:
<…>I have no idea why it didn’t install correctly.

that man will help him root it out and concatenate.

mrburnette wrote:Anyone that demands 100% perfect downloads 100% of the time, really should back off the STM32 bootloader and go to a different, less problematic flash methodology.

Ray

The fact it works on some win7 64b, and it doesn’t on some (except usb hw issues, which I would consider less probable) it might indicate the driver does not install because of other installed drivers. Zadig simply somehow forces USB CDC to install.
As I wrote above, I did with zadig 2.1 and I did not get an USB CDC offer for Maple. After I had taken the zadig 2.2x it offered me the USB CDC for Maple and it started to work.
So my current understanding is – a driver collision, or other (ie Avira is blocking it??, not tried yet).
I am a long time happy Win user and I do not have any fundamental issue installing drivers for any kind of crazy dongles I am doing last years.. Of course I am using Linux too, but in limited quantities..

stevech wrote:
<…>
I’ve never had flash fail to read-back OK. Call me lucky, but this is NXP, Freescale, Atmel, ST. Several chip types each.
In production, the chips get flashed once. Then maybe 3 times a year due to updates.

mrburnette wrote:stevech wrote:
<…>
I’ve never had flash fail to read-back OK. Call me lucky, but this is NXP, Freescale, Atmel, ST. Several chip types each.
In production, the chips get flashed once. Then maybe 3 times a year due to updates.

I’ve installed stm32duino on an older win7 32bit machine (1.6.10 nightbuild, Maple Mini, Bootloader 2).
DFU works, upload is ok.
Serial over USB – it shows in dev manager as “Mass Storage Device”, I’ve used Zadig 2.2.689 to replace it with Serial CDC, but no luck.
Still shows Mass Storage device on COM18..
PS:
After 4hours of messing with drivers it seems the issue was with Bluesoleil Bluetooth driver. After reinstalling it I see Maple as COM13 (without using zadig).
The other issue I see: when hw resetting Maple it ends up in DFU mode after the reset, so it does not continue into Serial (Maple COM13 does not appear in the dev manager). Pluging/unpluging also ends in DFU. Sometimes Maple COM appears, after the upload I get usually (port set to COM13):
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
error resetting after download: usb_reset: could not reset device, win error: The system cannot find the file specified.

Pito wrote:I’ve installed stm32duino on an older win7 32bit machine (1.6.10 nightbuild, Maple Mini, Bootloader 2).
DFU works, upload is ok.
<…>

Resetting USB to switch back to runtime mode
error resetting after download: usb_reset: could not reset device, win error: The system cannot find the file specified.

DFU util seems to randomly produce this error, but it doesn’t actually make any difference.

BTW. I tried removing the “reset” option from the DFU upload, but it stops the upload working.

But as this is more of an erroneous error message than a real problem I didnt pursue it further.

Re: Maple mini getting locked in DFU upload mode

Either its actually locked in upload mode (DFU), or the Maple mini has attempted to trigger USB enumeration and your PC / Mac has not noticed the enumeration.

If its actually locked in DFU upload mode, the LED on the maple mini will continue to flash quickly (indefinitely)
This can only really happen under 2 conditions.
(a). The “Button” is being pressed on the Maple ini
(b). The data in the sketch is not being recognized by the bootloader as a valid program that it can run

If the LED is not flashing quickly, the bootloader has handed control to the sketch and the sketch is running.

Upload a sketch that flashes the LED slowly e.g. delay(1000) and see if the flashing on the LED changes from quick flashing to the slow (1000ms) flash in the sketch)
I suspect in your case the sketch is running, and that your PC has not spotted the signal to re-enumerate

The other possibly option that should not be discounted is that your Maple mini board is faulty e.g. the circuit which resets the USB (to force re-enumeration) is not working e.g. dry joint or faulty component.

I started the stuff this morning and:
1. Maple COM13 appeared in dev man
2. I set port to Com13 in arduino
3. it uploaded and stopped with the message as above, and in DFU mode (I can see the DFU driver in dev man, I cannot see the MMCOM13 in dev man)
4. the LED on MM works as expected
5. after a hw reset I can see MMcom13 (DFU not visible) in dev man
6. after a next hw reset I cannot see MMcom13 (DFU visible) in dev man
5. after a next 2 hw resets I can see MMcom13 (DFU not visible) in dev man
6. when connected to TeraTerm com13 when MMcom13 in dev man is visible, I see correct results, so the MM sketch works..

I have done following test: pressing hw reset on MM every 10-15secs – it shows MMCOM13 once per 15 resets in average, otherwise lands in DFU mode.
PC: nvidia chipset, amd64x2..

Your system is not recognizing the USB reset signal sent by the Maple mini.

You could try modifing the core to change the reset pulse duration, and / or add a delay between the reset pulse and the USB subsystem starting up.

Is it not the bootloader stuff? Why core?

I did following changes in usb_serial.cpp:

...
/*
* USBSerial interface
*/

#define USB_TIMEOUT 200 //50

..
#define RESET_DELAY 400000 //100000
..

I always get that message. I don’t know what it means but it doesnt seem to matter.

Hmm, when working with my BT serial, the stuff stops to work reliably again. So the there is still an issue with the drivers..

Pito wrote:Is it not the bootloader stuff? Why core?

Hi pito

My generic stm32f103 also encounter usb serial issue.
see http://www.stm32duino.com/viewtopic.php?f=28&t=1631

Is it similar to your issue? what is going on now?

Pito wrote:I started the stuff this morning and:
1. Maple COM13 appeared in dev man
2. I set port to Com13 in arduino
3. it uploaded and stopped with the message as above, and in DFU mode (I can see the DFU driver in dev man, I cannot see the MMCOM13 in dev man)
4. the LED on MM works as expected
5. after a hw reset I can see MMcom13 (DFU not visible) in dev man
6. after a next hw reset I cannot see MMcom13 (DFU visible) in dev man
5. after a next 2 hw resets I can see MMcom13 (DFU not visible) in dev man
6. when connected to TeraTerm com13 when MMcom13 in dev man is visible, I see correct results, so the MM sketch works..

I have done following test: pressing hw reset on MM every 10-15secs – it shows MMCOM13 once per 15 resets in average, otherwise lands in DFU mode.
PC: nvidia chipset, amd64x2..