Page 3 of 18
Re: ChibiOS OpenOCD support
Posted: Mon Aug 27, 2012 2:25 pm
by noether
dandys wrote:Giovanni wrote:I missed this:
@dandys, I believe that __attribute__ is a GCC-specific extension.
Agree. But there can be some similar extensions for other compilers too (as is for packed structures for example). In this case some macros like KEEP_SYMBOL_BEGIN and KEEP_SYMBOL_END can be defined in chtypes.h. Are some IAR or KEIL users arround? Anyway still not sure if this would be the best solution. Declaring as volatile won't work IMHO. At least I can't find it _must_ work in C89 spec.
I am not an expert programmer, so correct me If I am wrong. But when the compiler (when I apply -01,2,3 or s) optimizes some variables that I had in "hardware" routines (such as timers, interrupts, etc), then I have an unexpected behavior, because sometimes these variables are not referenced in other place of the code and the compiler "thinks" they can be erased.
Declaring that variables volatile tells the compiler do not optimize them, and it has worked for me so far.
http://en.wikipedia.org/wiki/Volatile_variableI do not know if they are the same case what you are discussing about.
Re: ChibiOS OpenOCD support
Posted: Mon Aug 27, 2012 2:53 pm
by dandys
noether wrote:dandys wrote:Giovanni wrote:I missed this:
@dandys, I believe that __attribute__ is a GCC-specific extension.
Agree. But there can be some similar extensions for other compilers too (as is for packed structures for example). In this case some macros like KEEP_SYMBOL_BEGIN and KEEP_SYMBOL_END can be defined in chtypes.h. Are some IAR or KEIL users arround? Anyway still not sure if this would be the best solution. Declaring as volatile won't work IMHO. At least I can't find it _must_ work in C89 spec.
I am not an expert programmer, so correct me If I am wrong. But when the compiler (when I apply -01,2,3 or s) optimizes some variables that I had in "hardware" routines (such as timers, interrupts, etc), then I have an unexpected behavior, because sometimes these variables are not referenced in other place of the code and the compiler "thinks" they can be erased.
Declaring that variables volatile tells the compiler do not optimize them, and it has worked for me so far.
http://en.wikipedia.org/wiki/Volatile_variableI do not know if they are the same case what you are discussing about.
What you describe is true. Volatile qualifier tells compiler to not optimize ACCESS to this variables. So when you have code like this:
Code: Select all
int a=6;
int i;
for(i = 0; i < 10; i++) printf("a = %d", a);
GCC will probably optimize ACCESS to "a" variable so "a" is read only once before for cycle. This is bad in case when "a" is changed during for cycle from another thread, or if we consider "a" is for example UART data register, where more consequent reads may be needed for read out FIFO.
But when variable is not used (accessed) at all, it's different story. GCC simple put every variable and function to special section when --ffunction-sections and --fdata-sections switches are enabled. At this point variable is still preserved in object file. When linking with enabled gc-sections switch, linker walk through every single section and when some section isn't refferenced from another place, is discarded.
Re: ChibiOS OpenOCD support
Posted: Mon Sep 03, 2012 10:04 pm
by awilkinson
Possibly a little off topic but openocd 0.6.0 from Freddie Chopin's site seemed to work well with Giovanni's Chibios+Eclipse+STM32F4discovery guide. Used the debug configurations from Freddie's stm32f4_blink_led example for programming and debugging.
Even more off topic: Used Yagarto for Giovanni's guide and found that the install path shouldn't contain any spaces. Could someone tell me where to report this and other info if it is of interest to anyone.
Re: ChibiOS OpenOCD support
Posted: Tue Sep 04, 2012 7:59 am
by Giovanni
Thanks, I will add a note into the guide about spaces.
Giovanni
Re: ChibiOS OpenOCD support
Posted: Mon Oct 01, 2012 2:53 pm
by mabl
Hi Giovanni,
I'm back from holidays and looking at OpenOCD support again. Have you found a solution to the dropping of ch_root? If so, it is not included in the most recent SVN, right?
Re: ChibiOS OpenOCD support
Posted: Mon Oct 01, 2012 3:16 pm
by Giovanni
I forgot about that
I will do something in the evening.
Giovanni
Re: ChibiOS OpenOCD support
Posted: Mon Oct 01, 2012 3:24 pm
by mabl
Great
As an insentive:
Code: Select all
mabl@mikrocanonix [04:20:08] [~/Programming/ARM/Projects/ChibiOS_openocd/demos/ARMCM4-STM32F407-LWIP-FATFS-USB] [master *]
-> % arm-none-eabi-gdb build/ch.elf
GNU gdb (32-bit ARM EABI Toolchain JBS-2011.09-69-v2011.09-69-15-g4c24572) 7.2.50.20100908-cvs
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi".
For bug reporting instructions, please see:
<https://github.com/jsnyder/arm-eabi-toolchain>...
Reading symbols from /home/mabl/Programming/ARM/Projects/ChibiOS_openocd/demos/ARMCM4-STM32F407-LWIP-FATFS-USB/build/ch.elf...done.
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0x20000042 in __main_stack_base__ ()
(gdb) monitor reset halt
JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080001f0 msp: 0x20000400
(gdb) tbreak main
Temporary breakpoint 1 at 0x8026b44: file main.c, line 617.
(gdb) continue
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.
Temporary breakpoint 1, main () at main.c:617
617 halInit();
(gdb) continue
Continuing.
^C
Program received signal SIGINT, Interrupt.
_idle_thread (p=0x0) at ../../os/kernel/src/chsys.c:61
61 }
(gdb) info threads
[New Thread 536899336]
[New Thread 536901456]
[New Thread 536899024]
[New Thread 536901760]
[New Thread 536905776]
[New Thread 536904464]
[New Thread 536907216]
8 Thread 536907216 (shell : : WTQUEUE) chSchGoSleepTimeoutS (newstate=8 '\b', time=134229708) at ../../os/kernel/src/chschd.c:196
7 Thread 536904464 (http : : WTSEM) chSchGoSleepTimeoutS (newstate=8 '\b', time=536906984) at ../../os/kernel/src/chschd.c:196
6 Thread 536905776 (No Name : : WTSEM) chSchGoSleepTimeoutS (newstate=32 ' ', time=536886356) at ../../os/kernel/src/chschd.c:191
5 Thread 536901760 (lwipthread : : WTOREVT) chEvtWaitAny (mask=0) at ../../os/kernel/src/chevents.c:381
4 Thread 536899024 (blinker : : SLEEPING) chSchGoSleepTimeoutS (newstate=32 ' ', time=0) at ../../os/kernel/src/chschd.c:191
3 Thread 536901456 (usb_lld_pump : : SUSPENDED) usb_lld_pump (p=0x1) at ../../os/hal/platforms/STM32/OTGv1/usb_lld.c:696
2 Thread 536899336 (idle : : CURRENT) _idle_thread (p=0x0) at ../../os/kernel/src/chsys.c:61
* 1 Thread 536873296 (main : : WTOREVT) chSchGoSleepTimeoutS (newstate=32 ' ', time=2224) at ../../os/kernel/src/chschd.c:191
(gdb)
Code: Select all
mabl@mikrocanonix [04:19:57] [~/Programming/ARM/Projects/ChibiOS_openocd/demos/ARMCM4-STM32F407-LWIP-FATFS-USB] [master *]
-> % ~/bin/oocd/bin/openocd --search ~/bin/oocd/share/openocd/scripts
Open On-Chip Debugger 0.6.0-rc1-dev-00006-g9db3f00-dirty (2012-10-01-15:45)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from 3333
Info : device id = 0x10016413
Info : flash size = 1024kbytes
Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
Info : should no be called
-------ChibiOS_get_symbol_list_to_lookup()
--------------rtos_qsymbol()
--------------rtos_qsymbol()
-------ChibiOS_detect_rtos()
Auto-detected RTOS: ChibiOS
-------ChibiOS_create()
-------ChibiOS_update_threads()
-------ChibiOS_update_memory_signature()
Info : Successfully loaded memory map of ChibiOS/RT running with version 2.5.1
Investigating ChibiOS task 0
Error: ChibiOS registry integrity check failed, double linked list violation
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080001f0 msp: 0x20000400
-------ChibiOS_update_threads()
Investigating ChibiOS task 0
Error: ChibiOS registry integrity check failed, double linked list violation
-------ChibiOS_update_threads()
Investigating ChibiOS task 0
Investigating ChibiOS task 1
Investigating ChibiOS task 2
Investigating ChibiOS task 3
Investigating ChibiOS task 4
Investigating ChibiOS task 5
Investigating ChibiOS task 6
Investigating ChibiOS task 7
Investigating ChibiOS task 8
Finished checking the thread registry.
Exporting ChibiOS task 0
Thread in state 8 (WTOREVT)
Exporting ChibiOS task 1
Thread in state 1 (CURRENT)
Exporting ChibiOS task 2
Thread in state 2 (SUSPENDED)
Exporting ChibiOS task 3
Thread in state 6 (SLEEPING)
Exporting ChibiOS task 4
Thread in state 8 (WTOREVT)
Exporting ChibiOS task 5
Thread in state 3 (WTSEM)
Exporting ChibiOS task 6
Thread in state 3 (WTSEM)
Exporting ChibiOS task 7
Thread in state 13 (WTQUEUE)
Info : Current thread is 536899336
-------ChibiOS_update_threads() SUCCESS!!
-------ChibiOS_get_thread_reg_list()
-------ChibiOS_get_thread_reg_list()
-------ChibiOS_get_thread_reg_list()
-------ChibiOS_get_thread_reg_list()
-------ChibiOS_get_thread_reg_list()
-------ChibiOS_get_thread_reg_list()
-------ChibiOS_get_thread_reg_list()
Re: ChibiOS OpenOCD support
Posted: Mon Oct 01, 2012 4:04 pm
by Giovanni
Just wow, are you already to the point to be able to contribute the patches back? we could have this in time for 0.7.0 I hope.
Giovanni
Re: ChibiOS OpenOCD support
Posted: Mon Oct 01, 2012 4:24 pm
by mabl
Hi Giovanni,
there are still many rough edges and I'd like to make it rock solid before I contributing it back. But from coding still and refactoring I'm already quite happy with it. Once it's in a generally usable state, I'll provide instructions on how to use it. Hopefully there will be enough testers to iron out all bugs. I expect this will be mid/end of next week.
Re: ChibiOS OpenOCD support
Posted: Tue Oct 02, 2012 7:16 am
by mabl
Hi Giovanni,
I'm still kind of stuck on how the registers are saved to stack on context switch. Could you elaborate how it works? I see in chcore_v7m.c the
Code: Select all
push {r4, r5, r6, r7, r8, r9, r10, r11, lr}
What about the other registers? Are they saved by some gcc magic I'm not aware of? What I need is a map like
Code: Select all
Stack register layout
r4
r5
r6
r7
r8
r9
r10
r11
pc <-- Stack head
I've had a look at ecos and FreeRTOS but they are even more complicated.