I have been comparing it with the asm code that is generated by MDK(RVD_S) and there is only one BX at the end for MDK. With the above changes my GCC generated code looks very close to MDK.
That is very strange. What is then the point of a double branch?
BTW, i will go look at my interrupt asm code. i forgot the OffsetOf part… :). But the base code that I used returned values in r3(i think). Is this not required?
There is no point in that. It is an artifact. We have full code inlined using asm (including final branch),but we didn’t tell the compiler that we took care of it so it adds another branch at the end.
The solution is to remove our branch instruction or “tell” compiler that the function is “naked” and has all the needed instruction inlined.
My bad, you can try this one: YAGARTO - Yet another GNU ARM toolchain
Yes I have it as well ;D and it is 4.6.2. I did try it before, but I am not sure if it is as full as Sourcery’s implementation. Sourcery has different organization of libraries in their directory tree. They have librares for thumb2 which we are trying here. Yagarto has only thumb. So using Sourcery’s tool chain works (as far as compiling and linking goes). I will try Yagarto after I have Sourcery running on the device.
Thank you!
How do I decode the stack?
.section i.FAULT_SubHandler, "xa", %progbits
@ AREA ||i.FAULT_SubHandler||, CODE, READONLY
FAULT_SubHandler:
@ on entry, we have an exception frame on the stack:
@ SP+00: R0
@ SP+04: R1
@ SP+08: R2
@ SP+12: R3
@ SP+16: R12
@ SP+20: LR
@ SP+24: PC
@ SP+28: PSR
@ R0-R12 are not overwritten yet
Keep ending up in FAULT_SubHandler, but can’t figure out from where…
Edit: Should LR contain the source line where exception happened?
You know what, I’m getting sick and tired of this CPU.
I used Atollic’s Light STM32 version to create a default project for the Discovery board.
[ol]Half the time their own GDB server can’t write to the flash on the chip.
The default program sets up the chip then loops in main for ever. Even this crashes and resets the whole chip back to “power on state”, after some milliseconds[/ol]
Edit: Strange, if, after a “reset to zero”, I do a single step then the program is back where it should be and all the registers are back. Don’t know what is going on…
Errol,
You know that’s not CPU’s fault that software is buggy…
Even if you use NXP chips you should see the same problem… as debuggers are wrong not uC…
Maybe we could manage to get some debugger working using OPENOCD or something else…
Even Keils debugger has its own bugs. If you try to debug the sample program and try to check the value of some variables, some of them show as invalid…
Edit: Just tosay that if you use Freescale Codewarrior things get worse than this when it comes to debug… At least that was my experience…
I am taking it slow - learning a lot on the way. I haven’t tried it on the device yet,so can’t help with your debugging issues. One thing that might help you is to look at tinyclr.axfdump. Look at the address of the Fault_SubHandler and then search where that address is used.
@ Pablo:
Tried to compile the supplied code in Keil. Also keeps resetting.
Loaded the supplied binary, and it runs fine. 
@ Architect:
It gets called by the HardFault interrupt.
Seems to happen here:
ldr r4, [pc, #168] ; (0x8000270 <BootEntry()+192>)
Did you compile before you started making changes for GCC or after? It is possible that something changed by accident. I have compiled version with MDK (if you need it) that I did before starting making changes for GCC.
@ Errol,
I found this thread helpful
Sorry about the confusion. The code that I compiled was the Discovery Demo code that came with the board.
The supplied image works, but if I compile and debug it from within Atollic or Keil then it crashes the board. It is as if the debugger badly interferes with the CPU.
But I think I must take a break now. Need to work on my buzzer contest entry… ;D
BTW, I ran my MF code on the CPU without the debugger connected, using the ST flash tool, can’t remember it’s name, to flash and run the code. It might be getting farther than I think…
Hmm. I’ve tried Discovery Demo code and it works fine for me. (MDK 4.22a)
I’ve tried Discovery demo either and it works. Only I couldnt watch some variable as it was listed as unknown but only with one, the rest of watchs works great.
I think you must have a problem with your drivers or something. Using Win7 32bits and Keil.
Did you push the blue button?
Did the leds stop rotating after the press? Did the g-sensor start driving the leds?
In keil it runs, for me, but it keeps resetting which you don’t see unless you try to move the program into the next stage. After the reset the program is back in the first state, ie, the running lights mode…
I am sure I have tried, but I will double check tonight.
I did that and it works. I even use the board as a mouse on my PC just to test. That works great. Even into the debugger doing breakpoints and stepping trought the code…
Did you use the latest Keil version ?
If I dont remember wrong the first thing the board does is check for hardware failures initiating everything on the board (USB, Mems, accelerometer and Audio DAC) after that test, it writes some bytes to flash to indicate the test passed and not check anymore for it. Maybe your board is defective. Try to erase the flash, load the program again and check if it passes the test stepping into the code.
I even tried other examples on the discovery firmware (Check the firmware version, they released a newer one, 1.1 I think after the initial release, and has a lot more examples).
Hope it helps.
I dont thing it has anything to do with it but I bougth my board from Farnell, it’s not the one of the free samples…
Bought my board from RS.
Hmm, I ordered an FTDI dev board that can do JTAG. Will wait for that and my Cerberus board. Maybe my board is dead. I scoped the reset pin and it bounces, as if something is resetting it. I don 't know if the watchdog gets enabled somehow…
Bummer, neither Cerberus shipment nor DuinoProto shipment is even in my country yet…
I hear you. I feel the same when I order parts from Hong-Kong or Taiwan. The good thing about DuinoProto is that you can make it yourself if needed.