Strange Baite Mini USB behavior

Chuck(G)
Posts: 9
Joined: Sat Jun 18, 2016 10:42 pm
Location: Oregon, USA

Strange Baite Mini USB behavior

Postby Chuck(G) » Tue Aug 30, 2016 5:39 pm

I've been having a good deal of success with the Chinese "Baite" mini clones, but yesterday I ran into an issue.

First off, I've been using the original USB bootloader in these things (my PC OS is Ubuntu), but I have an ST-Link V2.

I'd been playing with a USB-com application and fumbled and compiled for the standard Maple, not the mini. Of course, it didn't work. But after that, I found that the mini was no longer seen as a USB device, even though the LED activity seemed to show that the bootloader was still present. Using the ST-Link, I've reloaded the original bootloader firmware (from another board) and tried the 2.0 mini bootloader from Roger's git collection. Same thing over and over.

Dmesg shows the following:

Code: Select all

 4050.337547] usb 5-1: new full-speed USB device number 2 using ohci-pci
[ 4050.506701] usb 5-1: New USB device found, idVendor=1eaf, idProduct=0003
[ 4050.506713] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4050.506720] usb 5-1: Product: Maple 003
[ 4050.506726] usb 5-1: Manufacturer: LeafLabs
[ 4050.506732] usb 5-1: SerialNumber: LLM 003
[ 4052.709486] usb 5-1: USB disconnect, device number 2


After the auto disconnect, lsusb doesn't show the device. Pressing the reset button or putting the thing into perpetual bootloader mode produces the same result--recognition, then disconnect.

Does anyone have any idea what has happened? I don't mind binning this board too much, given the low cost, but I'm afraid of ruining the whole lot of what I have, which would be annoying and uninstructive to say the least.

edogaldo
Posts: 214
Joined: Fri Jun 03, 2016 8:19 am

Re: Strange Baite Mini USB behavior

Postby edogaldo » Tue Aug 30, 2016 5:50 pm

My guesses:
  • the bootloader thinks there is a valid sketch within the device and gives the control to it, unforunately there is no valid sketch so the MM is not enumerated as a Serial device
  • the bootloader thinks there is a valid sketch within the device and gives the control to it, the sketch is valid but you don't have the COM driver installed thus the device is not enumerated as a COM device (don't know if linux needs the COM driver too)

Chuck(G)
Posts: 9
Joined: Sat Jun 18, 2016 10:42 pm
Location: Oregon, USA

Re: Strange Baite Mini USB behavior

Postby Chuck(G) » Tue Aug 30, 2016 5:59 pm

Thanks for the opinion. I thought that the "perpetual bootloader" mode would bypass the looking for a sketch. But maybe not.
My next step will be to erase all flash to zeroes and then reinstall the bootloader. I'm thinking that it's got to be something very simple that I've overlooked.

I'll post my results later.

edogaldo
Posts: 214
Joined: Fri Jun 03, 2016 8:19 am

Re: Strange Baite Mini USB behavior

Postby edogaldo » Tue Aug 30, 2016 6:20 pm

I thought that the "perpetual bootloader" mode would bypass the looking for a sketch. But maybe not.

yes, it should be effectively, anyway..
Try also uploading an empty sketch if the bootloader is working (maybe you can win by resetting the board just before the IDE is starting the upload); if the problem is an invalid sketch then this could fix..

Chuck(G)
Posts: 9
Joined: Sat Jun 18, 2016 10:42 pm
Location: Oregon, USA

Re: Strange Baite Mini USB behavior

Postby Chuck(G) » Tue Aug 30, 2016 6:48 pm

Success! Using the stlink and openocd, I did a "flash erase_sector 0 0 last" and followed with a "flash write_image unlock maple_mini_boot.bin 0x08000000" and that did the trick. Apparently, the "perpetual bootloader" mode doesn't prevent the code from looking for a sketch.

Something useful to file away.

Given that I've got an ST-Link in my toolkit, can I flash a sketch directly without a bootloader? If so, what's the procedure? (I've tried flashing a sketch directly to 0x08000000, and it doesn't work).

User avatar
RogerClark
Posts: 5470
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Strange Baite Mini USB behavior

Postby RogerClark » Tue Aug 30, 2016 9:00 pm

Chuck(G) wrote:Success! Using the stlink and openocd, I did a "flash erase_sector 0 0 last" and followed with a "flash write_image unlock maple_mini_boot.bin 0x08000000" and that did the trick. Apparently, the "perpetual bootloader" mode doesn't prevent the code from looking for a sketch.

Something useful to file away.

Given that I've got an ST-Link in my toolkit, can I flash a sketch directly without a bootloader? If so, what's the procedure? (I've tried flashing a sketch directly to 0x08000000, and it doesn't work).



Just select the STLink upload option, this changes all the defines and selects the correct linker file etc etc

Note, this sill runs USB serial, as STLink dongles do not have USB CDCACM ( serial )

If you dont want USB serial e.g you have a STLink board with serial passthrough to USB CDCACM, you would need to modify boards.txt and remove the defines that control the compilation of the USB code

Chuck(G)
Posts: 9
Joined: Sat Jun 18, 2016 10:42 pm
Location: Oregon, USA

Re: Strange Baite Mini USB behavior

Postby Chuck(G) » Wed Aug 31, 2016 12:31 am

Okay, I do find this all a bit confusing. I've use the STM Peripheral Support library to create programs loaded at 0x08000000 and they run just fine. But not so with the Maple sketches.

Exactly what is it about the Maple sketches that's different from loading and entry aspect?

User avatar
RogerClark
Posts: 5470
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Strange Baite Mini USB behavior

Postby RogerClark » Wed Aug 31, 2016 2:03 am

Chuck(G) wrote:Okay, I do find this all a bit confusing. I've use the STM Peripheral Support library to create programs loaded at 0x08000000 and they run just fine. But not so with the Maple sketches.

Exactly what is it about the Maple sketches that's different from loading and entry aspect?


The codebase that we use is a clean-room implementation of a API to the STM32 hardware which was originally written my LeafLabs for their Maple range of boards

It does not use any STM code (well virtually none)

The reason Leaflabs had to write it from scratch was back in 2012 when they wrote the code, that the STM license was not compatible with OpenSource development.

(STM have only made their HAL SPL OpenSource friendly around 6 months ago)


All that being said, the code does run fine from 0x800000 if you select the correct options e.g. Serial upload or STLink upload or BMP upload

But the whole system is setup so that normal Arduino users don't need to understand what goes on under the hood.
For 99% of users, it works the way they expect (and I think 90% of people use the bootloader as they don't have STLink etc and sometimes don't even have a USB to Serial converter (the Maple mini board comes pre-flashed with the bootloader))

Chuck(G)
Posts: 9
Joined: Sat Jun 18, 2016 10:42 pm
Location: Oregon, USA

Re: Strange Baite Mini USB behavior

Postby Chuck(G) » Wed Aug 31, 2016 4:16 am

Thanks Roger.

In some ways, the Leaflabs API is a lot more straightforward that the STM one. The other issue is that if you start doing anything serious, the amount of library code starts getting pretty large with the STM codebase.

I'll check out the STLInk upload options.

User avatar
RogerClark
Posts: 5470
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Strange Baite Mini USB behavior

Postby RogerClark » Wed Aug 31, 2016 4:37 am

@Chuck(G)

The API is and binary size is smaller than the SPL, but is not so fully featured.

Several functional blocks are not supported, most notably CAN, and SDIO

CAN is an issue as it shares the ISR with USB

SDIO has just never been written, probably because only the very last Leaflabs product (the Maple RET5) could possibly support SDIO (as it uses a STM32F103RET)

The bootloader and USB serial system developed by Leaflabs, separates the DFU upload into the bootloader and the Serial into the sketch
(This confuses a lot of people as they think the bootloader also handles Serial and wonder why a serial device does not appear at the same time as the DFU device)

From what I've read Leaflabs had to do it that way, to support Windows XP (which was their primary OS version at the time)

But the whole idea of the sketch providing USB Serial still gets a lot of questions on the forum

I few people have investigated building a composite USB bootloader but they all seem to have run into problems with it, on different versions of Windows


Return to “Maple mini”

Who is online

Users browsing this forum: No registered users and 1 guest