Maple Bootloader 2.0

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

Maple Bootloader 2.0

Postby RogerClark » Mon Apr 27, 2015 11:16 am

The an bootloader is being developed to replace the existing Maple bootloader.

The improvements in the "bootloader 2.0" are

  • All RAM in the processor is available to the Sketch for uploads to Flash. In the old bootloader, 3k is always allocated to the bootloader even though the bootloader does not run after the sketch starts, so 3k does not need to be reserved
  • "Bootloader 2.0" is 12k smaller than the old bootloader, so that there is 12k more for the sketch
  • Uploads on OSX and Linux should be much faster

Current Status

The bootloader works for Maple mini, when used with the latest version of Arduino STM32 from GitHub.
You also need to select "Bootloader 2.0" from the "Bootloader version" menu within the Maple mini board selection.

There is however one bug that needs to be resolve. Uploads to RAM do not currently work.
This is because the old upload to RAM could fail intermittently to run. This is because the bootloader attempts to detect if the RAM contains a sketch or just variables, and the "magic number" used for this purpose is weak.

I am developing a new system which uses a 64 or possibly a 128 bit magic number, rather than the effective 13 bit magic number that the old bootloader used.

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

Re: Bootloader 2.0

Postby victor_pv » Mon Apr 27, 2015 3:13 pm

Roger, I suggest to just change the mask used to filter the SP address in checkUserCode in hardware.c

if ((sp & 0xFFFE0FFF) == 0x20000000) {

That only leaves 5 bits out, that cover the range from 4KB to 64KB. There could still be false positives, but much less likely that the current one.

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

Re: Bootloader 2.0

Postby victor_pv » Mon Apr 27, 2015 3:29 pm

Actually, what about this?

Seems to compile fine for me. I'm not at home so didn't have a chance to test it.

#if defined(TARGET_MAPLE_MINI)
if (sp == 0x20005000) {
#elif defined(TARGET_MAPLE_REV3)
if ((sp & 0x2FFE0FFF) == 0x20000000) {
#endif

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

Re: Bootloader 2.0

Postby RogerClark » Wed Apr 29, 2015 1:18 am

Victor

The problem is not the two different versions of board.

The problem is the upload to RAM

When the bootloader resets its self after an upload to RAM, it has to look for a flag in the RAM that indicates that a sketch is in the RAM

Previously it looked at 0x20000c0 for that pattern (as shown in your code) but when we allocate all RAM to the sketch, the sketch variables will be put into the RAM location that the bootloader checks

And the issue is that we've no control of what the sketch will put at offset 0xc00 from the base of RAM

At the moment, the sketch seems to consistently put a value (from its vars) into that location, which the bootloader reads as a valid SP vector

Hence to free up all RAM for the sketch we had to build a new version of the bootloader that doesnt do the RAM check.

But for backwards compatibility, I was hoping to keep the RAM upload, even though its almost impossible to use, even on the old Maple IDE, because the blink sketch in the old IDE only just fits in RAM on a Maple mini

I thought that after an upload to ram, that the bootloader could just switch to executing from RAM, but it doesn't seem to do that. It seems to reset its self (not sure why), and then restarts main() from the beginning.
So unless I can get it to run without resetting, we'd need to store a much more reliable flag in the code to indicate the last upload was to RAM

The guaranteed way to do this is to not allow the sketch to use the lower 4 or 8 bytes of ram, and get the bootloader to set some magic number in there that we know the sketch will not overwrite, as it wouldnt use those bytes.

But I don't like the thought of not having all ram available for the sketch

I think people would perhaps prefer if we just get rid of upload to ram. Well I can leave it in the code, but perhaps return an error, e.f. upload to ram no supported

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

Re: Maple Bootloader 2.0

Postby victor_pv » Wed Apr 29, 2015 12:07 pm

Roger, I understand the sketch may load whatever it wish in ...C00, but given that the address 0x20005000 is actually out of the range of RAM for that MCU, and as far as I know is only used for the SP, what are the chances that a sketch will use that 32 bit value somewhere, and then the chances that will store that exactly at C00?

The original code mask all the bottom bits, which I think causes the issue, because any RAM address will fit a pattern when you are masking out all the bottom bits of the addresses, and even some top ones... so if the sketch loaded the value of any valid RAM address in that position, the check would be positive.

But by checking to 1 single 32bit number, which on top is an address out of range, I don't think we should get false positives.
I compiled a bootloader to test it, but that was right when my mini died and never got a chance to test it. Now I think I repaired the short in the board (burnt 1117), and my bootloader works, but I suspect higher flash addresses get corrupt because I detect the Serial port but with the wrong hardware id (0E0F rather than 1EAF) so the drivers wont load for it. I will try testing all my flash later with ST-Link with different bit patterns to see if any address fails, and if so make a bootloader for that board that loads the sketches higher than that... that will keep me busy until another maple mini arrives ;)

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

Re: Maple Bootloader 2.0

Postby RogerClark » Wed Apr 29, 2015 12:22 pm

Victor,

Using the top of the RAM seems worth trying.

Perhaps a 64bit one e.g unsigned long 0x1EAF1AB5

I.e in homage to LeafLabs ;-)

Ps see my postings about stlink now working much better

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

Re: Maple Bootloader 2.0

Postby victor_pv » Wed Apr 29, 2015 12:50 pm

Roger,

I believe checking for exactly 2005000 should be very reliable, but if not, what about this?
-Uploads to RAM set the top of the RAM 4 bytes shorter than the actual RAM, and the SP address 1 byte lower.
We store 1 particular value at those bytes, and check for them.

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

Re: Maple Bootloader 2.0

Postby RogerClark » Wed Apr 29, 2015 10:02 pm

Victor,

I will test and get back to you. I think there may be a simpler solution ;-)

bobc
Posts: 20
Joined: Mon Apr 27, 2015 11:20 pm

Re: Maple Bootloader 2.0

Postby bobc » Thu Apr 30, 2015 10:10 pm

Personally, I would drop the upload to RAM option. In introduces an unnecessary complexity, and I just can't see the need. Certainly the "quick and simple" method LeafLabs chose is unreliable.

I think this is one of the mis-steps Leaflabs made. My experience with bootloaders is that robustness is far more important than features.

Btw, I use emblocks to build the bootloader, and STLINK JTAG to debug, which proved really useful in tracking down the problems caused by the upload to RAM option.

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

Re: Maple Bootloader 2.0

Postby RogerClark » Thu Apr 30, 2015 10:40 pm

Bob

I was hoping for 100% backwards compatibility, but I agree, the whole upload to ram thing is fairly pointless

As a test I ran the original Maple IDE, and uploaded their Blink sketch to RAM, and it ran OK, but Blink takes around 90% of available RAM

So in the real world upload to ram is basically useless for any sketch that actually does any work.

I agree it was a gimic.

I'll see if I can get the bootloader to return an error message if an upload is requested to RAM. I know it can return error codes, but I'm not sure the mechanism to attach a message, as the code doesnt ever seem to return error messages


PS. Thanks for the tip about using em:blocks to build, so I can debug via stlink

Exellent idea.

I also have CooCox, so I could probably use that as well


Return to “Maple Bootloader”

Who is online

Users browsing this forum: No registered users and 1 guest