I ported the current APP 2.51 to compile with GCC instead of IAR. I tried to make minimal changes in the process to the actual app - those will come next. I mainly fixed some warnings and startup code. It’s still a bit messy, but that can be changed.
It’s available on
Feel free to make forks or pull requests!
Thanks for the port. I was able to build the .hex files but I can’t get them to run on the scope. I currently have SYS_B150 and APP_B250 loaded and running on the scope. When I load the app3.hex file I get a .rdy file (in Linux) but when I try to run it I just get a BEEEEEEEEEEEEP. Do you have any clue what might be wrong? I do find downloading to be finicky, but I was able to upgrade in the past.
That’s weird. I never had problems with uploading.
Please try the following .hex file: tmb.elitedvb.net/tmp/5IpcxxptX1/app3.hex
If that works (it’s straight from an unmodified source), it’s most likely your toolchain. Did you build a proper toolchain? Maybe my toolchain build defaults to a few options that are not specified by the command line.
If you still have problems, please upload your app3.hex file somewhere and I can take a look what’s different. “Long beep” means that the code crashed.
Your app3.hex file and mine are identical, so I guess I just have to figure a more reliable way to download the file in Linux. Any suggestions?
More info:
First I turn on the dso holding down the play/pause button.
Then I mount and copy the app3.hex file to the file system.
After a minute or two the file system disappears and I mount the next file system that appears.
I see an app3.rdy file that is 366 lines long, containing 183 lines of this:
050801C0002E
:00000001FF
After I get the .rdy file I turn off the DSO and turn it back on holding down the button with the circle. Just a beep. My SYS version is 1.50.
Thanks for the port. I got it to compile and flash just fine. It works great.
I experimented with some modifications and they worked too
I wonder if there is still an alignment issue with the linker scripts:
I was attempting to strip out all the DSO code, build an application and then start putting things back. I got to a point where removing things resulted in a binary that would compile but would hang during the DFU process.
Lots of troubleshooting later,
adding back a 16-bit constant in Main.c fixes it. uc8 is not sufficient.
uc16 ThisFixesAnAlgnmentBugSomwhereInTheLinker[]= {21};
I’m not a gcc wizard so maybe this is enough information for someone else to diagnose and update the linker script.
-Dan
I tried loading the .hex file with windows and no problem. I guess the linux load procedure is the problem.
Update: found the problem. You need to specify -o sync in the mount command. I updated the wiki accordingly.
Another update: it still isn’t reliable. Doesn’t work more than it does work. I found it isn’t reliable on windows either, but is much better than linux.
Here is a modification of tmbinc’s GCC port that works on Windows.
http://www.seeedstudio.com/forum/viewtopic.php?f=22&t=2352
You only need to make some light changes to the makefile:
add “-mthumb” to the AFLAGS
add FWLib/inc App/inc App/src to the include folders
compile !STM_SRC!/stm32f10x_nvic.c
compile two asm files:
!CC! !AFLAGS! -c !STM_ASM!/cortexm3_macro_gas.s -o cortexm3_macro.o
!CC! !AFLAGS! -c bios.S -o bios.o
link all together
Gabriel
I have no problem with installing .hex files with mtools under FreeBSD. Just “mcopy file.hex u:”, no umount/umount is required.
grep u: /usr/local/etc/mtools.conf
drive u: file="/dev/da0"
“/dev/da0” is the path to block device. The same path should be used in mount command.
I am not sure about location of mtools.conf in Linux (/etc/ or /usr/local/etc/).
@bag2
Thank You 
. This is the first time I am able to upload the firmware using Ubuntu.
btw on Ubuntu, mtools.conf is located in the /etc directory. I added the following to the end of the file:
drive u: file="/dev/sdb"
drive v: file="/dev/sdc"
I also had to run the mcopy command as root.
added:
After reading the man page on mtools.conf, I change my mtools.conf to:
drive u:
file="/dev/sdb"
sync
drive u:
file="/dev/sdc"
sync
Not sure if this is your problem or not, but a careful reading of the Windows update
procedure reveals that the DSO disconnects, changes it’s file system (.hex to .rdy) and
then reconnects. That kind of behavior is un-disk-like, and a race condition with the Linux VFS.
The fix I found for myself is to
rename the hex file to ALL CAPITALS - that is, app3.hex --> APP3.HEX
and
execute the mount/cp/umount really fast, i.e.:
mount -t vfat /dev/sdb /mnt/dso; cp FILENAME.HEX /mnt/dso; umount /dev/sdb
I had been completely unsuccessful at doing a DSO upgrade before I tried this and now it works
great just about every time. Note that this is not a true “fix”, but really just a workaround
so that the VFS unmounts the DSO before any evil has time to occur. It may or may
not work every time, but it worked for me.
I tried the APP3.HEX file pointed to above, and without the rename/gofast, it failed. Doing
it, it worked (well, it’s the same GUI as before, but it’s the gnu toolchain version).
Now it’s time to hack. 
Hello,
there is quite nasty bug in linker script - load address of .data is not properly aligned, when source is modified, it gets unaligned a then hard fault is triggered (mainly because Title and Meter are wrongly initialized and used to address string to print). Also some of stm library data was not initialized properly (.data* fixes this)
this should fix this problem:
[code]— a/src/app/main.lds
+++ b/src/app/main.lds
@@ -28,27 +28,32 @@ SECTIONS
BIOS.o
}
. = ALIGN(4);
_etext = .;
_sidata = _etext;
*(.data) /* Data memory */
*(.data*) /* Data memory */
. = ALIGN(4);
_edata = .;
. = ALIGN(4);