Problem with Baite Maple Mini and bootloader 2.0

Discussion about the Maple and other bootloaders
edogaldo
Posts: 247
Joined: Fri Jun 03, 2016 8:19 am

Problem with Baite Maple Mini and bootloader 2.0

Postby edogaldo » Thu Aug 18, 2016 10:14 pm

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.

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

Re: Problem with Baite Maple Mini and bootloader 2.0

Postby RogerClark » Thu Aug 18, 2016 11:55 pm

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

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

Re: Problem with Baite Maple Mini and bootloader 2.0

Postby edogaldo » Fri Aug 19, 2016 6:42 am

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


Hi Roger, thanks for the update!
I'll try to go back the history searching for a working version and breaking changes.
Just a question: when you say that you have not been able to reproduce the issue you mean that latest bootloader 2.0 is working fine on your Baite maple minis (by the way, I mean those with the Baite logo and the AMS1117 as ldo)?

Thanks and bye, E.

User avatar
Pito
Posts: 994
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Problem with Baite Maple Mini and bootloader 2.0

Postby Pito » Fri Aug 19, 2016 7:05 am

My MM bootloader showing 20.4.2016 (file timestamp) works fine on the maple mini clone - flashed via stlink.
Pukao Hats Cleaning Services Ltd.

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

Re: Problem with Baite Maple Mini and bootloader 2.0

Postby RogerClark » Fri Aug 19, 2016 8:14 am

Is that version the last version that works for you ?

i.e newer versions don't work?

User avatar
Pito
Posts: 994
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Problem with Baite Maple Mini and bootloader 2.0

Postby Pito » Fri Aug 19, 2016 9:19 am

There is only one version - 20 :)
Pukao Hats Cleaning Services Ltd.

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

Re: Problem with Baite Maple Mini and bootloader 2.0

Postby edogaldo » Fri Aug 19, 2016 10:16 am

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.

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

Re: Problem with Baite Maple Mini and bootloader 2.0

Postby RogerClark » Fri Aug 19, 2016 10:51 am

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.

Code: Select all

-   #define USB_DISC            9
+   #define USB_DISC_PIN            9



The change at line 44 does look like a bug fix

Code: Select all

-  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)); 
-  gpio_write_bit(USB_DISC_BANK,USB_DISC,1);

+  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)); 
+  gpio_write_bit(USB_DISC_BANK,USB_DISC_PIN,1);


As it doesnt make any sense to use the LED_PIN when sifting the bit pattern to put the mode of the pin into OD

Code: Select all

CR_SHITF(LED_PIN)


From what I recall the code only intially worked if LED_PIN was the same as USB_DISC_PIN, or if LED_PIN was USB_DISC_PIN - 8

This is because the way that each GPIO port has 2 control registers (CR High and CR Low), and there is a macro to generate the bit pattern

Code: Select all

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


So that if LED_PIN = 1 and USB_DIS_PIN = 9 it would work, even though the code is wrong

I think I wrote the macro

Code: Select all

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


So perhaps it does not work correctly, i.e what I hoped would happen is

that 8*(pin>7) would resolve to 8 for pins greater than 7 and 0 for pins less then 7, hence

((pin - 8*(pin>7)) is supposed to always resolve to a number between 0 and 7, for both pins 0 to 7 and also pins 8 to 15.

Then I think the pin is multiplied by 4 to generate the correct number to shift the output mode

In hindsight, I should have not used macros, and should have just written a function which did this correctly using if() etc

But I think, in my defense, the code was already full of macro's and I just followed on from the last author (leaflabs plus various other contributers)


However, this still doesn't really solve the problem , if it occurs at this commit.

Are you sure this was the place the bug was introduced ?

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

Re: Problem with Baite Maple Mini and bootloader 2.0

Postby edogaldo » Fri Aug 19, 2016 12:04 pm

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:

Code: Select all

#define CR_SHITF(pin) ((pin & 0x07)<<2)


[edit2] by the way, shouldn't it be:

Code: Select all

#define CR_SHITF(pin) (2<<(pin & 0x08))

instead?!


Best, E.
Last edited by edogaldo on Fri Aug 19, 2016 12:39 pm, edited 1 time in total.

User avatar
Pito
Posts: 994
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Problem with Baite Maple Mini and bootloader 2.0

Postby Pito » Fri Aug 19, 2016 12:38 pm

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:

Code: Select all

CRC-32: 7e4a31b6
   MD4: 6d8c354fa9620d258b38c505e3dd00f8
   MD5: 9dc7cae7c488420192ad3b2441dd1592
 SHA-1: 5a2915fb37ebfc023c070740056a98e1bc047680


The checksums of the maple_mini_boot20.bin I've compiled now are:

Code: Select all

  File: maple_mini_boot20.bin
CRC-32: 7e4a31b6
   MD4: 6d8c354fa9620d258b38c505e3dd00f8
   MD5: 9dc7cae7c488420192ad3b2441dd1592
 SHA-1: 5a2915fb37ebfc023c070740056a98e1bc047680
Last edited by Pito on Fri Aug 19, 2016 12:51 pm, edited 5 times in total.
Pukao Hats Cleaning Services Ltd.


Return to “Maple Bootloader”

Who is online

Users browsing this forum: No registered users and 1 guest