BETA bootloader for Generic boards . Already working.

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.

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 !

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”)

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?

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 )

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.

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

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.

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

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

void setupLED (void) {
/* enable LED pin */
pRCC->APB2ENR |= RCC_APB2ENR_LED;
....

The code is a bit messy at places.
When I compared it to the updated maple mini code, the RET6 code had many mistakes that had been corrected over the years in some basic stuff, so I corrected all that, but still in general my guess is that this was a work in progress that leaf labs never finished.

It looks like several pieces where glued together to make it work, with the intention of later cleaning it up to make it consistent, but never got to that point.
I am a complete beginner and still spotted strange stuff, I’m sure we are seeing loads of things that look strange.

Victor

Can you remember what other code appeared to contain redundant or bad code?

It’s possible the Maple mini branch that I took my original code from, doesnt have those issues, because it looks like all the branches got updated separately. Hence why I want to unify it for the future

Edit. BTW. I’m not sure if its worth updating, but I’ve noticed that the usb_lib that is used by the bootloader, dates back to 2008 !!!!!!

I’m pretty sure I’ve see a newer version kicking around on the web (from STM)

One of the reasons to update would be to get rid of all those annoying compile warnings. I personally don’t like warnings as they often mask potential bugs.

So if I get chance I may replace the lib_usb with an up to date one.

Victor

Just a quick update.

I’ve done a bit more tidying and have cut down the amount of config that is required, so that you only have to set the port and the pin for the LED and the button

But….

For some reason, I can’t use all pins on the Maple mini as the LED.

I don’t seem to be able to use PA15 or PA14 or PA13, however I can use PC13
Initially I thought I must have stuffed up the masking and bit shifting of the control register setup, or the gpio_write_bit etc

But, as now after various bits of tinkering, I can use PC13 as the LED, I don’t think there can be anything wrong with my code

So, looking at the manual for the chip (that huge PDF), it looks like the reason that I can’t use PA14 or PA15 is because the spec has the “Main function” of these pins as JTAG pins.

So I think we need to do some AFRemap stuff in order to make these pins available

I guess it depends if we want to debug the bootloader via STLink or BMP etc, I guess we may want to do that.

But perhaps this could be a #define for ENABLE_SWD and normally have it turned off.

Otherwise people will end up doing what I’ve been doing, which is spend loads of time thinking they’ve wired stuff up incorrectly

Edit. I just tried disabling the SWD and JTAG but have not really had any success

Perhaps I’ve missed something. I thought that I just need to change the

AF remap and debug I/O configuration register (AFIO_MAPR)
Address offset: 0x04

Bits 26:24 SWJ_CFG[2:0]: Serial wire JTAG configuration
These bits are write-only (when read, the value is undefined). They are used to configure the
SWJ and trace alternate function I/Os. The SWJ (Serial Wire JTAG) supports JTAG or SWD
access to the Cortex® debug port. The default state after reset is SWJ ON without trace.
This allows JTAG or SW mode to be enabled by sending a specific sequence on the JTMS /
JTCK pin.
000: Full SWJ (JTAG-DP + SW-DP): Reset State
001: Full SWJ (JTAG-DP + SW-DP) but without NJTRST
010: JTAG-DP Disabled and SW-DP Enabled
100: JTAG-DP Disabled and SW-DP Disabled

But unfortunatly this has not enabled PA13 etc, so perhaps I need to do something else, as well as this. But looking at what the maple mini does in the code to disable or enable the SWD its basically the same code

Interesting, it never occurred to me that some ports would be set to default for JTAG.

I think there are two options then, remap the pins, or just write a warning with your finding in the code section that manages the PIN, indicating X Y and Z pins can not be used for leds because they are used for JTAG.

If you think we really need to be able to use all pins, I can check the datasheet later to see if I find any missing step.

As part of testing the USB port yesterday, I changed modes in the PA12 before and after the pull down, to see if there would be other results.
I set to output OD after the pull, set it to input pullup, and also tested on setting it to output OD rather that PUPD before the pull down.
It worked all the time, but I did notice more consistent reenumeration if I set the pin to Output OpenDrain rather than PullUp/PullDown before pulling it low.
May be just perception because I was messing so much with it trying to make sure it didn’t break… resets, power down, reset again and again…
But at the moment I will keep it with Output OpenDrain rather than PU/PD for a while and see how it goes.

Thanks victor

I think the thing we need to do is test on multiple hosts, e.g not just windows, so will see if I can test on OSX

Btw. I have been continuing to tidy up the bootloader code, so that the config.h is a lot less complex.

Once I have tested on a few more boards I will push the code

Victor,

I can’t find any reference online where the DBGMCU_IDCODE can be read by by the processor its self.

I found this on a russian website (google translate http://translate.google.com.au/translat … rev=search )

Where they stated it could not be read in normal mode, even though the manual says it can.

But as we know the manual is not always right, hence the Application Notes and Erratica, but I really cant find anything useful about this.

Anyway, at the moment it looks like we still need to set the flash page size in the config for the bootloader :0(

Edit.

I found out its not possible to read this value

See

http://www.st.com/st-web-ui/static/acti … 190234.pdf

2.3 Debug registers cannot be read by user software

Great

We may still be able to infer page size based on total flash size, but I’m not that hopeful

Is there anything non unique about the “unique identifier” or some other register(s) possibly in the memory controller (FSMC) that would allow you to identify or infer page size?

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.

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

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

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…

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 )

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 )

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)

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.

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

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?

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

Victor

I’ve removed the inline -D defines in the Makefile for the generic boards, and have created separate sections in config.h for them.

If buttons are important, we could add new targets e.g.

make gerneric-pc13-pc14

e.g. led on pc13 button on pc14, but its very dependent on what people have on their board, and none of my generic boards have a “button” on them (apart from the reset button), so unless the pin is already used, people may as well use PC14 , for their button, as its the pin defined in the code.

I’ve not had chance to fully document how to modify the bootloader, but I’ll try to do that it, one evening in the week.

Victor

I think I may change the name of the “Maple DFU” upload option on the generic boards

I know the name makes sense to us, but to anyone coming to this afresh, it probably doesn’t instantly become apparent that its the option for the Generic Bootloader

Perhaps we can call it “Bootloader upload” ? though that sounds a bit like we are uploading the bootloader

perhaps Generic Bootloader

But again I know we call it the generic bootloader, but its kinda an internal name.

Any ideas ? (Perhaps I better post this to general discussion)

Roger,

My sarcastic side really wants to suggest the Oak Uploader, or perhaps Pine or Hickory(can you tell our street names here are all trees?).

Now, to be serious: why not just BareSTM32 Uploader of GenSTM32 Uploader. With Gen, it could be taken as Generic or General. It does kind of seem like development is falling into the Maple board variants and General Board variants. For beginners, General is a nice soft term and a good foundation where specific variants can be offered.

Just a thought for y’all (my feelings won’t be hurt if it’s a bad idea… I’m full of bad ideas).

RogerClark wrote:Victor

I think I may change the name of the “Maple DFU” upload option on the generic boards

I know the name makes sense to us, but to anyone coming to this afresh, it probably doesn’t instantly become apparent that its the option for the Generic Bootloader

Perhaps we can call it “Bootloader upload” ? though that sounds a bit like we are uploading the bootloader

perhaps Generic Bootloader

But again I know we call it the generic bootloader, but its kinda an internal name.

Any ideas ? (Perhaps I better post this to general discussion)

Stm32duino bootloader did cross my mind

I may post this to general discussion, so it gets a wider airing.

Thanks

Roger

My sarcastic side really wants to suggest the Oak Uploader, or perhaps Pine or Hickory
My sarcastic side would take the name “weeping willow” because leaflabs abandoned the whole maple project and my optimistic side would take the name “weed”, because weed does not pass

(lol)

… of course, “GenXup” is still avsilable

R