search

leaflabs / maple-bootloader

Bootloader firmware for the Maple ARM Cortex-M3 development board from LeafLabs
http://leaflabs.com
135 stars 117 forks source link

dfu.c globals are not volatile. #1

Closed nekromant closed 7 years ago

nekromant commented 12 years ago

This screws up flash prgramming when built with -Os Fixed in my git tree: https://github.com/nekromant/maple-bootloader/commit/d7211dd9a4729f5ebc411638fc95ae3aa9af8897 P.S. My code is quite reworked, see this post: http://forums.leaflabs.com/topic.php?id=1847

rogerclarkmelbourne commented 9 years ago

@nekromant

Should I be using your repo or the Leaflabs repo.

Although yours looks better, there are more recent fixes to the LeafLabs repo.

Also, I can't see how to build for Maple mini in either repo.

I can see your repo has separate boards, for each platform, so I guess I could make a maple-mini board by copying the Maple board and changing the GPIO pin stuff

It just seems odd that neither repo has a way to build the bootloader for the mini ;-(

nekromant commented 9 years ago

Since I haven't been making any stm32 boards with usb bootloader (Actually moved to my http://github.com/nekromant/rf24boot/ (bootloader over nrf24l01 wireless) for most of my projects) I haven't been committing much to that repo, nor watching for any fixes upstream for a while. But all the things worked last time I've checked. Since I don't have any maple boards (only a few maple-like made by a friend) I didn't add any support for them (since I couldn't test it anyway). Patches welcome ;)

rogerclarkmelbourne commented 9 years ago

@nekromant

OK. Thanks.

It looks like some fixes have been applied to the Leaflabs bootloader repo since your development stopped. But the fixes seem to have mainly been applied to the Master branch and not the maple mini branch

I didnt really think that this is what branches were for, and think your system of board folders is better

Anyway, I'm probably going to see if just changing the GPIO pin stuff in the Master (Maple) code allows it to work on the mini, as I can't see why the code should be that different between the F103CB and the F103RB devices (as ram size and flash size shouldnt really affect the bootloader, except possibly for Ram uploads)

BTW. There are loads of maple mini clones from China for around $5, so a lot more interest in the Maple mini as well as many other F103 based generic boards.

nekromant commented 9 years ago

Feel free to play with my branch. I don't push any updates, but happen to still use it in production in a few places, so things should 'just work'.

rogerclarkmelbourne commented 9 years ago

@nekromant

I've decided to fork https://github.com/jonatanolofsson/maple-bootloader as it seems to track this repo and has other updates

I've been working with some other guys to free up the 3K RAM that is always allocated to the bootloader by the libmaple. However the method that the bootloader uses to determine if there is a valid RAM based program is flawed and even in normal builds seems to result in my Maple board not running code in Flash after an upload has finished. i.e the code to test for program in ram space, only tests 13 of the 32 bits of the first 4 bytes of the RAM

And as there is very limited ram on the F103CB processor, only very small sketches would ever have fitted in RAM

Hence our intention is to remove the RAM upload option completely, and get rid of any associated bugs, which as a byproduct will make the bootloader smaller.

We will also re-allocate less flash to the bootloader, as it doesnt need 0x5000, we are hoping for perhaps 0x2000 which will more flash to the sketches

rogerclarkmelbourne commented 7 years ago

This has been totally superseded by my modified copy.

https://github.com/rogerclarkmelbourne/STM32duino-bootloader

I think this issue should be closed

nekromant commented 7 years ago

@rogerclarkmelbourne You may want checkout github.com/uISP/uisp-userspace && github.com/uISP/uisp-bootloader. I'm working on a single spec & bootloader utility, and so far have avr and nrf24lu1done + a cross-platform uplaod utility. Since latest windows have a huge problem with driver signing I've used the HID spec, so the uploader tool now works happily from windows/linux/mac/freebsd and needs no drivers at all. STM32 and AVR with hardware usb are my next targets.

rogerclarkmelbourne commented 7 years ago

Cool I'll take a look

BTW. Have you seen

https://github.com/jeelabs/embello/tree/master/tools/usbserup

rogerclarkmelbourne commented 7 years ago

BTW. I'm looking for a bootloader for the STM32F4 via USB. The built-in USB DFU doesnt seem to be compatible with my Windows DFU driver and doesnt seem to work on all Linux machines either :-(

nekromant commented 7 years ago

@rogerclarkmelbourne Seen that. Here's the proper readme.md for mine: https://github.com/uISP/uisp-userspace/tree/cross-platform

And suggest we take the discussion away from this issue, so that we won't annoy maple folks anymore.

rogerclarkmelbourne commented 7 years ago

@nekromant

I have a gitter room for my bootloader https://gitter.im/stm32duino/bootloader

We could chat there