Can I get an immediate sketch start?

joevpt
Posts: 12
Joined: Sat Aug 27, 2016 6:38 pm

Can I get an immediate sketch start?

Postby joevpt » Wed Dec 14, 2016 12:42 pm

I have a sketch which uses : Serial (for debug messages), Serial1 (for comms), and SPI (to communicate with a display peripheral).

At startup, the external peripheral which powers up at the same time as the Maple Mini waits in an uncertain state (random leds flashing) until the Maple Mini starts running the sketch to initialize it.

The sketch is delayed by the strobing of the original Maple Mini bootloader.

Obviously having the bootloader there is a good thing - in case I need to upgrade the firmware.

My question is whether there is a way to bypass the bootload in normal operation and, using the button press method, enter the DFU mode to load the bootloader when needed.

Joe

stevestrong
Posts: 884
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Can I get an immediate sketch start?

Postby stevestrong » Wed Dec 14, 2016 1:08 pm

Or you can use the STLink adapter to upload new firmware, in this case there is no bootloader in game, the software starts immediately.

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

Re: Can I get an immediate sketch start?

Postby mrburnette » Wed Dec 14, 2016 3:17 pm

If you can do without A9/A10 (physical 30/31) then you can just use an external USB-serial and a Blue Pill and save 1/2 the cost of the Maple Mini.
http://stm32duino.com/viewtopic.php?f=45&t=1441

http://wiki.stm32duino.com/index.php?title=Blue_Pill

Just like with a STLink, using the internal serial firmware overwrites the bootloader.

Ray

joevpt
Posts: 12
Joined: Sat Aug 27, 2016 6:38 pm

Re: Can I get an immediate sketch start?

Postby joevpt » Tue Dec 20, 2016 1:38 pm

So the answer to my question appears to be yes I can get an immediate sketch start, but I must loose the bootloader. Here is what I found:

1. I have two types of Maple Mini. One has the suggested white stamp to indicate that it is from Baites. The other has no marking. When putting the boards together, I found that the drill holes for the pins are two large on the non-marked board, but other than to have to pour additional solder into them, this did cause too much of a problem. The other difference had me scratch my head for about half an hour. The non-Baites board has the Read Out Protection option set (in option bytes), which causes the bootloader upload sketch to fail. Resetting it with an ST Link solved that issue.

2. I modified the bootloader v2.0 to reset the SPI2 pins before it did anything else. Unfortunately this did not help with the noise I was seeing on the display. I therefore abandoned this approach.

3. I then did a chip erase (using the ST Link) and uploaded the sketch directing the programmer to place it at 0x8000000 instead of the usual 0x8005000.
This did not work for me, so I wondered whether the boards.txt file needed to be modified to reflect the fact that there was no longer a bootloader present. The only address specific setting I could find was:
mapleMini.menu.bootloader_version.original.build.vect=VECT_TAB_ADDR=0x8005000
Given that nothing was now in 0x8000000, I reasoned that this should be 0x8000000. Again, I compiled the sketch and uploaded it using the ST Link using the base address of 0x8000000. I really expected that to work, through I hadn't changed anything to tell the compiler that I wanted my program to be located at 0x8000000 (because the Arduino IDE hides all that ugly stuff).

4. Obviously it did not work. I then reasoned that my sketch needed to be located at 0x8005000 even though the VECT_TAB_ADDR needed to be 0x8000000. To do this I just erased the chip again, uploaded the sketch at 0x8005000 and then reasoned (I use reason here to disguise the fact that I am plucking this stuff out of the blue), that the vector table (whatever that is) was located at the beginning of my sketch and could be copied back into flash at around 0x8000000, so I copied 80 or so bytes from 0x8005000 back to 0x8000000 and it worked !

I now have a sketch which starts immediately, first thing it does is to initialize my external display over the SPI2 bus. No noise.

Can anyone enlighten me as to how I should have done this properly.... I'm guessing that I need to tell the compiler/linker that my address start is 0x8000000 (I would have used ORG in the old assemler days)...

Sorry for the ramble, but the miander might help another poor soul get something to work..

danieleff
Posts: 133
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: Can I get an immediate sketch start?

Postby danieleff » Tue Dec 20, 2016 1:58 pm

Select the correct upload method (in your case STLink) in Arduino IDE, in the Tools / Upload method menu.

User avatar
martinayotte
Posts: 1162
Joined: Mon Apr 27, 2015 1:45 pm

Re: Can I get an immediate sketch start?

Postby martinayotte » Tue Dec 20, 2016 6:15 pm

The LD scripts need to be tweaked accordingly if you wish to boot at 0x8000000.

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

Re: Can I get an immediate sketch start?

Postby RogerClark » Tue Dec 20, 2016 9:14 pm

You could modify the bootloader to do this.

There is already code which holds the bootloader in DFU mode if one of the battery backed RAM registers has a magic number in it, and this feature could be expanded so that the bootloader does not enter DFU mode at all unless that register had the magic number.

But, At the moment the Core does not contain the code to set the battery backed RAM register.

Currently I do not have time to implement and test any enhancements to anything, due to workload between now and Chinese New Year

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

Re: Can I get an immediate sketch start?

Postby victor_pv » Thu Jan 12, 2017 4:33 am

joevpt wrote:2. I modified the bootloader v2.0 to reset the SPI2 pins before it did anything else. Unfortunately this did not help with the noise I was seeing on the display. I therefore abandoned this approach.

3. I then did a chip erase (using the ST Link) and uploaded the sketch directing the programmer to place it at 0x8000000 instead of the usual 0x8005000.
This did not work for me, so I wondered whether the boards.txt file needed to be modified to reflect the fact that there was no longer a bootloader present. The only address specific setting I could find was:
mapleMini.menu.bootloader_version.original.build.vect=VECT_TAB_ADDR=0x8005000
Given that nothing was now in 0x8000000, I reasoned that this should be 0x8000000. Again, I compiled the sketch and uploaded it using the ST Link using the base address of 0x8000000. I really expected that to work, through I hadn't changed anything to tell the compiler that I wanted my program to be located at 0x8000000 (because the Arduino IDE hides all that ugly stuff).


Just to add some details to the excellent replies you got already.

2. You could modify the bootloader to first read a pin (switch connected pin would be ideal, but you can use any other an a jumper cable) and depending whether the pin input is high or low, either run thru DFU, or jump straight to user code.

3. When you erase the bootloader, and want to load your code at the start of flash, many addresses have to be recalculated, since the NVIC table and all the functions are shifted. If you dont use bootloader, just select the upload method as STLink. That will tell the linker to place everything starting in 0x8000000, and everything should work, you should not need to modify any file manually.

But as Roger said, the easiest if you want to keep the bootloader would be to just modify it so it does what you want, either with a pin, or a RAM value, or any other way you choose. Should not be difficult, the code is commented pretty well.


Return to “Maple mini”

Who is online

Users browsing this forum: No registered users and 1 guest