Problem with Baite Maple Mini and bootloader 2.0

Hi there, today I was trying to substitute my Baite Maple Mini bootloader (standard MM bootloader) with the 2.0 version (file “maple_mini_boot20.bin” taken from Github – I’m sure the file is OK).
I’m using ST’s COM application under Windows to upload via USART’s standard ST bootloader and the upload appears successful anyway, after uploading the 2.0 bootloader, the board is not responding anymore (no led blinks, no dfu) even resetting it.

Note: uploading back the standard maple mini bootloader instead brings back the board working fine.

Am I missing something?!

Thanks and bye, E.

Hi edogaldo

I think there is a problem with the latest build of the bootloader, but it only seems to effect some people

Unfortunately I have not been able to replicate the issue, and other people who have the problem have not been able to debug why it is not working

If possible can you look in the commits history and try some older versions, and let me know at which commit, the problem started ?

Thanks

Roger

RogerClark wrote:Hi edogaldo

I think there is a problem with the latest build of the bootloader, but it only seems to effect some people

Unfortunately I have not been able to replicate the issue, and other people who have the problem have not been able to debug why it is not working

If possible can you look in the commits history and try some older versions, and let me know at which commit, the problem started ?

Thanks

Roger

My MM bootloader showing 20.4.2016 (file timestamp) works fine on the maple mini clone – flashed via stlink.

Is that version the last version that works for you ?

i.e newer versions don’t work?

There is only one version – 20

Dear all, I created a new branch where I removed the GD part of the tree and perfomed a comparison between this branch and branch 00597b9b18 which seems to be the branch committing second-to-last version of “maple_mini_boot20.bin” (commit date 17/07/2015).

Here the comparison results: https://github.com/edogaldo/STM32duino- … o:mybranch

For what I can see there is only a change that seems strange (and possibly worng) to me, which is in file “STM32F1/usb.c” – row 44:
(-) SET_REG(GPIO_CR(USB_DISC_BANK,USB_DISC),(GET_REG(GPIO_CR(USB_DISC_BANK,USB_DISC)) & crMask(USB_DISC)) | CR_OUTPUT_OD << CR_SHITF(LED_PIN));
(+) SET_REG(GPIO_CR(USB_DISC_BANK,USB_DISC_PIN),(GET_REG(GPIO_CR(USB_DISC_BANK,USB_DISC_PIN)) & crMask(USB_DISC_PIN)) | CR_OUTPUT_OD << CR_SHITF(USB_DISC_PIN));

Best, E.

Thanks E.

I vaguely recall someone contacting me about a problem with the Pin number vs the bitmap of the pin.

It looks like that change is from this commit

https://github.com/rogerclarkmelbourne/ … b25aa8e749

However, the change just appears to be the name to signify that its the pin number and not the bit value of the pin

e.g.

- #define USB_DISC 9
+ #define USB_DISC_PIN 9

Are you sure this was the place the bug was introduced ?
No, I’m not sure this is the bug, it was just an idea based on following facts:

• current version is not working
• based on Pito’s post, previous version should be working (couldn’t anyway directly check it yet)
• most “particular” change (to me) was the one I highlighted

I’ll perform deeper checks as soon as I can and in case I’ll keep you posted.

[edit] anyway yes, LED_PIN = 1 = ( USB_DISC_PIN – 8 ) so this could be an indicator that, as you supposed, there could be a problem in CR_SHITF..

what about changing it to:
#define CR_SHITF(pin) ((pin & 0x07)<<2)

I’ve been compiling the latest source version for my BluePill disconnect pin PB2 and it works fine with BluePill (it compiles for MM basically, so the BluePill with an external pmos transistor is basically the same as MMini with disconnect at PB2). My understanding therefore is the latests source is ok.

The checksums of the maple_mini_boot20.bin dated 20.4.2016 I flashed into my MMini on 21.4.2016 (I did not compile it, but downloaded as-is) are:
CRC-32: 7e4a31b6
MD4: 6d8c354fa9620d258b38c505e3dd00f8
MD5: 9dc7cae7c488420192ad3b2441dd1592
SHA-1: 5a2915fb37ebfc023c070740056a98e1bc047680

Pito wrote:I’ve been compiling the latest source version for my BluePill disconnect pin PB2 and it works fine with BluePill (it compiles for MM, so the BluePill with an external pmos transistor is basically the same as MMini with disconnect at PB2). My understanding therefore is the latests source is ok.
The checksums of the MMv20.bin dated 20.4.2016 I flashed into my MMini on 21.4. are:
CRC-32: 7e4a31b6
MD4: 6d8c354fa9620d258b38c505e3dd00f8
MD5: 9dc7cae7c488420192ad3b2441dd1592
SHA-1: 5a2915fb37ebfc023c070740056a98e1bc047680

There is no difference between generic and maplemini sources except 3 lines handling the disconnect pin.
The MM_20.bin above works fine with my MMini clone.
I suspect the STM flashing utility is your problem. Try to flash it with stlink (clone).

Ok, problem solved!

It seems that the “maple_mini_boot20.bin” available on GitHub is corrupted.
I recompiled it with no changes and the new file is different and working fine!

By the way, I recompiled all the bins and the only file that compiled differently was this one..

My guess is that it got corrupted because in the make_all.bat file there is no “make clean” before the “make maple-mini” like for the other builds; this can lead to file corruption if the compilation folder is not clean (i.e. running “make_all.bat” more than once consecutively).

@Roger: I’d kindly ask you to recompile the file and update GitHub.

ps: about
#define CR_SHITF(pin) ((pin - 8*(pin>7))<<2)

The checksums of the current github binary:
File: maple_mini_boot20.bin
CRC-32: eb11a422
MD4: 17a76aa2fe920162c880d792721897d6
MD5: e43dd145f20152152630ab27a9064d4d
SHA-1: 0dc1a29e5409da3e4144f72516b805e91951671d

Thanks guys

I will update the make all bat , recompile and upload new binaries.

Actually I think of of the new targets is not in the bat file, as I forgot to add it ( but i compiled it manually)

It would be good if the problem was just as simple as a corrupt binary.

Guys

I’ve added a make clean to the start of the batch file and have run it to recompile them all.

Only the maple mini bootloader binary actually changed, which proves what @edogaldo has diagnosed as the problem

I’ve commited the change to male_all.bat and maple_mini20.bin to github

@edogaldo thanks again for your help in tracking this down.

Hi Roger, I can confirm that now the new “maple_mini_boot20.bin” from GitHub corresponds to the version I compiled and is working fine.

You’re welcome!

Best, E.

Thanks @edogaldo

That’s one more mystery solved.

PS. I’ve not changed the macro, but I agree your macro is better.

RogerClark wrote:PS. I’ve not changed the macro, but I agree your macro is better.