Building firmware with gcc

Hello Tormod,
happy to see you immediately hacking on BenF code :wink:

git clone git://gitorious.org/dsonano/dso-firmware.git dso-firmware
cd dso-firmware

These commands are ok.

git checkout gcc

The step breaks with:

$ git checkout gcc
error: pathspec 'gcc' did not match any file(s) known to git.

I really don’t know what’s wrong… help appreciated.

My Perl is a bit rusty, but I’d get the needed address with

perl -0777 -ne'printf "0x%08x\n", unpack('V',substr($_,4,4));' dso-app.bin

With the aid of a Makefile we could then apply the address to the LIB automagically.

Antonio

Ah, I guess:

git fetch origin gcc

is needed once to add the gcc branch locally. The git version I am using (1.7.0.4) does this automatically for you.

No, we should really fix the code in the LIB main() to do it itself instead :slight_smile:

The ARM toolchain I am using is the CodeSourcery G++ Lite (for ARM EABI). There was a new version out yesterday, 2010.09-51:
http://www.codesourcery.com/sgpp/lite/arm/portal/release1592

It took me some time, but git on Debian Lenny seems old (1.5.6.5); to me, the command needed is

git checkout -b gcc origin/gcc

Just for reference, in case someone else develops on Debian stable like me.

Antonio

I’ve compiled successfully both the APP and the LIB with arm-none-eabi-gcc (Sourcery G++ Lite 2010q1-188) 4.4.1.

In order to get a DFU file to download on the Nano, I have used:

./dfu.py -b 0x08004000:dso-lib.bin -b 0x0800c000:dso-app.bin dso_gcc.df

The file can be flashed, but still just blanks the screen :wink:

Is there anything I can do to help you in getting the gcc port further?

Antonio

Yes, I only get the white screen as well. It seems it goes bad already when starting the lib, since nothing is displayed. There can be just a small thing that I have overlooked for instance in the necessary startup code.

For the next steps, I would study the gcc-compiled code and compare it with the code from IAR. Running objdump -d on the elf file makes it pretty easy to go through the assembly code. I am just waiting for anyone to give me an IAR elf file :slight_smile:

I also have a development board with the same microcontroller, which I can debug with JTAG and openocd. If I find some time in the weekend, I can try loading the code on it and single-step through the starting code. :nerd:

[quote=“tormod”

git clone git://gitorious.org/dsonano/dso-firmware.git dso-firmware
cd dso-firmware
git fetch origin gcc # only needed on older git versions
git checkout gcc
cd DS0201_APP/project/gcc
make[/code]
[/quote]
The checkout works for me, git --version == 1.7.3.2 but the make fails because no c files came.?

[code]richard-hydes-macbook-air:dso-gcc rich$ rm -fr dso-firmware
richard-hydes-macbook-air:dso-gcc rich$ git --version
git version 1.7.3.2
richard-hydes-macbook-air:dso-gcc rich$ git clone git://gitorious.org/dsonano/dso-firmware.git dso-firmware
Cloning into dso-firmware...
remote: Counting objects: 237, done.
remote: Compressing objects: 100% (183/183), done.
remote: Total 237 (delta 90), reused 155 (delta 50)
Receiving objects: 100% (237/237), 518.02 KiB | 138 KiB/s, done.
Resolving deltas: 100% (90/90), done.
richard-hydes-macbook-air:dso-gcc rich$ cd dso-firmware
richard-hydes-macbook-air:dso-firmware rich$ git checkout gcc
Branch gcc set up to track remote branch gcc from origin.
Switched to a new branch 'gcc'
richard-hydes-macbook-air:dso-firmware rich$ cd DS0201_APP/project/gcc
richard-hydes-macbook-air:gcc rich$ make
arm-none-eabi-gcc -I ../../../DS0201_APP/include -I ../../../library/inc -c -fno-common -Os -g -mcpu=cortex-m3 -mthumb -Wp,-DGCC   -c -o ../../../DS0201_APP/source/Calculate.o ../../../DS0201_APP/source/Calculate.c
make: arm-none-eabi-gcc: No such file or directory
make: *** [../../../DS0201_APP/source/Calculate.o] Error 1
richard-hydes-macbook-air:gcc rich$ ls
Makefile			startup_stm32f10x_md.s
cortexm3_macro.s		stm32f10x_flash_offset.ld
iar2gas
richard-hydes-macbook-air:gcc rich$ 

Oh master of all things git, please tell me what I am missing?
I am still using the slightly older code sorcery port that is in macports, but that will not affect the checkout.

You simply missed the “first of all” step :slight_smile: You must have the toolchain in your path, so that the commands like “arm-none-eabi-gcc” can be found. Either your toolchain has a setup script to set paths etc, or you do this in the terminal before running make:
PATH=/real/path/here/arm-2010.09/bin:$PATH

You are of course correct. I had just realized that and apologize for my stupidity.

I am tracking down the startup problem step by step, literally, using openocd and gdb (and qemu as well, yum). There is an uninitialized function pointer being called in USB_Init. Something should have set up Device_Info and Device_Property. If anyone wants to chase it down while I am going skiing…

With a rational path in place I can now almost compile. Unfortunately Mac Os puts sed in /usr/bin not in /bin so the iar2gas blows out. :cry: I get tired of these random differences, but I thought I would mention it. The configure scripts normally fix this sort of thing.

Have fun skiing I will poke at the init function, but the whole startup world on these embedded micros is pretty opaque to me.

Well the init function is trying to walk a list of device descriptors, from first glance, and I am guessing that the function that populates that list has not been called. Without your trace capabilities I am not going to get much further here. I need to get the rest of my tools working, but I suspect you will get back from skiing before I get that far along.

Last night I fixed the sed path and the data initialization issue (I was simply not copying the initialized data section to the .bin and .hex file, duh). I can verify many things using openocd and gdb on the development board, but when it comes to timers and interrupts it gets difficult. The same goes for anything that depends on input on the GPIO ports which of course are hooked up to different hardware on the real DSO.

So to get any further I think it will be needed to debug directly on a DSO. Maybe Jerry or someone at Seeed has everything set up for this? I haven’t opened my DSO and do not have my little screwdriver around, but from the schematics posted at code.google.com it seems like it has some kind of JTAG connector inside. But it will certainly not fit my JTAG adapter plug. Is there some pictures from inside the Nano v2 anywhere?

Of course, there can be just some small detail missing in my gcc setup, like those things I have discovered so far, but I am too blind to see my own mistakes :slight_smile:

In any case, I have learned a lot about arm debugging, and I can write up some short tutorials. I think the wiki will be a better place for this though, rather than having the information scattered around forum posts.

Hello Tormod, I do not have a JTAG for debugging, but the DSO Nano certainly has a connector for that - CN7 in the picture attached, lower left (sorry for the poor image quality). There are other interesting pads, too: both CN4 and CN5 have RX/TX connectors - one of them should be the console port.

Great idea! I’d love to learn how to debug at device level: at present I’m pretty much lost without an OS underneath.
dsonano.jpg

Which JTAG board are you using? Do you have recommendations? I know I need to get one soon, but have not yet figured out which one I can get by with.

Has anyone made any more progress here? Are there known issues that need addressing? I expect to have some time later this week so if I can help I will be glad too. I am tracking down a possible JTAG path, that if I can get working will make things much easier for me to work on.

Hi Rich, I am using an IAR rebranded version of the Segger J-Link (http://www.segger.com/cms/jlink.html) that came with an IAR dev board that I am borrowing. I have not tried anything else, so I can not recommend any on basis of my own experience. If I would buy one I would maybe look at the ARM-USB-TINY-H or ARM-USB-OCD from http://www.olimex.com. It would be important for me that it works well with openocd and other open-source tools, and without any restrictions (like the Segger EDU version has).

Olimex also has a minimal dev board, but I guess buying a LeafLabs Maple (http://leaflabs.com/devices/maple/) would make more sense, since it has excellent open-source support and a community around it. Futurlec also sells a cheap STM32 board.

I have currently no time to work on this unfortunately. I do not have any lead to what goes wrong. It is interesting that the IAR 5.0-compiled code also fails to run. I’ll paste some short debugging notes on the wiki in case it can help or inspire someone.

EDIT: Added two tutorials to the Developer’s Corner of the DSO Nano wiki http://garden.seeedstudio.com/index.php?title=DSO_Nano. This is gonna be helpful for myself at least :slight_smile:

I’ve been scratching my head over the code, and I can only see a single place where it could fail: I’d say that the culprits are almost certainly the two files ASM_Function-gcc.S. The __Start_APP symbol you mention is only half of the story: also the symbol table in the LIB is likely to be found somewhere else, given that we are using different compilers instead of IAR4.

Thanks a bunch!

Antonio

That is true. However, it will only play as soon as the APP is launched. And as far as I can see, something goes wrong already when launching the LIB. I have uncommented the “waitforkey” call which is just before the final jump to APP, but nothing appears on the screen anyway. I would have expected the start-up text messages (including “Lib version …”) to show up.