[solved]breakpoint : halt only main program, not ISR

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

[solved]breakpoint : halt only main program, not ISR

388 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lg_inetyx on Wed Jan 21 03:48:21 MST 2015
Hello !

Recently, I've come to an issue I don't have a workaround for yet...

I am currently developping a motor driver - this implies an ISR called periodically to setup a timer PWM according to a sine table.
Until here, no big deal...

However, this is not the only code in the application, and I need to setup some breakpoints in the main while the motor is running (ie the isr is still fired).

Unfortunately, if I use a breakpoint, the ISR won't be triggered, the timer won't be updated, which means my PWM ratio will remain the same, which means unwanted current in the motor, which leads to the destruction of my power electronics :(.

Has anybody ever had the same issue ? Which workaround did you use* ?
0 Kudos
5 Replies

364 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lg_inetyx on Thu Jan 22 00:20:50 MST 2015
Hi everybody !

Thanks a lot for all your answers !

It appears using an external custom debugger doesn't fit my budget, neither in cost nor in time, so I'm gonna go for something else.
However, it is good to know this kind of solution exists ^^

As I'm already working with freeRTOS and the UART, The logging task approach seems the best to me : easy & fast to implement :D.

PS : Thanks a lot for this forum, it is incredible to see that 4 people have answered me in 24 hours, moreover using different approch and proposing useful solutions.
Keep on guys, you are doing a great job !


Laurent
0 Kudos

364 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Superfred on Wed Jan 21 07:32:26 MST 2015
Hello,

I made me my own small logging system:

The event stores Logtype, Timestamp, Messageid and Value in a FIFO-Queue using a small function.
The Logtype value selects the type of message I want to see, all other mesages will be not stored,
so I do not have to change my code to get for instance the IMU angles, I send a Command which simply changes the Logtype.

A seperate RTOS Task reads the FIFO Queue, translates the Messageid into a readable text ("IMU angle = ") and prints it out via UART or recently wireless via a RFM70 (SPI) radio module.

This helped me a lot, I can get messages and values without interrupting time critical tasks, even out of ISRs.

Fred
0 Kudos

364 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by R2D2 on Wed Jan 21 06:18:28 MST 2015

Quote: lg_inetyx
Has anybody ever had the same issue ?



Yes  :)


Quote: lg_inetyx
Which workaround did you use* ?



Just don't use breakpoints  :D

Adding an array to store a few values can help to get data without interrupting / destroying your hardware...

Then you can read these data later or transmit them (USB, UART, CAN...) :)

0 Kudos

364 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by MikeSimmonds on Wed Jan 21 05:05:58 MST 2015
Traditionally, systems (such as your motor control or car ECU's) that must not simply halt at a breakpoint
make use of the (little documented) 'debug monitor' system interrupt (marked as reserved in some NXP user
manuals).

This uses debugging code that has to be included into the firmware image which handles debug related issues
without halting the processor.

Unfortunately, (as far as I know) the IDE's (LPCXpresso, Keil, IAR) all use a 'halting debug' approach.

One would have to purchase a custom debug solution [External debugger and debug monitor code] which
is likely to be (very) expensive and difficult to find.

You could implement your own solution, but you would need deep understanding of the CoreSight debugger
and also have to write your own external (PC) debugger and monitor. This is way beyond the capabilities of
most users.

I am sorry that this is not much help, but at least you have some insight as to why you will have to come up
with some sort of hardware work around to stop the motor burning out. I am not hardware savey, but perhaps
temporarily adding a resetable fuse to the motor circuit?

Regards, Mike


0 Kudos

364 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by 1234567890 on Wed Jan 21 04:11:20 MST 2015
I'm not sure, but I think it depends on the device. There are devices where it is selectable 'halt timer on debug' or so.
0 Kudos