BETA bootloader for Generic boards . Already working.

STM32duino bootloader aka Maple bootloader
victor_pv
Posts: 1739
Joined: Mon Apr 27, 2015 12:12 pm

BETA bootloader for Generic boards . Already working.

Post by victor_pv » Fri May 15, 2015 3:12 pm

All,

I took the old RET6 bootloader code and brought it up on par with the bootloader 2.0 for the mini, including most of Roger's changes to it.
The code is here:
https://github.com/victorpv/maple-bootl ... ensity-2.0

There are 3 precompiled binaries:
maple_RET6_boot_old.bin - Original RET bootloader. did not completely work for me on a generic board.

maple_boot_HD_PD2_20.bin - Worked fine in RCT board with no button. This one will not check for any button. It blinks a led in PD2, if the led is in a different port the bootloader will still work but just not blink. Can upload with ID1 and ID2 and their respective addresses.

maple_boot_HD_PE5_20.bin - This expects a button in PC0, and a led in PE5. If you dont have a button on PC0 you may need to pull the pin to GND. you can let it pulled all the time. This one gets the Upload to RAM option again, in ID0, and the old same address of 20000C00, make sure you use the right compiler script

I have tested re-enumeration seems to work really good in Windows 8.1, but have not tested other OS, so I would appreciate if someone tested linux, OSX or any other flavor, and let me know if there is anyproblem.

We are trying to sort out re-enumeration in the generic boards. If that works fine, there should be no problem having a bootloader in any board we want with a USB port with the 1K5 resistor.

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

Re: BETA bootloader for Generic boards . Already working.

Post by RogerClark » Sat May 16, 2015 6:23 am

Hi Victor,

I will try flashing it onto my VET board (I presume it will work on that one) Or I could try by ZET board.

I have OSX and linux, but my linux setup is flakey at the best of times, so its probably best if someone else tests it on Linux

If it works on the PC (WIndows 7 Prof), I will try it on OSX

One thing, I think you should have mentioned is that this only works for the STM32F103V series board setting, with Maple DFU as the upload type

This is because on the VET board variant has Maple DFU as an option and also only the VET board variant has the reset code that uses PA12

I will however shortly add those options to the other boards, but your bootloader code will only work for devices with 2k flash page size i.e F103RC or better I think

We will need to do a bootloader that works for the boards that have 1K flash page size

i.e probably best to do a bootloader for for the C8 boards

Also. Regarding the "button". The only reason for the button was to enter perpetual bootloader, in case something in the sketch has got screwed up.
However there is no real need for this.

Simply hold the reset button down, and release it as soon as the compile has finished and DFU Util is looking for the DFU device.

DFU Util seems to have a 5 second timeout, so there is plenty of time to release the reset button and for the USB bus to re-enumerate

I've tried this a number of times with no problems whatsoever !

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

OSX

Post by RogerClark » Sat May 16, 2015 8:48 am

Victor,

It looks like the osx maple upload for the mini maple is not working for me, so I cant fully test your bootloader

I need to fix OSX so that works for the baords which have the Maple hardware.
I'm not sure how Tim thought it was working.

Anyway, I downloaded the old Maple IDE, and managed to do a successful upload to the Maple mini, and then did an upload to my ZET board running your bootloader

But as the sketch then has the old code in it,i.e doesnt have the code to use PC12 , so I could only test it once.


Anyway, basically i think your bootloader will/does work on the Mac (OSX), but not until I fix the existing bugs in the reset sequence on OSX.

At the moment I don't think the OSX is resetting the board correctly, it just seems to reset the USB serial device, but i thought that the reset sequence is to set DTR and then send a sequence of characters e.g LEAFLABS

So i suspect what I need to do is write a small program using the terminal library to do the reset sequence correctly

I think the same problem applies on Linux, because it uses the same (not working reset command using "stty")

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

Re: BETA bootloader for Generic boards . Already working.

Post by victor_pv » Sat May 16, 2015 1:38 pm

Roger, quick update. The issue with the button possibly missing is resolved the way we talked on messages, setting the port as pull-down, so we can leave it there like.
I believe the bootloader should work for every device just changing the page size to the right value. The same works for my RCT, my VET, and your ZET, and from the things that are different in the code respect to your version, I don't think anything would break it for the C8 and CB, it should just work right away.

I'll try compare mine with your other branch to see what changes, and add the conditional compiling for these options:
Maple mini (1k size, disc pin in the right place).
Maple (1k size, disc pin in the right place, if the same as maple mini, I will only set one for both).
Maple RET (2k size, and discovery pin).
Generic up to 128KB (1k page size).
Generic over 128KB (2k page size).

I think with the options above we cover every possibility, or did I miss anything?

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

Re: BETA bootloader for Generic boards . Already working.

Post by RogerClark » Sat May 16, 2015 8:59 pm

Victor

I think you have covered all the bases.

Like you said...

In the simplest form there only needs to be 4 variants.

2 permutations for flash page size and
2 permutations for disconnection hardware method.

Button is optional, and I agree we should use internal pull down, as only in rare occurrences is this likely to cause a problem

Led pin is a bit more tricky, as each board has it in a different place.
The problem is that it won't be practical to have a bootloader for every possible led location.
E.g. On my ZET board I think its in pin PG15! I.e pin 112, but we can't build around 100 different bootloaders for Z series boards. ;-)

One thought I had is to do online compiling of the bootloader, ie have a web page where you select the processor from a menu, then select led pin and button pin (optional)

But I'm not sure it's worth the bother or whether my web hosting company allow it.

I can SSH into my shared web server and I could copy the Linux arm compiler binaries to the sever, and just write a script that runs the compiler on the necessary files.
It would be an interesting technical exercise, but I suspect my time would be better spent on other things.

In the mean time, I would like to tidy up the bootloader build process and make file etc and make sure it works on C8 boards

But the other thing I need to sort out are the issues on the Mac (which may also apply to Linux )

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

Re: BETA bootloader for Generic boards . Already working.

Post by victor_pv » Sat May 16, 2015 9:18 pm

Roger,

Personally I think the 4 permutations of disconnect method and page size is all we should care about.
About the led, anyone can go an modify the config file and recompile it. Even if the led is not working, DFU works.
Same for the push button, as you said before, you can always press reset again.

I would only host 4 compiled bins (maple mini, maple RET, generic 1k page, and generic 2k page).
Looks like at the end of the day, most people get the same type of boards, I have already seen posts showing both of the generic ones I have, and the mini c8t6 boards seem to be everywhere with a similar configuration.

I think you should save your time for something else more important, as chaging the config file and recompiling for the few boards that seem to be the most common would take much less time.

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

Re: BETA bootloader for Generic boards . Already working.

Post by RogerClark » Sun May 17, 2015 12:49 am

Victor,

I may have time time later to carry on with this and try to get the makefile working for those variants.


I will also set the button to pull down, rather than just #ifdef'ing out the code

Cheers

Roger

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

Re: BETA bootloader for Generic boards . Already working.

Post by victor_pv » Sun May 17, 2015 4:10 am

Roger, in the latest updates in my repo the button port is set to input pull down, if you want to take the defines from there, and works fine with my RCT board that doesn't have a button.

I have been trying to finish with the DMA SPI, the ILI9163 driver, and making a better example for FreeRTOS. I need to resync with your repo and will send you a pull request for those things as they seem to all work well.

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

Re: BETA bootloader for Generic boards . Already working.

Post by RogerClark » Sun May 17, 2015 6:04 am

Hi Victor,

I've had a go at pulling your code into my new repo, but I think I must have made a mistake somewhere because although my F103ZET board enumerates, it says as the DFU device, so I've almost certainly stuffed up the button code

tried to conditionally compile the button code, but I think you are right and that its best just to pull the button pin low

I will grab your code for that and try again

Thanks

Roger

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

Re: BETA bootloader for Generic boards . Already working.

Post by RogerClark » Thu May 21, 2015 11:04 am

Victor

I've not had much time to work out why merging the code has not worked

But one thing that has struck me, is why they bother to individually enable the GPIO clocks

e.g. in

Code: Select all

void setupLED (void) {
  /* enable LED pin */
  pRCC->APB2ENR |= RCC_APB2ENR_LED;
....
I think I may as well just change it so that GPIO clocks are enabled or all ports A to G, (that is unless enabling a port that doesnt exist is a bad thing !)

I think I'll give it a try as its one less thing to have to mess around with different configurations for (and mystery bit patters )

Thanks

Roger

Edit.

I've done some tests with the Maple bootloader and it doesnt seem to do any harm enabling all the GPIO RCC clocks (i.e enabling all the GPIO ports A to G regardless if the device has those ports of not)

Also, I've rewritten / simplified the button and LED setup into one much smaller function and have also reduced the amount of config that is needed to specify the LED and the Button

All this is now needed is the BANK (i,e GPIO port base address) and the pin number

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)*/
	
	#define BUTTON_BANK GPIOC
	#define BUTTON 9
//	#define BUT_BANK_CR GPIO_CRH(BUTTON_BANK)
//	#define BUT_CR_MASK 0xFFFFFF0F
//	#define BUT_CR_INPUT_PU_PD 0x00000080 // Input PU/PD
//	#define RCC_APB2ENR_BUT 0x00000010 // enable PC	
I've done this my writing 1 new macro and adding one new function
This macro does the work to determine if its the HIGH or LOW control register for the pin (bit) in question

Code: Select all

#define GPIO_CR(port,pin) (port + (0x04*(pin>7)))
and this function generates the Control Register mask

Code: Select all

unsigned int crMask(int pin)
{
	unsigned int mask;
	if (pin>=8)
	{
		pin-=8;
	}
	mask = 0x0F << (pin<<2);
	return ~mask;
}	
There may be a way to macro'ize the CR mask, but its probably not worth it, because the code is needed several times, so any macro would end up injecting the same code in several times.
I can probably drop the local var "mask" as well,

For the Maple USB there doesnt seem to be a need to setup the USB RCC in the USB setup. I've moved it to the setupCLK() where the other RCC stuff is setup, but the generic board USB stuff may need the USB clock to be turned on after the GPIO has been toggled, but I suspect its not needed to be done there either.


There also seems to be some other redundant code, e.g. the LED is initially turned on, but I don't see why this is needed, as its turned on as soon as the flashing code is called, so I've taken that line out as well, and my Maple mini bootloader is still working fine

One thing I've still not managed to do however is to get the LED working on another pin for the Maple mini, I'm not too sure whats going on, I suspect there is some other setup going on elsewhere, i,e we keep finding code that should be on one place, being liberally distributed all over the place.

But hopefully with my latest changes, I will soon be in a better position to get your code working

PS. I've not pushed these changes, as I need to do some more testing as I'm not sure its stable

Cheers

Roger

Post Reply