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

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
  • I think it should be possible to test this behaviour under the uVision2 simulator. Once you can douplicate this problem there, it is very easy to find the reason of this mis-behaviour.

    For example you can use the trace recording of uVision2 to find the instructions that cause your problem.

Reply
  • I think it should be possible to test this behaviour under the uVision2 simulator. Once you can douplicate this problem there, it is very easy to find the reason of this mis-behaviour.

    For example you can use the trace recording of uVision2 to find the instructions that cause your problem.

Children
  • in 99% of the cases where I have seen "crash after adding code" the reason has been the timing in the original code.

    Erik

  • Thank you Erik,
    but I think the descriped problem doesn't coused by an timing problem. My application has no timing critical program part. The watchdog timeout startes the firmware a few secondes later. The watchdog is the only time critical part.

    Armin

  • 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

  • what derivative are you using?

    Erik

  • Thank's Keil Support Team,
    I am working with your simulator and the trace function. But I think, the Simulator don't know about the changing memory model. I copy the Flash programming routines form the Flash into the RAM at 8000H. Then I change the memory model from:
    code: 0000H...FFFFH (Flash)
    xdata: 0000H...7FFFH (RAM)

    to
    code: 0000H...7FFFH (Flash) and 8000H...FFFFH (RAM)
    xdata: 0000H...7FFFH (Flash) and 8000H...FFFFH (RAM)


    After changing the memory model, the code runs from the RAM. But the Simulator don't know about the changed memory and continue at code 8000h form Flash and not from RAM!

    Is there a way to teach the simulator about the changing memory model?

    Thank you for our help

    Armin

  • Erik,
    maybe you are right with your timing problem. The crash is caused after dividing the main() into more smaller functions with about 3 Parameters. Maybe it slow down the controller. But I'm not sure if it is enough for an crash.
    I will check it.

    I'm using an 80C320 form Dallas on an Phytec micro modul 8051 with horrible 16k Flash blocks.

    Armin

  • The MAP command allows you to map memory even as von-Neumann memory. Take a look to the µVision2 Debug Commands on-line help (DBG51.CHM) and refer to the MAP command. Maybe this allows you to solve your issue.

  • Perhaps, your code is too long for your memory, and over-writes interrupt table...

    Just an idea... who knows?

    Jil