URGENT: No source available for "0x000001 (0x000001)() "

[efrencabebe]

Hello,
I am currently experiencing a debugging error stating 'No source available for "0x000001 (0x000001)() "'. This error occurs during a reference to a Simulink-developed, Embedded Coder generated C model developed by us. A snapshot is attached.

MCU: MM9Z1J638 (S12Z core)

IDE: CodeWarrior for MCU 10.6.4 

Debugging / Flash Tool: P&E Micro Multilink Universal

• What does this error signify?
• What could be the cause of this error occurring?

[christinar]

Hello,

I'm using the DEVKIT S12ZVC with CodeWarrior and P&E USB Multilink. I had the same error after I tried to "Step over" in debug mode. 

The mistake was the "Timer Interrupt Enable Register (TIE)". I set it but it was wrong. 

[Alice_Yang]

Hello Efren,

Please be sure when you download project , the chip is selected right .

And you can first create a simple project to have a try .

Hope it helps

Alice

[efrencabebe]

Hi Alice,

Thank you for the quick response. We have been using the correct chip since the beginning (S12Z). Attached is a picture of the project properties showing the S12Z C/C++ build options, as well as the Simulink compilation options showing the Freescale S12Z chip being chosen as the target platform.

 

I have been developing on the RD9Z1-638-4LI evaluation platform that uses the MM9Z1J638 core for a few weeks, and have had success with creating a project and exercising the peripheral modules (voltage / current and temperature sensing), but our actual logic is within this Simulink block.

I'd like to reiterate my questions:

• What is the "source" this error is referring to? 
• What causes this error to be triggered? 
  

Thanks,
Efren

[MJW]

Hello,

Regarding the your first question:

The debugger is reporting that it can't find any source for the code at address "0x000001". That is not suprising since it is not allowed to place any code there (executing code from I/O space would trigger a machine exception). This behavior is a sign of a software crash.

Regarding the cause:

Judging from the posted screenshots this is likely caused by a stack-overflow (i.e. the stack grew past the SRAM into the I/O register space). To confirm please check the content of CPU register 'S' before executing "RTS" in your scenario.

Hope that helps,

MJW