Illegal BP at starting the engine (KIT33812ECUEVME)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Illegal BP at starting the engine (KIT33812ECUEVME)

1,676 Views
josh007
Contributor II

Hello,

 

i want to integrate the KIT33812ECUEVME to a real engine. First i only want to regulate the ignition, so i only connect the VRS sensor and ignition coil from the Engine to the ECU. The other components are still connected with the simulated engine environment.

 

But now if i pull on the engine the debugger gives me an illegal BP. Do anyone knows what is the reason for this ?

 

Best regards

Andreas

Labels (1)
0 Kudos
Reply
6 Replies

1,196 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

Andreas,

First I need to know the problem is due to software or hardware side. Could you please create a new project with wizard, can you download and run the new project code on the board?

If the problem only happened on your own project(no problem with new project), There is no document on the list of illegal BP, but I will try to explain it in detail to you.

There can be many reasons for “ILLEGAL_BP” error message.

  1. unmapped interrupt vectors or non-serviced irq is enabled or incorrect ISR vector number is used. The illegal breakpoint error often happens when the MCU is getting lost and executes dummy code. If this happens whenever you enable your interrupt, check that the interrupt vector has been correctly initialized with the address of the interrupt service routine. If the interrupt vector is left blank (0xFFFF)  this could be the cause of the problem.
  2. watchdogs: this might be a COP reset, check that the watchog, if enabled, is being fed correctly. Also please check that the stack is not overflowing.
  3. bad SW approach to RAM, e.g. some buffer overflows, STACK overflow…
  4. code optimization by CW may cause the JMP to non-defined program memory address and PC lost way.

Please check your code if it belongs to one of the reasons above.

Hope it helps!


=========================================

this answer is for you, if it helps, please click on "correct answer" button. thanks!

Best Regards,

ZhangJun







0 Kudos
Reply

1,196 Views
josh007
Contributor II

I think the problem is something with the usb multilink interface. if i only want to generate spark this doenst work in the debugging mode with the ecu connected to the usb multilink interface. It only generates one spark and then gives out the "illegal bp". if i take the interface away it generates sparks and the software keeps running.

does the spark voltage trouble the debug mode??? and what can i do against this problem ? I want look at the engine parameters in realtime in the debugging mode.

Best Regards

andreas

0 Kudos
Reply

1,196 Views
iggi
NXP Employee
NXP Employee

Hi Andreas,

the problem is certianly not with the USB multilink interface/connection.

If you would run the application without debugger it will work OK. But when the debugger is activated, the MCU is in Special Single chip mode.

Regarding the Special single-chip mode you should know that:

- It is used for debugging single-chip operation, boot-strapping, or security related operations.

- The background debug module BDM is active in this mode.

- The CPU executes a monitor program located in an on-chip ROM.

- BDM firmware waits for additional serial commands through the BKGD pin.

- In special single chip mode the BDM is ACTIVE out of reset – that means the CPU is halted and the BDM firmware is waiting for commands that come from BDM cable.

- The special modes should not be used in final application, that’s for development purposes only.


Regarding your problem, some values/parameter used by the program application are updated by time and fed back to the MCU. So the most probably while stepping through the code, you don't get the actual values and that causes code runaway.

Try using breakpoints between some parts of code and let it run. But breakpoints can also cause similar problems.


Regards,

iggi

0 Kudos
Reply

1,196 Views
iggi
NXP Employee
NXP Employee

Looking at the PNG you attached, there is the Dummy ISR for interrupt vectors that aren't used by application but must be defined in case such interrupt happen so it can be serviced.

The PC holds the $FF13 value which should correspond to System Call Interrupt (SYS) (Vector base + 0x0012) which software interrupt. The SYS CALL interrupt routine should be called only when the SYS instruction is executed (opcode 0x18A7).

If you use CodeWarrior and its hiwave debugger, you can try the Trace component to find out the erroneous code:

Select in main menu in debugger: Component -> Open… -> Trace. New window will appear on the screen. Place a breakpoint into SYS CALL ISR, run the code and wait until breakpoint is reached. Then the set of asm instructions will be displayed in the Trace window. These are the instructions that has been executed prior the breakpoint, so you can find out what was wrong.

Hope it helps.

Regards,

iggi

0 Kudos
Reply

1,196 Views
josh007
Contributor II

so i put all parts of the engine together and started the engine without the connection of the bdm cable and the engine is running :smileyhappy:

but now i always have the problem with the illegal_pb in the debugging mode. if i put a breakpoint in the dummy isr and start the engine, the code doesn't stopp there and anyway gives out the illegal_bp. I took some picture of the Trace windwos perhaps you know whats means the instruction INY.

ILLEGAL_BP_2.png

0 Kudos
Reply

1,196 Views
josh007
Contributor II

okay thanks for the answer. i will try if its helps and tell you the result :smileyhappy:

0 Kudos
Reply