Forum : ST7/STM8
Original Post
| Post Information | Post |
|---|---|
|
April 28, 2011 - 5:01pm
|
Hi I keep getting the following error when I want to start debugging with RIDE. ------ The option bytes are set to CCF3. My external oscillator runs on 16Mhz and is working properly (I can run the code if I download the HEX code to the memory, without beeing in the debug mode). Target: ST7FLITE15B If I change the Option Bytes to "default" I am able to debug but the code runs too slow. Has anyone an idea? Daniel |
Hi,
First please make sure that you are using the latest version of the software. (both Ride7 and RKit-STM8)
Are you sure that you don't send two clocks to the OSCIN of your ST7?
If your board contains an oscilator or crystal that provides a clock to the ST7, then you must remove the 12MHz jumper from the RLin ADP. Not doing it could result in the kind of problems that you report, considering it works with default option bytes 0xF... and not your own 0xC... . The fact that the application runs without debugging is not really proving anything, unless you have a way to guarantee that the application runs exactly at the expected speed...? Please make sure you have one and only one clock, and then if the problem persists try with option bytes xFCF3 and then with xC0EF and see if/how it makes a difference.
Also, for debugging the monitor must be able to modify the flash, and for that you must not protect the full range. Please try with option bytes xC0F3 and then xFCEF and see if/how it makes a difference.
Please also try each of the other things you changed compared with the default option bytes, one by one, and see which one breaks the debugger:
to see if the problem is related to voltage treshold, try xCCFF and xF0F3. (the monitor could increase the consumption, and therefore decrease the voltage)
to see if the problem is related to internal oscillator, try xCCE3 and xF0FF. (I see no reason for that, but if all the rest gives no result, try this)
Best Regards,
Vincent
Thanks for your input!
My software is up to date:
Ride 7.30.10.0159
Rkit 2.32.10.0307
Ride7 Patch 7.30.10.0169
Yes, I'm sure I have only one clock source. I have only the ICC jumper on the adapter pcb. (RLink-ADP-ST7-STM8-V2.1). Without debugging, the application runs exactly at the predicted speed, I verified that with the oscilloscope measuring toggling of pins.
Option Bytes Settings:
0xFCF3 -> OPI Driver Error (2)
0xC0EF -> I can start debugging, after pressing a button on my custom hardware: OPI Driver Error (2750) Unable to retrieve context from the monitor, but probaby thats an other issue.
0xC0F3 -> OPI Driver Error (2)
0xFCEF -> I can start debugging, afterwards OPI Driver Error (2750)
I figured out that 0xCCE3 (RC Oscillator ON) works (still get the Error 2750) and when I turn the RC Oscillator OFF (Option Bytes: 0xCCF3) it does not work anymore.
Where can I change this?
Regards,
Daniel
Hi,
I checked and indeed the monitor requires the internal RC ON.
So for debugging you need option bytes 0x??E?, not 0x??F?
Sorry I had forgot that.
The protection is set on the second hex digit. For debugging you need option bytes 0x?0?? (protect 0.5K), not 0x?C?? (protect 4K).
For the other problem (Error 2750), are you sure that your button is not connected on one of the ICC pins?
Are sure that your application does not modify the configuration of these pins?
Best Regards,
Vincent
Hi Vincent
Thanks a lot for your help, I can debug now. For debugging I set the Option Bytes to 0xC0E3 and for production to 0xCCF3.
And you were also right on Error 2750!
Still, the microcontroller is much slower if I let it run in debug mode (without breakpoints) than without debugging. It's about factor 11.
Regards,
Daniel
Hi,
Probably when you disable the internal RC by option bytes it runs automatically on ext osc, but when you have both it selects RC, and then if you want to use ext osc, the application must select it...
Then note that the monitor will not work with all possible clock speeds.
In my previous post I said that the RC must be ON but I should have said that the clock must not be too fast.
We know that it will not work with the fastest possible speeds, but we don't know the exact limit. (also the limit might depend on things on the board, routing, etc.)
This is a direct consequence of the design of the ICC protocol, and I'm afraid you'll have to slow the application down somehow for debugging.
Best Regards,
Vincent
Hi Vincent
Thanks for your answer. I think, I can life with these restrictions.
Thank you very much for your help!
Regards,
Daniel