STM32, Maple and Maple mini port to IDE 1.5.x

Other Hardware 3rd Party Boards
1201

Ray

Re: Adafruit

I'm not sure who their message about not re using their VID is aimed at.

I presume its other suppliers. Telling any hobbyist that they can't make a trinket or similar device from scratch and the program it with those VIDs seems be counter to the whole Maker / Open source hardware / Open source hardware ethos.

I wonder how this whole VID thing works for all the clone Leonardo and Pro Micro boards.

They must be using Arduino Industries VID.

With regard to Adafruit getting their VID etc ncluded into other projects.

I've noticed this a lot with both Adafruit, and PJRC etc, not just for VIDs but also in terms of what hardware is supported by the Libraries that Arduino ships with, or the official libraries that you can download.
PJRC, who are a commercial organisation, host the OneWire library, and possibly some others ( I can't remember off the top of my head)

Arduino Industries, seem to be moving away from Open Source hardware with their new boards, and are looking increasingly like any other commercial company.

I recall when I posted a question to the Arduino developers group, regarding issues with supporting new hardware in Libraries, I was basically lambasted by PJRC and told I should be buying hardware that is commercial supported.

S as it stands there are still significant barriers to new hardware being integrated into the Arduino family.
This is being reinforced by Microsoft and Apple, which both now require signed drivers, albeit it is possible to disable this requirement on both OSs if you try hard enough, and I think its easier to disable on OSX than it is on Windows , as its in a control panel on OSX I think.

I'm not sure what's happening with Windows 10 and whether this will make things worse again.

Ahull

Did that change get implemented, the link you sent is just a proposal as far as I could tell

Re: Wndows drivers in general.

I think this needs a bit more research.

Assuming Leaflabs didn't write the windows serial drivers... Then they are probably emulating some existing device and have just changed the VID in the inf file to match the VID the Maple bootloader uses.

I intend to rebuild the Maple bootloader from source soon, because my IteadMaple version works fine, but my Maple mini does not. So whatever bootloader is in the Maple is it the same as in the Maple mini.

I did try downloading the iTead Maple bootloader from its Flash using USB to Serial, but when I uploaded to the Maple mini it didn't work. So there may be a binary difference for the two processors, that is configured in the build process.

Anyway, if I can rebuild the bootloader from source code, I can change the vid, well I can do this by hacking the binary I suppose, as its easy to find those patterns.

And I could try loading VIDs for Prolific , FTDI and a few other USB to serial devices and see if any of their drivers work with the bootloader.

I may also post an issue to the Maple IDE on GitHub and perhaps Martin may respond about where the sources are to the drivers, but he has not responded to some of my other questions, so I don't hold out much hope on that front.

PS. USB Serial on OSX

I did take a look at it yesterday evening, and I started to change platform.txt so that there can be an upload_router script for OSX.

I didn't get that far, but it looks quite feasible to do.

I'm hoping to build the stm32flash uploader to an OSX binary, but it will depend if OSX is a Posix compliment system.

If not the python route should work, but is more of a pain for users to install.

I guess also the same applies to Linux, but I'm not sure about distribution of binaries, for different flavours of Linux. I guess I could include the source and a make file on Linux.

1202

rogerClark:
Assuming Leaflabs didn't write the windows serial drivers... Then they are probably emulating some existing device and have just changed the VID in the inf file to match the VID the Maple bootloader uses.

The "dfu" driver is the opensource libusb-win32 driver and the "serial" driver is Microsoft's usbser driver. A few posts back I posted an installer (wdi-simple) which can install the libusb-win32 and usbser drivers for any vid/pid. It self-signs the .inf files. I am still waiting for my Maple Mini clones to arrive so I only tested it with my Arduino Micro clone.

1203

@timschuerewegen

Thanks for the info.

I think it missed your previous post, or didn't understand what you were saying.

Sorry about that.

Re: Microsoft usbser

OK.

So, all we need is a modified Inf file that has the LeafLabs VID and PID for the Maple board, but your wdi does all the hard work :wink:

I will download your files and try them on my Windows 7 machine that I have not messed around with too much.

And if it works I'll include those files in the repo (probably uncompressed to make things easier for people)

Re:

It self-signs the .inf files.

The inf files are not signed, only the binaries are signed.

I'll take a look at that WDI stuff to see if it actually does re-sign the binaries, or whether its just installing the information in the inf files into the registry

Anyway, I'll give it a go

Thanks

Roger

1204

rogerClark:
The inf files are not signed, only the binaries are signed.

They are. The installer generates a .cat file which contains the thumbprint of the .inf file and signs it using an autogenerated and installed certificate. If you modify the .inf file and try to install the driver manually then Windows 8.1 x64 says "blah blah unsigned blah blah goodbye".

1205

If you modify the .inf file and try to install the driver manually then Windows 8.1 x64 says "blah blah unsigned blah blah goodbye".

umm.

Interesting

Modifying the inf file is not an issue on Windows 7 x64, but I'd not tried it on Windows 8.1

I know have a copy of 8.1 installed, so I can give it a go with my Canon scanner, which I had to modify the inf in order to use a newer driver.

Umm. Except I've disabled driver signing on my 8.1 machine,

I guess I"ll need to turn it back on again...

arrggghhh

1206

This is what happens when I modify the date in the .inf file.

1207

And this is the autogenerated certificate.

1208

Tim

That's excellent.

I knew that self signing was an option and I'd seen explanations on how to use the Microsoft DDK to do it, and I'd got as far as downloading the DDK at the weekend

But the solution you found is much simpler and gets around other issues in Windows 8.1,that I didn't know existed, as I only installed 8.1 at the weekend

I'm not at home at the moment, but I will endevour to include your stuff into the repo in the next day or two and update the wilki

Thanks again

Roger

1209

Tim,

I tried running that wdi-simple.exe on my Windows 7 x 64 machine, but although windows seemed to re-load the maple driver after the exe had infinished, the driver still didnt load.

This could be because I'd already got it working with the original driver that is in the Repo, which is from the Maple IDE installer.

I'll try rebooting my machine into the mode that disables the need for driver signing, and perhaps I can remove the driver that I originally installed.

I also have a laptop running Windows 7, so I could try it on that one later

Cheers

Roger

1210

@timschuerewegen

I tried using the zip file you posted, but I can't get it to work on any of my Windows 7 machines, including ones that have never had any Arduino stuff on them.

What driver does the file you attached to your posting sign ? Is it the Maple usb serial device, or was it the one for the Arduino Micro ?

The Diff file you posted seemed to suggest it was for the Maple as it had the VID 1EAD in it, but I decompressed the EXE but it was hard to tell what was in the exe package as it contained literally thousands of files if fully unpacked.

can you explain how you built the exe ?

I have VS2013 so I could rebuild it if necessary, I'm just not sure how you did it ??

1211

rogerClark:
What driver does the file you attached to your posting sign ? Is it the Maple usb serial device, or was it the one for the Arduino Micro ?

Type "3" will extract/sign/install the USB modem (usbser.sys) driver. It's only an .inf file, the driver file itself (usbser.sys) is part of Windows.

rogerClark:
The Diff file you posted seemed to suggest it was for the Maple as it had the VID 1EAD in it, but I decompressed the EXE but it was hard to tell what was in the exe package as it contained literally thousands of files if fully unpacked.

I added the fake 0x1EAF VID because libwdi puts the name of the vendor in the .inf file.

rogerClark:
can you explain how you built the exe ?

With VS2013. You need some extra files for the embedder thing. Their location is specified in config.h. Mine are located in c:\temp.

https://dl.dropboxusercontent.com/u/94421767/libwdi-extra-files.7z

1212

rogerClark:
I tried running that wdi-simple.exe on my Windows 7 x 64 machine, but although windows seemed to re-load the maple driver after the exe had infinished, the driver still didnt load.

If you add "--log 0" to the commandline you can see what both libwdi and windows are (not) doing. I found and fixed a bug in wdi-simple (see earlier post for v3 exe/diff) where it would try to install the driver for the wrong device if your device supports multiple interfaces (aka USB composite device).

wdi-simple-log-win7-x64.txt (50.1 KB)

1213

Hello, I need some help with the Nucleo-F103RB Board. As posted before, I cannot even get a simple blink running.
Steps I've done:
Add a new board description:

maple.name=Nucleo F103RB

maple.upload.tool=stlink
maple.upload.protocol=stlink
maple.upload.maximum_size=108000
maple.upload.use_1200bps_touch=false
maple.upload.file_type=bin
maple.upload.ram.maximum_size=17000
maple.upload.flash.maximum_size=108000
maple.upload.usbID=1EAF:0003
maple.upload.altID=1
maple.upload.auto_reset=true

maple.build.mcu=cortex-m3
maple.build.f_cpu=72000000L
maple.build.core= maple
maple.build.extra_flags=-DMCU_STM32F103RB  -mthumb -DSTM32_MEDIUM_DENSITY -march=armv7-m  -D__STM32F1XX__  
maple.build.ldscript=ld/jtag.ld
maple.build.variant=maple
maple.build.variant_system_lib=libmaple.a
maple.build.vect= VECT_TAB_BASE
maple.build.density=STM32_MEDIUM_DENSITY
maple.build.error_led_port=GPIOA
maple.build.error_led_pin=5
maple.build.gcc_ver=gcc-arm-none-eabi-4.8.3-2014q1
  • Compiling&uploading with no error, but no function.
  • I also added a blink skript switching 32 outputs high/low - so it´s not a pin redirection fault.
  • I also added from the original libmaple the "Nucleo-F103RB" files as "variant"
  • manual uploading with the STM-Link utility
  • Tested OS: OSX & Windows7
  • tried both: maple.build.vect= VECT_TAB_BASE and VECT_TAB_FLASH

So where I missed something?
Thanks&regards Matthias

1214

@madias

Could it be that the .bin file you are uploading starts at the wrong address? Is it expecting the Maple bootloader to be there and thus it is linked to start at a different address?

Maybe something to look into.
http://forums.leaflabs.com/topic.php?id=10278

Regards,
Mike

1215

dear mikewop,
I have the previous posted settings from this leaflabs thread :slight_smile:
I thought this could be the problem, so I uploaded the file with the st-link-utility on base address 0x08000000, but with no luck either.

1216

@madias

It should work ok

Use generic option, second to last, ie the one above Microduino

Turn on verbose in your preferences.

Look at the output from the verbose compile it will show where the bin file is located.

Use that address with STMs own STLink uploader GUI and load and run at 0x8000000 it should at least blink

I have done this with an external stlink adaptor

1217

@madias

Just as a matter of interest.

Can you tell me what you normally use to develop on you Nucleo board? E.g Keil, or CooCox or Em:Blocks etc

Can you tell me if there is an equivalent of Serial.read() that you use?

I can see how possibly we can make Serial.print() work through STLink, but not Serial.read()

Do you think that if STlink upload was an option that Serial.print() etc should be redirected to the STLink?
Rather than Hardware Serial 1.

Or do you think it would be better to have another api call e.g. Debug.print() for this?

1218

@madias

I'm not at home at the moment, but looking on my iPad at the GitHub repo files,

If you look in boards.txt at this block of text

##############################################################
maple_STM32.name=STM32 to Flash - No bootloader

maple_STM32.upload.tool=serial_upload
maple_STM32.upload.protocol=stm_serial
maple_STM32.upload.maximum_size=108000
maple_STM32.upload.use_1200bps_touch=false
maple_STM32.upload.file_type=bin
maple_STM32.upload.ram.maximum_size=17000
maple_STM32.upload.flash.maximum_size=108000

maple_STM32.upload.usbID=1EAF:0003
maple_STM32.upload.altID=1
maple_STM32.upload.auto_reset=true

maple_STM32.build.mcu=cortex-m3
maple_STM32.build.f_cpu=72000000L
maple_STM32.build.core=maple
maple_STM32.build.extra_flags=-DMCU_STM32F103CB -mthumb -DSTM32_MEDIUM_DENSITY  -march=armv7-m  -D__STM32F1XX__ 
maple_STM32.build.ldscript=ld/jtag.ld
maple_STM32.build.variant=maple_mini
maple_STM32.build.variant_system_lib=libmaple.a
maple_STM32.build.vect=VECT_TAB_FLASH
maple_STM32.build.density=STM32_MEDIUM_DENSITY
maple_STM32.build.error_led_port=GPIOB
maple_STM32.build.error_led_pin=1
maple_STM32.build.gcc_ver=gcc-arm-none-eabi-4.8.3-2014q1

##############################################################

Then change where it says serial_upload. To stlink_upload

Quit and restart the Arduino IDE on windows, and select that option, it should use the STLINK files which are the command line version of STMs own STLink program.

I have tested this on my board and it worked.

Albeit your board has more ram and more Flash, but this doesn't normally stop it working, it just doesn't allow you to use all the flash.

In the long term we either need to add Nucleo as a board in the list, in which case we need to know what's nucleo you have.
Or we add it to the complex menuing system that Alexey created. But I think to add STLINK upload to the menus requires duplicating loads of lines in boards.txt, but I may be wrong.

So perhaps adding the Nucleo board type would be better

Edit

Looks like I failed to commit some changes to platform.txt to support the stlink stuff and I think I've since overwritten platform.txt when doing other pull request testing :frowning:

I'll need to re-write the section in platform.txt, but from what I can remember I basically just duplicated the serial_upload section and modified it a bit.

I'm at home now, so I will try to get this resolved by adding a Nucleo STM32F103RB board type to the menu boards menu

1219

@madias

OK.

I've added a new board type of Nucleo STM32F103RB (STLINK)

I have tested it with my external STLink adaptor (clone) and it works fine to my F103C8 board, so it should work OK with your RB board.

Here is the test blink sketch I used

void setup() {
  // put your setup code here, to run once:
pinMode(PC13,OUTPUT);
}

void loop() {
  // put your main code here, to run repeatedly:

digitalWrite(PC13,!digitalRead(PC13));
delay(50);
}

Note, your LED will probably not be on PC13, so you'll need to change this to the pin your LED is attached to (in both places in the code - I know I should have used a #define but I just wanted to do a quick test so its not the most elegant code)

I'm not sure how it works on the Nucleo boards, but with my external STLink on the F103 boards, I appear to have to manually reset the board before uploading, I also need to set Boot0 to HIGH on my board

However its possible that on the Nucleo things work differently and that there are additional connections between the STLink section of the board and the main microcontroller.

On my board I have a reset line but no other lines from the STLink board that I can connect to boot0

Its possible that perhaps one of the pins in the STM32F103C8 that is on my STlink board may be being toggled to connect to Boot0 on the target board, but I'm not an expert on STLink and generally dont use it.

If the upload doesn't seem to work for you, and you cant set Boot0 to HIGH on your board e.g. via a jumper, its possible that you'll need to change the arguments sent to STMs CLI exe

see the stlink_upload.bat file and reference the docs for the CLI (which are at the end of the docs for the windows GUI version of the STLink program), as you may need to set some more options

Failing that, use the verbose output to find the bin file and manually upload it using the windows GUI version of STLink utility

1220

Dear Roger,
sadly nothing you posted I didn't tried out. I think you meant "stlink" instead of "stlink_upload"?
The Board is a "Nucleo-F103RB" - so the same type of mcu as the "normal" maple.
Even with your modification (it's more or less the same as mine) the same result: code will be uploaded, but then the board does nothing, not even an error log in the root (this is the new function of ST-Link2.1: the device is like a flash device, but when there is a problem there is an error log in the root).
I only played around with mbed (the online ide) getting quit good results with TFT and so on. But I don't like online IDE's and wanna get rid of windows.
I also tried out such stupid things like upload the maple bootloader at 0x8000000 and loaded up a the sketch at 0x8005000. I also compared the RAM on the MCU with the *.bin file: no difference. I wrote a code with 30 pins toggling and so on....
So I have no clue anymore. Maybe a problem with ST-Link2.1 ? But I don't think so...
BTW: I think a "debug.print" would be fine!

OK: Maybe a super super stupid thing? - The (missing) oscillator! As I looked at the board, there was something missing for me: the quartz. So I read this document:
http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00105823.pdf

OSC clock supply
There are four ways to configure the pins corresponding to external high-speed clock
external high-speed clock (HSE):
• MCO from ST-LINK: MCO output of ST-LINK MCU is used as input clock. This
frequency cannot be changed, it is fixed at 8 MHz and connected to PF0/PD0/PH0-
OSC_IN of STM32 microcontroller.
The following configuration is needed:
– SB54 and SB55 OFF
– SB16 and SB50 ON
– R35 and R37 removed
• HSE oscillator on-board from X3 crystal (not provided): for typical frequencies and
its capacitors and resistors, please refer to STM32 microcontroller datasheet. Please
refer to the AN2867 for oscillator design guide for STM32 microcontrollers.The X3
crystal has the following characteristics: 8 MHz, 16 pF, 20 ppm, and DIP footprint. It’s
recommended to use 9SL8000016AFXHF0 manufactured by Hong Kong X'tals
Limited.
The following configuration is needed:
– SB54 and SB55 OFF
– R35 and R37 soldered
– C33 and C34 soldered with 20 pF capacitors
– SB16 and SB50 OFF

So maybe there is a config problem? The main osc takes the freq. from the st-link quartz. Sadly I only have a 8-mhz-quartz, but no smd (resistors/caps) components at home(resistor/cap) yet.