BETA bootloader for Generic boards . Already working.

Bootloader for boards that don't have the addition hardware found on the Maple mini, which resets the USB
User avatar
RogerClark
Posts: 5564
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: BETA bootloader for Generic boards . Already working.

Postby RogerClark » Wed May 27, 2015 11:20 pm

Andy,

There may be something, but I searched the web for a while yesterday and didn't find anything useful on the subject.

It look me quite a while just to find out the error in the manual RM0008 and its correction in the Errata

Its not a big deal, its just a line in the config, to set the flash page size.

We can reliably now get the actual size of the flash, so we can do away with the define #define FLASH_END

e.g.

#define FLASH_END ((u32)0x08020000)

I don't think we can get the size of ram in the same way we can get the flash size, but we can probe for it. i.e we have

#define RAM_END ((u32)0x20005000)

The size of ram in the F103 appears to be either 6k, 10k,20k, 48k,64k or 96k. and no one seems to be using any 6k or 10k devices, so we'd just need to probe for 96k,64k,48k points and if not, default back to 20k

it doesn't even need to be destructive. i.e save the memory location to a var, invert the bit patter, write it back, read it, and if it reads back what was written its OK, and the old value can be re-instated, and if it still reads back as the old value e,g,. 0xffffffff then no harm done as the address doesn't exist.

Its only going to take a few microseconds to execute such code and it won't take much space.

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

Re: BETA bootloader for Generic boards . Already working.

Postby RogerClark » Thu May 28, 2015 12:03 pm

Victor (and Andy)

I've done a bit more work on the bootloader, and I think that getting the flash size from the register in the processor is OK.

And I've added that code.

However, the flash page size is more of a problem.

I've checked and it seems that all devices up to 128k have a 1k page size and those with more than 128k have a 2k page size.

So I wrote code to do the switch

Code: Select all

int getFlashPageSize(void)
{
   unsigned short *flashSize = (unsigned short *) (FLASH_SIZE_REG);// Address register
   if ((*flashSize & 0xffff) > 128)
   {
      return 0x800;
   }
   else
   {
      return 0x400;
   }
}


However, when I looked at where #define FLASH_PAGE_SIZE 0x400 is used

Its in a static declaration for the ram buffer in dfu.c


Code: Select all

static volatile u8 recvBuffer[wTransferSize] __attribute__((aligned(4)));


So to move this into code, I'm going to need to use malloc to allocate the buffer in the code.

I don't have time to change the code tonight , as its already 10pm, but malloc(0x800) seems to compile OK

However my concern is the alignment that is requested in the static declaration of the array, and whether malloc would allocate a pointer on a 4 buffer boundary or not.

If it doesnt, the easiest thing is to allocate x+4 bytes and then check the pointer to see if its on a 4 byte boundary and if not just set the recvBuffer to the nearest (higher) 4 byte boundary.


Perhaps this is a question for Rick, as he seems a whiz at that sort of thing.

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

Re: BETA bootloader for Generic boards . Already working.

Postby victor_pv » Thu May 28, 2015 2:21 pm

Roger, can you just allocate 800 for the buffer size, but then use up to the size of the page? x400 bytes will not be used, but is not like the bootloader is short in RAM...

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

Re: BETA bootloader for Generic boards . Already working.

Postby RogerClark » Thu May 28, 2015 10:05 pm

Victor

I came to the same conclusion

Strangely when I set the larger page size, I have to change the linker file, as it needs more ram to be available.

I will need to look at your version based on the maple ret6 board as I think it must have a different linker file.

I can still use my kinda hacky code to determine how big an upload block is, as it seems to reliably calculate it for all the boards I have ( which is virtually every variant ;-) )

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

Re: BETA bootloader for Generic boards . Already working.

Postby victor_pv » Fri May 29, 2015 12:16 am

RogerClark wrote:Victor

I came to the same conclusion

Strangely when I set the larger page size, I have to change the linker file, as it needs more ram to be available.

I will need to look at your version based on the maple ret6 board as I think it must have a different linker file.

I can still use my kinda hacky code to determine how big an upload block is, as it seems to reliably calculate it for all the boards I have ( which is virtually every variant ;-) )

I would just use the RAM limit set in the RET boards for both the options. As we got rid of the upload to RAM option, we can actually use the whole 20KB if we want in the bootloader ;)

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

Re: BETA bootloader for Generic boards . Already working.

Postby RogerClark » Fri May 29, 2015 7:55 am

Victor,

I have made those changes to the bootloader, so that it now determines the Flash size and uses that value where it used the hard coded Flash size from the config. It also infers the flash page size (1k or 2k) and hence the DFU block size from the Flash size

i.e boards with up to 128k flash have a 1k page size and those with more than 128k seem to have a 2k flash page size.

So in terms of config.h, there are configs for Maple mini, and Maple rev3 and Maple Ret 6, but for generic there is now just one config block - as the LED pin is defined in the makefile

There are 3 make targets for generic with led on PC13, PD2 and PG15.

I have tested the PC13 on a F103C8 board and it works fine (this has a 1k page size), and I've also tested the PG15 version, on my F103ZET board, and it also works like a charm.

I have tested the Maple mini version as well, and it also works fine !

So... I have pushed the changes to https://github.com/rogerclarkmelbourne/ ... bootloader and when we are all happy, I will change over the main repo to include this repo as a sub module.

I will also post an announcement in case anyone else feels like testing the new bootloader(s)

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

Re: BETA bootloader for Generic boards . Already working.

Postby victor_pv » Fri May 29, 2015 2:54 pm

That's great! Now we can use the same upload methods for pretty much any board.
About the flash size, from all I have read I get to the same conclusion, up to 128KB is 1Kb page size, over 128 is 2KB, all the way to the 1MB devices.

I'll try to download it later today and test it in my RCT and VET boards.
I am sure it will work fine, I'll let you know if there is any problem.

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

Re: BETA bootloader for Generic boards . Already working.

Postby RogerClark » Fri May 29, 2015 10:06 pm

Hi victor

Well it seems to work with most of my boards

The only boards that it doesn't work on is the Ugly board, but I think I have a fault on that board as its never worked on USB

I have it tried it in my maple rev 3 board yet, as I need to work out which pins the led and button are on, I have a feeling its the same pins as the maple mini, but I need to double check

Actually, I'm kinda of surprised it worked first time. The flash page size was a bit more difficult to achieve than I'd realised, as the page size is the DFU block size that has to be reported over USB to the host, but the descriptor arrays that contain that data in 2 places are statically declared, so I had to put some dummy values (2k page size) into the static declarations, and then add some code to modify the specific bytes in the array that hold the high and low byte of the DFU block size.

And remarkably after I made the changes it worked ;-)
I had steeled myself for some hard core debugging, but it wasn't necessary.

Anyway, let me know how you get in.

Btw, I should really write a description of how to add more generic targets and also where to get a version of Make.exe for windows, so that anyone can make changes

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

Re: BETA bootloader for Generic boards . Already working.

Postby victor_pv » Sat May 30, 2015 3:15 pm

I just noticed there is no option to set the button for generic boards in the makefile.
Are you planning to add that later, or will just drop the button option?

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

Re: BETA bootloader for Generic boards . Already working.

Postby RogerClark » Sat May 30, 2015 9:36 pm

Victor

The button is defined in the config for the generic boards, in config.h but I agree its just fixed on the one pin, in that block of code

I guess perhaps I should change things so that there is a config block for each build target, rather than defining the led port and pin and button port and pin in the make file, as it will be a bit cumbersome for more than just the 2 or 3 defines for the led


Return to “Generic bootloader”

Who is online

Users browsing this forum: No registered users and 2 guests