Hey folks, I've been struggling with an issue in getting an STR7x (actually an STR712) to get as far as main() with RTX. - I have read that RTX uses the first 8 or so SW interrupts for internal use. - I have used the generic startup files (with EIC=0- so I think that this means that there is no interrupt service. - When I boot the processor, it gets through the earliest part of the boot, and (based on stepping through assembly and referencing the mapfile) gets into initializing the STR7 libs - a SWI occurs, and the configuration described means that an SWI is an endless loop. So, I think I have a configuration issue, somehow I have to have these SWI events be processed by RTX. I've read vague references in the documenation that RTX provides an SWI handler- it would have to. But I can't seem to find any documentation, example, immediately straightforward way to make this connection. I'm using uVision3.31 and the RealView toolchain. I have the 'RTX kernel' option selected in the operating system option. Can anyone point me to some docs or otherwise help? Thanks, Steve
I had a similar problem, although I was using the GNU toolset. The sample Startup.s file I was using did a branch to _start. That was the kiss of death for me because it encountered an SWI instruction in the C library init that I had no idea how to deal with - it needed semi-hosting support. I found a different Startup.s example that did a bit of setup and jumped directly to main. That worked fine. Kathy
Thanks for the reply, but I need it to go through that initial setup stuff that winds up calling an SWI. We're using a non-standard scatter scheme and __main does that setup (along with other stuff) before calling main (according to what I read). Also, I would think that other OS services would not work if you didn't have the SWI handler mapped. RTX docs say that these interrupts are used for 'internal' purposes, but I would think that most basic OS functionality would require these interrupts. Did your application use any tasks/semaphores/IPC/other OS services? Did it work? Thanks for the ideas and info. I think my solution will lie in actually mapping the interrupt to a jump into the library's SWIHandler. I'm trying to do that manually now, but I'm not an ARM7 assembler guy (yet) :) Then again, I may be totally off base and completely misunderstand the problem. If that's the case, enlightenment would be appreciated. I am very new to this ARM stuff. Steve
I am not using OS services and of course the GNU library may be a totally different animal from what you are using. I was seeing "SWI 0x00123456" when stepping through the GNU C library setup which indicates a semi-hosting command. I disassembled the library and found labels that indicated it was trying to initialize a monitor of some sort. I don't need any kind of monitor since I am using uVision, so skipping it wasn't a problem. I have my full system up and running and it has been fine. Kathy
RTX uses the SWI interrupts 0 - 7. Take a look to: RTL-ARM User's Guide, Using RTX Kernel, Writing Programs, SWI Functions.
Actually we have now a proper configuration example for the MCBSTR7 Board. It will be part of the next MDK revision 3.01 (planned for end of May) and is quite tricky (due to some strange interrupt behaviour). If you need this now, please contact the Keil support. Reinhard
Thanks for the info. I have read through the docs, and was aware that RTX uses SWI's internally. I believe that RTX is causing an SWI and expecting its SWIHandler to get executed. The startup code (maybe I'm using the wrong startup code, but I couldn't find any other than in RV30/Startup/ST) vectors SWI to a label in the startup code that simply loops (Note that I'm using EIC=0) Support suggested that I toy around with the Blinky example and I'm doing that this morning, but this example is set up for the eval board (refers to the SEL button, etc) and I'm using custom hardware (with an STR712 with JTAG) I'm still actively trying to get this software booted- and the pointers are appreciated. Steve
please contact the Keil support, so that we can send you an example project.
Done, thanks for the info.
So, I found the RTX_Blinky example in the RV30 tree, and have been toying around with that. This example boots fine on my hardware, and I can break/step/etc in the tasks that are running OK. I looked through the startup code there, and found that indeed SWI was being vectored into the SWI_Handler in the library, so I copied the config/startup files to my project that I'm trying to get running. I rebuild, fire it up, and suddenly I get to main()! Excellent, except it's totally insane. Stepping skips lines, moves into unrelated source files, etc. It's as though codespace becomes corrupted. So I reset and begin stepping through the assembly at startup again continue poking around, and eventually I find that it's hitting the os_stk_overflow function in RTX_Config. So, in the debugger, I check the RTX Kernel status, and there are no active tasks and the sytem tab tells me nothing that seems interesting: (0/254 tasks used, timer number 253, round robin timeout 247588ms, tick timer 3778019ms, stack size 57359 bytes** Tasks with User provided stack 160, stack overflow check is on) ** what stack is this?! no tasks are running, so it must be involved with the 'boot' task? 57K on it, seems to be my problem, but how do I debug further? I have a few questions for the folks who've been through this: (1) Anyone seen similar issues, and find a solution? (2) Heap size is set to zero in the RTX config. Does this make sense? Once the stack/codespace/bss is defined, does RTX just use the rest as heap? There are no (m)alloc()s in the code I'm trying to get running, but RTX may use heap for something- though RTX-Blinky works with a zero heapspace in RTX Config. (3) Is the information in the RTX Kernel dialog valid before any tasks get started? It hits the os_stk_overflow BEFORE it gets to main(). Thanks again for any advice/help/pointers. Steve
More information in case it helps anyone help me :) So, I set a break in RTX_Config\os_switch_tasks(). In the blinky example, when it hits this breakpoint, everything's good, if I check perhiperals\RTX Kernel, it's got all kinds of nice, valid looking data. This break is hit before main is called, during Kernel init, and there's init, os_clock_demon, and os_idle_demon running. In my (non-example) project, the data in the RTX Kernel dialog seems really corrupt. The break is hit before main() like in Blinky, but there are seemingly NO tasks running and the data is the garbage seen in the above post. In the blinky example, when it is trying to do the first context switch, it's trying to switch to a task with a TCB at 0x20000850, a perfectly good-looking pointer as the STR71x ram base is at 0x20000000. In my project, it's 0x5, not byte aligned, not in RAM, basically it's trash. Unfortunately, it seems very difficult to figure out why this would be the case. I'm using identical startup code: smacmull@GX520-01466 /cygdrive/c/work/arm/pgm/ArmCore $ diff RTX_Config.c ../../../../RTX_Blinky/RTX_Config.c smacmull@GX520-01466 /cygdrive/c/work/arm/pgm/ArmCore $ diff STR71x.s ../../../../RTX_Blinky/STR71x.s and identical scatterfiles: smacmull@GX520-01466 /cygdrive/c/work/arm/pgm/ArmCore $ diff Hello.sct ../../../../RTX_Blinky/Obj/Blinky.sct going through all of the IDE's setup dialogs yields no differences I can see. Anyone have any idea how to figure out why my kernel gets so corrupted? Thanks, Steve
Looking at the caller to os_switch_tasks shows an address that is in SWI_RTX according to the mapfile. Is the source included with the kernel? Is it debuggable? Would be possibly enlightening. Steve