Maple Bootloader 2.0

Discussion about the Maple and other bootloaders
User avatar
RogerClark
Posts: 5561
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Maple Bootloader 2.0

Postby RogerClark » Fri May 01, 2015 11:51 am

Bob and Victor

Rethinking this. ... Ignore my posting below

Whichever way I do this, its going to be a bit of a hack.

I will remove the RAM upload option, by returning an error if ALT ID 0 is selected.
I will see if there is a way to return an error message under the DFU protocol

----------------- ignore the rest of the posting ------------


Apart from just dropping the RAM upload entirely, which is still probably the best idea,

I was toying with the idea of doing this as a test (see below)

If I use __attribute__ ((section (".noinit")))

I think its going to tell the compiler not to initialise any variables at all.

so the global unsigned long ramUploadMagic; won't get initialised after a warm boot, hence if I set it to a big magic number after the RAM upload is complete, when it boots again, when the code reads the value of this, it should contain the same magic number

i.e this relies on the fact that the code compiler will put the location of that global variable in the same place in ram ever time

But I guess this could be seen as a bit of a hack

The other option is just to use a hard coded pointer to 8 bytes at the top of RAM

I know either way is not fool proof, but the only way to do this in a foolproof manner is to save the value in flash / eeprom

Edit. BTW. Yes. I know the bootloader may not work at all with the noinit setting as the code may be relying on C setting a variable to zero, so that would need to be sorted out first, ie make sure there is code to init every var that needs to be init'ed. (personally I always do this anyway)



Code: Select all

#include "common.h"
#include "dfu.h"
extern volatile dfuUploadTypes_t userUploadType;
__attribute__ ((section (".noinit")))
unsigned long ramUploadMagic;
#define RAM_UPLOAD_MAGIC 0x1eaf1abs
int main()
{
    systemReset(); // peripherals but not PC
    setupCLK();
    setupLED();
    setupUSB();
    setupBUTTON();
    setupFLASH();

    strobePin(LED_BANK, LED, STARTUP_BLINKS, BLINK_FAST);

   /* wait for host to upload program or halt bootloader */
   bool no_user_jump = (!checkUserCode(USER_CODE_FLASH0X8005000) && !checkUserCode(USER_CODE_FLASH0X8002000)) || readPin(BUTTON_BANK,BUTTON);
   int delay_count = 0;

    while ((delay_count++ < BOOTLOADER_WAIT) || no_user_jump)
   {

        strobePin(LED_BANK, LED, 1, BLINK_SLOW);

        if (dfuUploadStarted())
      {
            dfuFinishUpload(); // systemHardReset from DFU once done
        }
    }

   if (ramUploadMagic==RAM_UPLOAD_MAGIC)
   {
      // if we have just uploaded to RAM, then run whats in RAM
      jumpToUser(USER_CODE_RAM);
   }       
   else

victor_pv
Posts: 1237
Joined: Mon Apr 27, 2015 12:12 pm

Re: Maple Bootloader 2.0

Postby victor_pv » Sat May 02, 2015 2:16 pm

Roger, remember there is a string in the code that identifies each ID?
The one that shows something like "DFU Flash 0x8005000".
What about changing that for the ram ID, so it shows something like "Upload to RAM NOT SUPPORTED".
As that string is returned by the bootloader when an option is selected, if you can return that before an error code, anyone looking for why his upload to RAM failed, should be able to read the message right there.
That could be an option to return a message.

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

Re: Maple Bootloader 2.0

Postby RogerClark » Sat May 02, 2015 9:01 pm

Hi Victor,

Great minds think alike ;-)

BTW.

Because those messages are a pain to put into the code because every character seems to need a zero byte after it ( not sure why, perhaps its Unicode )

In the bottom of usb_desciption.c , I put a small JavaScript utility, as a comment.
If you copy the commented HTML js code to a temporary HTML file and open it in the browser
It spits out the code for the 3 ALT ID arrays, so save having to do them by hand.

I have figured also worked out,what the Mask stuff in the config does. It's to mask off the 4 bits in the control register when the bootloader sets the pin mode of the led as output and the button as input.

So if I get chance I will add the code for my Maple Rev3 clone, and see if I can update that bootloader as well

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

Re: Maple Bootloader 2.0

Postby RogerClark » Mon May 04, 2015 12:06 pm

Guys

I have been doing some more work on the Bootloader to add some code comments in how to port to different boards.
But it's not all working yet.

And I have setup 4 different build targets, maple mini, maple rev 3, maple rev 5 (same as maple rev 6 and maple Ret), and a build for my generic stm32f103c8 , just to test on a different led.

I've also written a simple HTML JavaScript utility to generate the USB DFU description strings

The GPIO in the bootloader has to be setup form first principals, but I don't think I have figured it all out yet, as I can't get the led on pc13 to flash .


I was thinking that as well as version number, the DFU messages should possibly contain which target the build is for e.g. Put (maple mini) at the end of the texts.

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

Re: Maple Bootloader 2.0

Postby RogerClark » Tue May 05, 2015 12:28 am

Victor

I'm not sure whats going wrong, but I can't seem to change it so that the bootloader has the LED on Port C instead of port B

The Maple mini config code looks like this

Code: Select all


   #define LED_BANK         GPIOB
   #define LED              1
   #define LED_BANK_CR      GPIO_CRL(LED_BANK)
   #define LED_CR_MASK      0xFFFFFF0F
   #define LED_CR_MODE      0x00000010
   #define RCC_APB2ENR_LED  0x00000008 /* enable Port B (bit 3 - see table above IOPBEN)*/

   /* On the Mini, BUT is PB8 */
   #define BUTTON_BANK      GPIOB
   #define BUTTON           8
   #define BUT_BANK_CR      GPIO_CRH(BUTTON_BANK)
   #define BUT_CR_MASK      0xFFFFFFF0
   #define BUT_CR_OUTPUT_IN 0x00000004
   #define RCC_APB2ENR_BUT  0x00000008 /* enable Port B (bit 3 - see table above IOPBEN)*/



and I changed it to this for a generic board with the LED on PC13

Code: Select all

   #define LED_BANK         GPIOC
   #define LED              13
   // Note GPIO_CRH is high register for bits 8 to 15. (GPIO_CRL would be for bits 0 to 7)
   #define LED_BANK_CR      GPIO_CRH(LED_BANK)
   // Bit mask for pin 13. Thus is the high 32 bits of the control register with 4 bits per pin
   #define LED_CR_MASK      0xFF0FFFFF
   #define LED_CR_MODE      0x00000010
   #define RCC_APB2ENR_LED  0x00000010 /* enable Port C  . Bit 4 IOPAEN: IO port C clock enable*/

   /* Assign Button to PB8 the same as on the Maple mini */
   #define BUTTON_BANK      GPIOB
   #define BUTTON           8
   #define BUT_BANK_CR      GPIO_CRH(BUTTON_BANK)
   #define BUT_CR_MASK      0xFFFFFFF0
   #define BUT_CR_OUTPUT_IN 0x00000004
   #define RCC_APB2ENR_BUT  0x00000008 /* enable Port B  . Bit 2 IOPAEN: IO port B clock enable*/



I will try just moving the LED pin by one bit ie leaving it on port B and see if that change works

I suspect its something to do with the RCC GPIO clock config


http://www.st.com/web/en/resource/techn ... 171190.pdf
page 112 and 113
seems to be where the gpio rcc clock stuff is documented

However I suspect there may be some other code not in config.h that may need to be changed , its just tracking down what it is

There is this code, which also sets up RCC, but its not commented in the code, so I'll need to reverse engineer what the bit patterns mean :-(


Code: Select all

void systemReset(void) {
    SET_REG(RCC_CR, GET_REG(RCC_CR)     | 0x00000001);
    SET_REG(RCC_CFGR, GET_REG(RCC_CFGR) & 0xF8FF0000);
    SET_REG(RCC_CR, GET_REG(RCC_CR)     & 0xFEF6FFFF);
    SET_REG(RCC_CR, GET_REG(RCC_CR)     & 0xFFFBFFFF);
    SET_REG(RCC_CFGR, GET_REG(RCC_CFGR) & 0xFF80FFFF);

    SET_REG(RCC_CIR, 0x00000000);  /* disable all RCC interrupts */
}

victor_pv
Posts: 1237
Joined: Mon Apr 27, 2015 12:12 pm

Re: Maple Bootloader 2.0

Postby victor_pv » Wed May 06, 2015 4:39 am

Roger did you check how it compares to the Maple bootloader, which apparently had the led in GPIOA:

I was having a look at the code and seems like it is just the masks that change:
https://github.com/leaflabs/maple-bootl ... hardware.c

Also this initial commit adapting the bootloader to a board called robotis may help, as the led was moved to another pin:
https://github.com/Gregwar/maple-bootlo ... bddaf2b05f

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

Re: Maple Bootloader 2.0

Postby RogerClark » Wed May 06, 2015 4:58 am

Victor

yes. I checked against the Maple RET5 / 6 and what I changed seemed to be correct

I only think one person has a Maple RET6 and he built it himself, and has not asked for the new bootloader

It looks like the Maple Rev3 may work with the Maple mini bootloader, I think it has the same pins for LED and button,
I don;t even think I need to change the Flash size in the bootloader, as the Maple REV 3 uses a F103RB which seems to be the same as the CB just in a bigger package

User avatar
tekk
Posts: 5
Joined: Mon Jun 22, 2015 8:24 pm
Location: Slovakia
Contact:

Re: Maple Bootloader 2.0

Postby tekk » Tue Jun 30, 2015 8:53 am

Hi there,
Sorry, I have a really noob question.

How do I burn the 2.0 Bootloader on my maple mini clone?

I've read somewhere that stm32flash utility in the tools could burn it, but I can't find .bin file of the 2.0 Bootloader.
Could anybody please explain me the process of burning the bootloader on BAITE maple mini clone?

Thanks a lot.

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

Re: Maple Bootloader 2.0

Postby RogerClark » Tue Jun 30, 2015 9:58 am

If you have a maple mini with a bootloader on it already, just load the sketch, I posted, (see link below) and follow the instructions

viewtopic.php?f=21&t=257&p=3229&hilit=updater#p3241

User avatar
mrburnette
Posts: 1779
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Maple Bootloader 2.0

Postby mrburnette » Tue Jun 30, 2015 12:07 pm

tekk wrote:<...>
How do I burn the 2.0 Bootloader on my maple mini clone?



AND remember that after you run the sketch, you MUST now select the 2.0 bootloader from the Arduino board menu!


Ray


Return to “Maple Bootloader”

Who is online

Users browsing this forum: No registered users and 2 guests