|
July 6, 2007 - 11:53pm
Guest |
Hello Vincent,
Details of above issue:
1) I have set up an FIQ interrupt service routine using the FIQ_Handler in 91x_it.c, which maps the SSP1 RX FIFO half full interrupt to the FIQ (all other SSP1 interrupts are disabled).
2) After writing four items to the SSP1 TX FIFO, I get an initial FIQ/SSP1 interrupt => where the FIQ interrupt service routine reads the items out ot SSP1 RX FIFO => all good => the mode has changed from USER/0x10 to FIQ/0x11 and both F and I interrupts are disabled in the PSR
3) But, when the program returns to main, which writes four new items to the SSP1 TX FIFO => the mode is still FIQ/0x11 and the F & I interrupts remain disabled!
4) If I stop program execution and change the mode back by hand to USER/0x10 where F & I are enabled in the PSR, I will get another FIQ_Handler Interrupt!
Why aren't the instructions in crt0_str91x.s (I'm certain that it is being used, because I have specified the crt0_str91x.o as the startup file) being executed properly => supposedly FIQHandler (in crt0_str91x.s) calls FIQ_Handler after it saves the context and restores the context before it returns => But, when I examine the Assembly code => FIQHandler does not appear to be used, so no context save/restore is occuring!
What's up,
1) why isn't the context being returned to USER Mode where the F & I Interrupts are enabled (by STR9X spec, the SSP1 RX FIFO interrupt is cleared when the FIFO data is read by the uC inside the FIQ ISR) ???
2) why can't I find the FIQHandler instructions detailed in crt0_str91x.s in the assembly listing (they should properly save and restore uC context)?
Thanks in advance for your help,
mschott
|
Hi,
What is it you call "the assembly listing"?
That would be the crt0_STR9.lst, but unless you assembled the startup yourself, you don't have this file, so I don't think that's what you are talking about...?
Is it the disassembly view in the debugger/simulator? If yes, then it's normal that you don't see these symbols and source lines, because the default startup is assembled without debugging information. (for starting the debug session on "main") I suggest you assemble the startup with debugging information: copy the crt0_STR9.s from "c:\ride\lib\strx" in your project's folder, add it to your project, configure the assembler for generating debugging information, assemble, configure the linker to use your new crt0_STR9.o, remove the crt0_STR9.s from the project, link, start debug. Then, you should be able to step out of your FIQ_Handler function into the end of FIQHandler.
You might also want to make sure that when stepping out of the FIQ_Handler function, you are in the disassembly view and use F7 (step into) and not F8 (step over). Then you'll see exactly where the execution goes, instruction per instruction.
Finally, I suggest you check your version of RIDE. Click "help"->"about" and check the BN "Build Number". If it's not "BN746-P1-P2" or "BN746-P1-P2-P3", then you should upgrade.
Best Regards,
Vincent
Hi mschott,
just one more question, are you using the startup file from ST (last Firmware lib V1.2 in ST web site) or your own/default startup ?
Hello Vincent,
Further Details to your response:
1) Yes, I'm using the debugger/simulator to view/step through the assembly listing and have Assembler Debug check
box enabled.
2) I had previously implemented all your sugestions for using crt0_STR9.s => and it still does not work! =>
It never appears to call FIQHandler => using step/F7 inside FIQ_Handler (returns directly back to the main code).
3) Why do I have to delete the crt0_STR9.s from the project list after compiling and before starting the debugger???
3) I'm using Build #: BN746-ST7-ARM-80C51-P1-STR750 (not certain if this correct and up to date???)
Notes on build #:
A) I downloaded and installed your last STR9x free update (dated 1/26/2007) on 2/3/07 =>
these are the versions you tell me to use even though I have 2 RLINK Pros!
B) I downloaded and installed the patch you made for me to run Rlink Pro for an 8/4 MHz External Osc on 3/22/07.
C) I downloaded and installed some patchs ST made for me to fix the I2C => this did not affect your build # =>
but it did affect your STR9x library and some of the files in C:\RIDE\LIB\STRX!
Hello MBS,
Yes, I also had previously tried/(linked in) the new 91x_init.s from ST Website => that also does not work!
Thank you, but still need help,
mschott
Hi,
Sorry for the late answer. I was asking help from the ST support team on this and we had several email exchanges before we could get back to you.
There was indeed a problem in the startup, but it should already be fixed in the "91x_init.s" from ST website. Please either send us a project showing the problem and that uses the "91x_init.s" from ST (send it to "support@raisonance.com"), or give a try at this example:
ftp://www.raisonance.com/temp/ST/STR91X_libv1.1_RIDE6.zip
Best Regards,
Vincent
Hello Vincent,
I tried 91x_init.s startup file and it did not fix problem, but I will try again (perhaps I did something wrong the first time).
What example would you like me to try from the Zip link you sent me, which one uses the FIQ Handler???
Thank you,
mschott
Hello Vincent,
Must have done something wrong the first time using ST's 91x_init.s => 91x_init.o!
I know get multiple interrupts from FIQ_Handler using 91x_init.s/o as startup file.
Question still remains, does the library link that you sent me have an FIQ example???
Thank you,
mschott
Sorry, I only sent you half of it. You have to take this file too:
ftp://www.raisonance.com/temp/ST/str91xstdlib.zip
And then the example is there:
str91xstdlib//str91xstdlib/Stdlib/Test_FIQ_
I have not tried it myself. It comes directly from the ST support.
Best Regards,
Vincent