• State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 22 subscribers
  • Views 1572 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Crash after adding Code

Armin Breitrainer

Crash after adding Code
I have an project with following Flash Code areas:

0x0000 - 0x4000: Downloader
0x4000 - 0xC000: Firmware
0xC000 - 0xFFFF: Parameters

In the Firmware area is about 1 kbyte free memory space. The Code runs in Flash.

The firmware works fine, reprogramming the Parameter area in Flash also on the target system works fine. If a add some code, the firmware crashs after following program part for reprogramming the flash (Parameters):

1. Copy Flash Programming routine from Flash into RAM
2. Switch memory model from Harvard memory to Von-Neumann memory.
(64k Flash, 32k RAM)
3. Run Flash Routine in RAM.

The Program does not return after running Flash Routines. There is no difference to delete the contents (emty funktion). The Jump out of the function fails. If I don't reprogram the Parameter Area, the firmware seems to work fine. I can not see any mal behave.
I had the same problem, if I divide the main() Funktion in more smaller functions. But I never found the cause.

I have controlled the stack on target system and there is enough space.

Has anybody an idea, what happens?

Thanks

Parents
  • 0 in reply to Armin Breitrainer

    but I think the descriped problem doesn't coused by an timing problem. My application has no timing critical program part
    ANYTHING with (an) interrupt(s) has (a) time critical part(s). Even some non-interrupt cases can have timing problems.

    To elaborate, an example:
    1) the processing in "main" is running at a loop time of ~1 ms. 2) Characters arrive at 9600 = ~1ms/character. 3)the program is "working" (no problems show. 4) a few instructions are added to "main" making it run a few microseconds slower than the character rate. 5) the problem sporadically malfunctions, but not where the new instructions were added

    Erik

Reply
  • 0 in reply to Armin Breitrainer

    but I think the descriped problem doesn't coused by an timing problem. My application has no timing critical program part
    ANYTHING with (an) interrupt(s) has (a) time critical part(s). Even some non-interrupt cases can have timing problems.

    To elaborate, an example:
    1) the processing in "main" is running at a loop time of ~1 ms. 2) Characters arrive at 9600 = ~1ms/character. 3)the program is "working" (no problems show. 4) a few instructions are added to "main" making it run a few microseconds slower than the character rate. 5) the problem sporadically malfunctions, but not where the new instructions were added

    Erik

Children