This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome. This forum is NOT for support.
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.
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.
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.
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.
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?
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)
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.
I will do something in the evening.