|
March 4, 2009 - 4:58pm
Guest |
Hi,
I am using Ride7 with STR9 MCUs -Ride7 version 7.16.0000, RKit-ARM version 1.16.0930 and RLink-Pro version.
1. Using the default linker script from Raisonance with STR911FAW42 and looking at the generated STR91xFx42_FLASH.ld (or the _RAM.ld), the generated _nbb_size is 0x3. Shouldn’t it be 0x2 (meaning 32KB according to STR9 Reference Manual)? I get the same results when selecting the STR910FW32… I’ve written my own startup file in which I am not using the _nbb_size variable so this is not an issue for me. Just wanted to check I wasn’t missing anything here? And notify you guys :)
2. When launching a debug session from RAM, the code is downloaded correctly but before running, the PC value jumps to 0x50001FFC which corresponds in my code to the location of the Undefined_Handler(). Of course when I run, the application is stuck in the while loop of that ISR. I need to set manually the PC value to 0x00000000 and then the program runs and debugs ok.
When launching a debug session from FLASH, same thing happens, the PC value jumps to 0x00002038 which corresponds in my code to the location of the Undefined_Handler(). This doesn’t seem to be a coincidence... Is my code starting to execute before I press 'run'?
If I remove the link to Undefined_Handler() from the startup file, I get the same problem with Prefetch_Handler(). If I remove all interrupts from the startup, PC value jumps to a location out of code area and crashes. Anybody had similar issues?
Thank you for any input!
|
Hi,
There is some system (hidden and probably undocumented) memory that the CPU needs enabled. (I don't know why, although I can guess several possible explanations)
And for that the _nbb_size (in fact the value at 0x54000004) should never be smaller than 3. So that is not a problem in the startup and linker script.
And having changed this could very possibly be the source of your second problem.
Please correct this first point and see if the second problem persists.
Just note that the STR9 CPU does not provide any mechanism for the debugger to reset it without letting it executing some code. This is a limitation of the hardware. (common to many ARM devices, unfortunately)
So yes, your code starts to execute before you press run.
To work around this I usually place a delay loop at the start of the main function when I intend to debug the application. See this example: \Examples\ARM\test\...
But of course if the problem appears in the startup, before the main function is called, that will be useless. You have to add a delay loop at the start of the startup if you are not using the default startup.
I hope it helps,
Vincent
Hi,
Thanks for your help!
1. I couldn't find any ST documentation requiring the value to be no smaller than 3. Furthermore, the ST demonstration firmware uses the FMI_Bank_Remap_Config function (in 91x_fmi.c) with 2 as a value for non boot bank size. Doesn't mean you're not right though ;) Anyway I've tried changing the value to 3 but it didn't solve problem 2.
2. I've tried your suggestions adding a delay loop at the start of the startup and the main function, but I still get the same behavior. The code never seems to jump from startup to the main application - even using the default startup file. :/ My code works fine in release mode, only debugging (RAM or Flash) seems to cause this problem.
Using the RIDE7 examples such as "test" or "ADC_STR9" work fine in debug mode (which means my hardware must be fine). But if I add my own source file defining the ISRs (such as the 91x_it.c file provided with the ST firmware library), the same behavior occurs. Looking at the linker script, I understand the ISRs are mapped to _start if not defined in another source file, which may explain why my debugging works fine without it. Could I send you a project example to get your opinion? And see if I'm missing something else?
Thanks again for your help!
Hi,
Yes, please send us your simplest project that shows the problem. (our example with modified ISRs)
Email it at this address:
And include a link to this post in the text o the email.
Best Regards,
Vincent
Hi,
I received your project and I can reproduce your problem, but only in RAM mode. (although it seems that once it has happened, it is sometimes required to make a power-on reset before I can work with the device again, either in Flash mode or without the ISRs)
I don't understand the problem yet, and I will need more time for enquiring. :(
And as I will be out of office tomorow, you should not expect an answer before next week...
Can you work in Flash mode for a few days?
Best Regards,
Vincent
Hi,
That's interesting that debugging works fine in Flash mode. I tried doing a power-on reset and could make Flash debugging work as well. I had noticed it occasionally worked but could not figure out how I did it. So thank you for that! :D
I'm still confused since the differences between a power-on reset and a system reset is that the POR resets to default the values for Clock Control register, PLL Config register and System Status register, which we are not modifying (except for turning off the PFQ/BC in the default startup file). Same thing for the Flash Protection level 1 register or the Flash configuration register (not reset by system reset)...
I guess one question would be how is the startup code even getting to the LDR PC, =UndefinedHandler?
And yes I can work with debugging in Flash mode for now.
Many thanks again!
Hi,
I still don't fully understand the problem, but I was able to trace our code back to when it started happening and what piece of code was added that made it happen, and workaround it.
Here is a test patch that should allow you to work in RAM mode:
ftp://... <<>>
Copy the file in \bin\
Please let me know how it goes.
I will inquire some more and try to understand the problem better.
Best Regards,
Vincent
Hi,
I copied the files from the patch, but I still get the same behavior as before when debugging in RAM mode. I rebooted my machine, tried power cycling the device but with no success... And debugging in FLASH mode does not work anymore. In both cases, the code never seems to jump from startup to the main application, and ends up in the Undefined_Handler().
I saw the patch contained a new version of STR7_pgm.exe. I don't know how your code works - but just in case - that is not supposed to be STR9_pgm.exe?
I am using Ride7 version 7.16.0000, RKit-ARM version 1.16.0930 and RLink-Pro. But I assume that is what you are running with as well, and those are the only files I am supposed to modify... I wish I could provide more input!
Best Regards,
Victor
Hi,
Sorry, the link was pointing to the wrong file.
Here is the correct file:
ftp://www.raisonance.com/pub/STRx/patch_090310_STR9_RAM_UndefIRQ.zip
Best Regards,
Vincent
Hi,
After installing the patch, debugging in RAM mode works fine! :)
It is interesting to note that my code still jumps to the Undefined_Handler() when interrupts go off. Not sure if that's a clue to what is happening... When not debugging, these interrupts are processed correctly: UARTs, timers, ADC are working fine... But at least I can now debug from RAM with interrupts disabled.
Thanks again for your help!