|
hi all
new to this forum
I have a problem programming the flash. my aim is to save data received from USART communication to the flash memory (not eeprom). I made a few proc. to write and erase block / byte, neither works. if I try to debug using "step into" button the compiler crashes. also using "FLASH_DeInit" proc. crashes the compiler.
any help will be greatly appreciated.
I'm using a REva starter kit with:
- a REva motherboard v3.3 with RLink
- a REva STM8S208RB daughter board.
- Windows XP, Service Pack 3
- Ride Ver. 7.24.09.0251
- RKit-STM8 Ver. 2.24.09.0238
activated for 16K code.
here are the proc. I created:
u8 write_flash_block (u16 flash_add)
{
u16 block_number;
u8 status;
u8 checksum;
disableInterrupts();
status = 0;
// FLASH_DeInit(); //Deinitializes the FLASH peripheral registers to their default reset values.
FLASH_Unlock(FLASH_MEMTYPE_PROG);
//calculating block number. flash start address is 0x8000, eack block is of 128 bytes
block_number = flash_add - FLASH_START_ADD;
block_number >>= 7;
FLASH_ProgramBlock((u8)block_number, FLASH_MEMTYPE_PROG, FLASH_PROGRAMMODE_FAST, flash_data_write_buf); //write block
status = FLASH_WaitForLastOperation(FLASH_MEMTYPE_DATA); //checking for errors
if (status == FLASH_STATUS_SUCCESSFUL_OPERATION) //this proc. has a simple timeout counting to 2000 in the cpu clock
{
status = 0;
for (block_number=0; block_number>= 7;
FLASH_EraseBlock((u8)block_number, FLASH_MEMTYPE_PROG); //erasing the flash block
status = FLASH_WaitForLastOperation(FLASH_MEMTYPE_PROG); //checking for errors
if (status == FLASH_STATUS_SUCCESSFUL_OPERATION) //this proc. has a simple timeout counting to 2000 in the cpu clock
status = 0;
else
status = FLASH_WR_ERROR; //corresponds to the bit in flags byte
enableInterrupts();
return (status);
}
u8 write_flash_byte (u16 flash_add, u8 number_of_bytes)
{
u16 block_number;
u8 status;
u8 i;
disableInterrupts();
// FLASH_DeInit(); //Deinitializes the FLASH peripheral registers to their default reset values.
FLASH->PUKR = FLASH_RASS_KEY1; //unlock memory - step 1
FLASH->PUKR = FLASH_RASS_KEY2; //unlock memory - step 2
status = 0;
//calculating block number. flash start address is 0x8000, each block is of 128 bytes
block_number = flash_add - FLASH_START_ADD;
block_number >>= 7;
for (i=0; iPUKR = FLASH_RASS_KEY1; //unlock memory - step 1
FLASH->PUKR = FLASH_RASS_KEY2; //unlock memory - step 2
for (i=0; i
|
Hi,
We succesfully created a project with your code, but did not get any relevant problem.
- When you say that "FLASH_Deinit creashes the compiler", does it mean that you have a build-time error? If this is the case, what is the message that the compiler outputs?
- Writing the the flash is a process which is inherently complex, as the STM8 memory bus has to be handled properly. Please retrieve the application notes from ST (there are two of them) that describe In-Application Programming for the STM8. If you still have problems which are not tied to the development environment, please head to the ST support forums, as we will not be very helpful on issues related to the STM8 itself.
Let us know about your results.
Regards,
hi
thank you
crash means the compiler hangs and I have to end the ride process in windows
I solved the problem by creating a small proc. that all it does is copy the buffer to the flash and have this proc. run from the ram.
sometime the compiler, while using "step into" gives me a message that says the step is not over and asks if to continue, selecting yes just bring the same message again (can't remember at the moment the exact syntax of the message), selecting no the compiler looks as if it is still working, though it doesn't, and I need to press the pause button, set a break point somewhere ahead in the code and press the run button.
my application has more files other than the ones I copied here of course but they are all non connected to each other at the moment (I test each module by itself and didn't "put them all together" yet)
thanks
Igal
Hi,
There seems to be a mix: What you call the "compiler" is actually the debugger/simulator (which is what provides you with the stepinto/over/break/run etc commands).
You may have this specific "looks dead" behavior in several cases:
1) Your main() function exits and the code goes wild. Just ensure you have a "while(1);" statement at the end of main().
2) Your code goes wild (null pointer dereference). This may be difficult to trak, but in general the debugger will stop responding after a given line of code (always the same). Try to narrow down the problem in the code and fix it.
3) You have a spurious interrupt, which makes your code go wild as well: Use the spurious IRQ handler as described in http://raisonance-forum.xsalto.com/viewtopic.php?id=2843 and set a breakpoint on the panic() function, which will break if this is the case.
4) You have an intricated loop such as "while((mybyte & 0x01)==0);", which is translated into a single opcode "BTJF $,mybyte,0". This can occurr when looping on a semaphore or on a hardware event. In such cases the STM8 pipeline may be overlflowed by the instruction flow cumulated to the on-the-fly debug information, and you may get "Step is not over. Go on?" error messages. If this is your case you can set a break after the faulty instruction, and not perform a step-by-step debugging on this instruction. This will be corrected in the next RKit-STM8 release.
Once again, writing the Flash is not easy. Let us know if you have some further advances on your debugging.
Regards,
Bruno
thank you Bruno
we can safely say it has nothing to do with scenarios 1,2,4
I'll check #3 scenario
the debugger is stuck sometimes after simple instructions such as "FLASH->CR2 |= FLASH_CR2_WPRG;" (when using step-by-step debugging)
programming the flash is successful
thanks
Igal
Hi,
scenario #5...
For stepping the debugger must set and clear breakpoints, and for that it must modify the flash, which includes manipulating the flash control registers. Therefore, you should expect problems when debugging functions that write the flash. (register values broken between steps, debugger hanging or reporting errors, etc.)
Considering that your code works when just launched but not when stepping, this could very possibly be the explanation of your problem.
I think that if you simply avoid stepping into the FLASH_... functions, then it should be all right. In theory these functions have been validated by ST already, and you shouldn't need to debug them, isn't it?
The other solution would be to place the flash-writing functions that you want to debug into the RAM instead of the Flash. (just for the time of debugging them) The compiler allows this if you have the latest version. Then the debugger will not need to modify the flash in order to set/clear breakpoints and step, and you should be able to debug your function. (This is just theory, and I have never validated it. I will ask Bruno to do it, since he has got your code)
Unfortunately, there is no technical way to solve the problem in a more clean way.
Best Regards,
Vincent