Forum : ST7/STM8
| Post Information | Post |
|---|---|
|
October 23, 2010 - 10:32pm
|
Goal: Change option byte 7 to one wait state for flash memory in anticipation of changing the clock from the default internal clock to the 24MHz external one. 1. Try via Ride7 (peripherals window). Interface complains that it can't write address 0x00480D. 2. Try via Ride7 (memory window). Interface complains that it can't write address 0x00480D. 3. Set the Flash FC2 register (and its complementary value) to allow access to the wait state option byte (as described in the ST manual). Well, not so much. You still can't write to the bytes of interest. 4. Modify STM8_OB.asm to set the value of option byte 7 and its XOR (0x01 and 0xFE). Then rebuild the project and start a debug session. In the debug peripherals window, the value of OPT7 shows a value of 0x01 (good) and a complementary value of 0xFE (good). But the Wait States detail field shows a value of 0x00, no wait state (very bad). But how can this be? The value of 1 corresponds to having a wait state. How can the value of the byte be 1 and the wait state be 0? 5. Despair. With the STM8_0B.asm file having the new contents and the wait state for the flash being either set or not, the target starts acting stupidly. The error "OPI driver No response from the DTC (Data Transfer Component). Terminating debug session" is not uncommon. Seems to go away when I put the asm file back to its default. It can't really be this hard to set these bits, can it? |
Hi,
The normal and only valid way to write the option bytes is to modify the asm file like you did. The detail field showing 'no wait state' is a bug of displaying. We will fix it, but you did manage to set the OB. To be sure of this, you can use RFlasher or STM8_pgm to dump the content of the CPU to a hex file and look at address 0x480D.
Now, the 'no response from DTC' error could be related to the setting of the wait states. During debug, the debugger needs to access the memory for displaying the views and for basic debugging. This is done in competition with the CPU. Changing the way the memory behaves, like for example configuring the wait states, can have some side-effects. Please consider the following points carefuly...
1. Make sure you are using the latest versions of the software. Some of these bus access problems were corrected in the most recent versions. Check both the Ride7 kit and the RKit-STM8 kit. (I wasn't able to reproduce your problem using the latest version)
2. Try to play with the debug options called 'Give bus access priority to debugger over core' and 'Activate Read-On-The-Fly'. If the problem is related to bus access, then you should observe a difference when changing these options.
3. If this doesn't help, then probably the problem is related to some configuration specific to your project. We will need you to send us (support@raisonance.com) a complete project (including source, headers, compiled objects, etc.) that shows the problem. The schematic of the board will help too.
Best Regards,
Vincent
Thanks for the suggestions:
1. Software is the latest as of a week ago. Details are in my first post to this board.
2. Need to try the suggested debug options. Sounds promising.
3. All my development so far is on the STM8-128/EVAL board from ST. Fortunately the project is extremely simple if it comes to that. I've made only minor modifications to the LED counter example program.
Hi Sam,
Thanks for your reports.
Concerning your point 4 (from your first message), the option byte 7 was not correctly decoded, and bit 2 of OPT7 was interpreted as the wait state bit, although it is actually in bit 0!
Only the displayed value or the "OPTION" peripheral was incorrect, although if you look through the memory window the value was fine.
This has been corrected and will be in the next RKit-STM8 (very soon now).
Regards,
Bruno
Per one of Vincent's recommendations:
Under RLink STM8 Configuration, Advanced options, are a number of option checkboxes. "Activate read-on-the-fly" is checked by default. Unchecking it seems to have resolved my "no response from the DTC" issue.