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
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.
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 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
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. 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
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.
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.
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.
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.
I get tired of these random differences, but I thought I would mention it. The configure scripts normally fix this sort of thing.