MSP430F5438 false breakpoint hits while debugging

 I am using a similar setup as follows:

a) MSP430F5438 Rev. L chip on a MSP430PZ5X100 board.

b) IAR KickStart from slac050t.zip with TI USB FET tool via 4-wire JTAG

I have seen other problems, but not the one described.

Is the Timer clocked at 64Hz? (i.e., 64 cycles per second?) What clock are you using? How often does it generat an interrupt? What is the frequency of MCLK?

How many breakpoints are you using when this happens? When you say it's stopping in the ISR is there a breakpoint in the ISR? If so this could be a timing issue.

The debugger utilizes the embedded emulation module of the MSP430. This element controls only the CPU. Now, the Timer is a hardware peripheral, so the debugger does not have control over the operation of this module. Once the Timer is started, it will continue regardless of what the CPU is doing (until the CPU executes a command to halt the timer).

Now, what does this mean for debugging an application that uses timer interrupts? It means that single-stepping while the timer is running may not be the best way to analyze operation. Let us say that you have a 32kHz clock source for timer_A. Depending on the CCR setting that could be set to less than the time it takes to make one step using the debugger. In such a case you will have a flag pending at each step, so your debugging will be less meaningful with interrupts enabled than if interrupts are not enabled.

The best way to debug such applications is to set a breakpoint in the Timer Interrupt vector to analyze the situation, or wait until a timer even has passed to stop the debugger such that you can see what has transpired.

All in all please remember this general rule: the debugger controls only the CPU, not the state of the analog peripherals.

Please also note the following from http://focus.ti.com/lit/ug/slau157i/slau157i.pdf:

"The debugger utilizes the system clock to control the device during debugging. Therefore, device counters, etc., that are clocked by the Main System Clock (MCLK) are affected when the debugger has control of the device. Special precautions are taken to minimize the effect upon the Watchdog Timer. The CPU core registers are preserved. All other clock sources (SMCLK, ACLK) and peripherals continue to operate normally during emulation. In other words, the Flash Emulation Tool is a partially intrusive tool.

Devices that support Clock Control can further minimize these effects by selecting to stop the clock(s) during debugging (Project -> Properties -> TI Debug Settings -> Target -> MSP430 Properties -> Clock Control)."

EDIT: This Clock Control Setup is for CCE, not IAR. I am not sure if IAR has this feature.

We are also using a Rev. L part.

Yes the timer is clocked at 64Hz. We are using the RTC module to generate this 64Hz timer. It interrupts 64 times per second (i.e., 64Hz).  MCLK and SMCLK are currently running at 7.34Mhz and sourced from an external 32kHz crystal attached to XT1.

We are using only one breakpoint when this happens. There is no breakpoint in the ISR, the debugger stops on the definition of the ISR, not the first line of the ISR (i.e., on the actual ISR function name, see attached image).

I would also like to clarify that this is not just related to a Timer ISR we experience this issue when basically any isr occurs.

This issues has shown up since we ported our existing code base, consisting of ~60K of byte code, to the MSP430F5438. We have had the same code base running on a MSP30F449 for several years and have never had this problem in the past.  We have also had the code running on a MSP430FG4618 and did not experience this issue.

We have tried stopping the clocks using the Clock Control feature and it did not seem to help with this issue at all. We have also observed this same behavior using both IAR and CCE tools.

I could send you a project that demonstrates this issue if that would be any help.

R

rboyd said:

We are using only one breakpoint when this happens. There is no breakpoint in the ISR, the debugger stops on the definition of the ISR, not the first line of the ISR (i.e., on the actual ISR function name, see attached image).

I would also like to clarify that this is not just related to a Timer ISR we experience this issue when basically any isr occurs.

This issues has shown up since we ported our existing code base, consisting of ~60K of byte code, to the MSP430F5438. We have had the same code base running on a MSP30F449 for several years and have never had this problem in the past.  We have also had the code running on a MSP430FG4618 and did not experience this issue.

We have tried stopping the clocks using the Clock Control feature and it did not seem to help with this issue at all. We have also observed this same behavior using both IAR and CCE tools.

I could send you a project that demonstrates this issue if that would be any help.

R

 

How often does this issue occur? Can you take a very simple example, create a brand-new project, and run the code as-is? What do you observe?

Just did that. Created a very basic example, ran the code, and I end up at the BasiTimer ISR every time, except for the very first time. I can send along the project if you like.

R

Yes, please attach the new project with the code example. I'd be happy to take a look at it for you.

Same thing happen to me. Most often these un-wanted breakpoint happen in interrupt but sometimes in other pieces of code as well. One was always triggered when removing another breakpoint.

rboyd said:

Just did that. Created a very basic example, ran the code, and I end up at the BasiTimer ISR every time, except for the very first time. I can send along the project if you like.

R

Could you zip that and either attach or upload the zip file to your "my files" area?

I just uploaded the workspace. It has a single logging break point in main and the RTC module setup to generate a 64Hz ISR. The main loop will wake up every 1 seconds and increment a counter. The break point is set on the counter increment. MCLK and SMCLK are running at 7.340032 MHz.

R

I saw the same behavior, however I noticed that you are using the RTC... does this behavior happen only when implementing the RTC, or does it happen accross the board? The RTC has a couple of bugs and the work-around is here: http://www.ti.com/lit/zip/slac166

You might try implementing the work-around and seeing if the performance improves.

Hey,

After discussing this with the factory apps it seems there is a bug that has not been published yet for specifically the 543x which is caused when the code has repeated, successive interrupts. Right now there is no work-around.

Does this also apply to the 543x (A) series of parts? How about the 5418 part?

R

Can you tell me if this problem affects the 543x (A) and 5418 (A) series of parts?

This errata affects all devices in 54xx, 54xx_A and 552x families.

Regards,

Priya

Priya,

So what is this bug called - multiple interrupts can't be enabled bug?

Wow - pretty severe and needs to be documented for sure.

Thanks,
johnw

We setup the most basic project with a single timer interrupt running and it breaks the debugger. The only place breakpoints function reliably are inside interrupt routines. We have resorted to using a logic analyzer to trace code.

FYI - The sample project that demos this issue can be found in my files section of my profile.

R

rboyd,

Thanks for this - I will download your example and verify on my setup.

What about multiple IRQ's?  From the sound of it - if you have more than one IRQ enabled you are hosed.  Can you set breakpoints inside multiple IRQ's and have that work?

I suppose I can give it a try - in fact I think I did this weekend (spent quite a bit of time in a debugger - wasn't looking for this....) and did notice that it appeared the breakpoint was not occurring every time the IRQ was serviced --- but I need to verify that to be 100% sure.  I was also debugging in IAR and CCE.

Thanks!
johnw

In our setup, having a single interrupt routine breaks the debugger.  The code seems to runs fine, when its not being debugged, no matter how many IRQs you have.  We have been able to successfully debug interrupt routines no matter how many are running, you simple can't debug code in the foreground.

To All:

What about '541x devices?

Thanks,
johnw

According to Priya above all the 54xx parts have this issue.

rboyd,

You are correct - I misread that.

Thanks,
johnw

In my earlier reply (05-12-2009, two and half months ago -- and shortly after the first posting on this subject), I said:

 I am using a similar setup as follows:

a) MSP430F5438 Rev. L chip on a MSP430PZ5X100 board.

b) IAR KickStart from slac050t.zip with TI USB FET tool via 4-wire JTAG

I have seen other problems, but not the one described.

Is the Timer clocked at 64Hz? (i.e., 64 cycles per second?) What clock are you using? How often does it generat an interrupt? What is the frequency of MCLK?

my customer tested it with CCE v3.0/slac135e and also with IAR but the failure still occurs! He notice this failure first time in Febuary!

Regards
Holger

With either build of CCE Pro V3.1, if I click the Halt button it almost always stops in an ISR. The older chips stopped randomly in the code, sometimes in an ISR and sometimes not, depending on the duty cycle of the ISR vs. the other code.

However, this is not so much a problem. The real problem is that when I place a breakpoint in code outside of any ISR, it always stops in an ISR with the latest build of CCE Pro V. 3.1 (3.2.4.3.8 from slac135f).

The older build, 3.2.3.6.4/slac135e, does NOT do this. It correctly stops at the breakpoint. This is extremely important in debugging.

While there apparently are problems with the chip, there is something that the older and latest builds are doing differently. Until this is resolved, I'm sticking with the older build.

FYI, another problem I was having with the latest build was that when I ran my device stand-alone (without the JTAG), I was having problems with my device not turning on (i.e., the software starting and running). On the JTAG, it was fine. I thought I had some hardware problem with my PCB, but no, when I load the code with the older build, my device turns on perfectly.

Another problem TI is having with the chip/IDE is an unintentional erase of INFOA flash. I have replicated that, but also I have a problem that INFOA cannot be erased when I load my code, even though the project properties setting is to erase INFOA when loading the code.

I'm having an on-going SR correspondence with TI support engineers on these issues, but they have not replied on my latest find as of yet.  I'll keep you posted.

Dear E2E,

The root cause is relatively easy to explain but much more difficult to fix.

It all starts with the EEM hardware triggering a CPU halt due to a breakpoint or single-step. The JTAG becomes aware that the CPU is halted, but needs to continue clocking the CPU until an internal two-stage pipeline is flushed. If an interrupt (or an interrupt of higher priority) arrives during this time that the JTAG is flushing the pipeline (externally clocking the system) then the CPU will do what it is supposed to and service said interrupt. This is why you will often stop on the entry to the ISR and not quite on the first instruction. If you have a frequent background interrupts then the probability that you experience this behavior increases.

The behavior is very much timing dependent. Sometimes the user can workaround the problem while debugging with some well-placed NOP instructions but if the background interrupts are coming fast enough then even this will not help the debug.

We believe that we have a fix of the debug flow in software but it is not yet implemented or tested. Since this fix affects the JTAG synchronization and communication with the MSP430 it also affects the CoreIP verification. It must be carefully evaluated and then run with our current regression tests to verify that we are still capable of interacting with the device under all corner cases. This will take some time, but I have heard that we should have it hashed out by e/o 2009.

Regards, ~Miguel

Miguel, 

Thanks for the info, however if you are telling us that the problem can be fixed in software, that means that the tool software CAN make a difference. I’m telling you that in the older build of CCE Pro 3.1, 3.2.3.6.4, the problem of incorrectly halting in an ISR when the breakpoint is not, is almost non-existent. You can come here and I will show you.

(I say “almost” because occasionally it does stop in an ISR (usually my ADC12 ISR because that is much more frequent than my RTC ISR), but then, as I said previously, when I click the RUN button (or press F8) it will then stop at the breakpoint. The latest build, 3.2.4.3.8, always keeps stopping in the ISR.)

You should look at what the tool builds are doing differently. That may help you arrive at a solid fix. And in the meantime, you can tell customers to revert back to the older build. (Has anyone else observed my findings on the older build?)

Why don’t the older 430’s have this breakpoint issue? (I started my project with the MSP430F448.) Was it the tool? I would assume the internal pipeline also needs to be flushed in the older chips. What is different with the 5xxx family?

Let me know if there is any more information I can give you. 

Regards,

Ed

Ed,

You're right that the tool set can make a difference. I guess my point was that none of the current tool sets should 'fix' the problem, since the software we intend to modify is the DLL. You make a good point, though, that if a different install shows improved behavior then it holds some clues as to how we can resolve the problem.

The previous 430's actually didn't implement this pipeline; the 5xx is the first. This is why you don't see it in those devices.

~Miguel

Miguel,

The old build doesn't totally fix the problem, but I'd say it's 95% "fixed" and I can debug virtually unhindered by the chip problem.

When I installed the latest build, I think the DLL was updated. I could be wrong, but I think so. And when I first launched the debugger it told me that it needed to update the JTAG firmware. And when I reverted to the older build, it restored the old firmware. The firmware and the DLL work together. Correct? If so, that tells me that the DLL was indeed modified between builds.

Ed

Miguel,

Here's an update: It looks like the breakpoint problem is a little worse than "95% okay". I'd say maybe 70%. At certain locations of the breakpoint, it will always stop in an ISR. However, if I move the breakpoint to a different nearby line, then it always stops correctly at the breakpoint.

Also, a Tech Support engineer in Texas confirmed that the DLL was indeed updated with the latest build.

I hope this information is of value to you in resolving this problem.

Ed

Its been confirmed by TI via several different channels that this is a bug in the silicon. All we can do is wait for them to create a work-around in software and or fix the bug in future revisions of the silicon.

In the mean time, its good for people to know this is broken so they can make informed decision when deciding to use this part in a product.

We wasted almost two man months of time trying to figure out what was going on with this when we initially ported our code base (~70k compiled code) to this part. At the start, there was very little information on this issue and we didn't know if it was a problem with the IAR compiler, the silicone, or something we broke during our code port.

We spent weeks going back and forth with IAR on this and they never did indicate it was a problem with the silicon.

R

R,

First of all, the word is "silicon" not "silicone" which is something entirely different (though I can see why it's on your mind!) [:6]

I have been posting to inform TI and users alike of a possible temporary "work-around" using the older build of CCE Pro. Also my hope is that it may provide TI some information that would be helpful in their coming up with a software fix.

Ed

You will have to forgive my poor proof reading abilities.

I understand that you are just providing information that you think is relevant to this issue, I was in no way "criticizing" you for your efforts.

R,

Maybe TI will provide you with a "courtesy" version of CCE Pro (the older build that I am using partially successfully) to compensate you somewhat for your troubles. If so, you could confirm or disprove what I am experiencing. Let us know. Good luck!

Ed

TI beta DLL works fine so far with IAR to fix the false breakpoint issue.

Where would one get this beta DLL of which you speak?

I have been developing using a F5418 part for a while now, and have developed my own work-around for this issue (I am using IAR):

1. When the interrupt happens in the beginning of the ISR, disable the interrupt on the stack. IAR has a 'Stack' window, mask out the GIE bit 0x04 on the top most location (where the SP points).

2. Single step out of the ISR in the assembly code - something goes wrong if it is done in the C code...

3. The PC is misaligned on return so it should be adjusted. Right-click on the breakpoint and choose 'Set next statement'.

And you are ready to continue single-stepping through the code!

Thomas,

Looks like what you're doing is disabling the GIE upon return from the ISR. I use CCE Pro and there is no stack window, so, if I have a problem where I need to set a breakpoint, and if it stops in an ISR, then another work-around is re-compile with a call to _disable_interrupts() just before you need the breakpoint. Then this correctly stops at the breakpoint.

I say "if" above because it doesn't always stop in an ISR instead of the breakpoint. Sometimes by moving the breakpoint around a little I can get to stop without disabling interrupts. Then you can single or function step to the line of code where you wanted the breakpoint, and it doesn't stop in an ISR. (This bug seems only to manifest itself when in "run" mode, not is step mode.)

So this bug is a significant annoyance, but it is not insurmountable! However, I too would love to know about the DLL mentioned in a previous post. Is it by IAR? If it works, I do hope they share the knowledge with the TI compiler developers.

Ed

TI has a BETA MSP430.dll available that hasa fixed our problem with the breakpoint using IAR compiler.  If you contact your local TIFAE he can get it to you.  He talked like it pertained to the CCE as well but I know it works well with IAR.

I have similar problem only that when a breakpoint is enabled, false breakpoint is triggered in UART0 ISR causing overrun error on receive buffer. this is so frustrating. 

Hi!

We have had same problems with MSP430F5418 cpu and CCEv3 SR1 as well as CCS v4.0.1.

This new DLL's definately fix this problem! Thanks a lot ! [:D] [<:o)]

best regards,
Gregor 

Miguel,

So far, so good! The new DLLs seems to work fine, "as advertised". I'll let you know if I see any incorrect behavior in my debugging.

When I ran your installer, I was not sure if it would back up the old DLLs or not, so I cancelled it, backed up the old ones manually, then re-ran the installer. Would it have backed up the old ones?

I ask because you made a point about not using the BETA version for production. What is the procedure to revert back to the old DLLs? Just rename them? Does "regsvr32" need to be run? When will a "production" DLL be available?

Thanks,

Ed

Ed,

The installer will not back up the old DLL's. Hence you are correct that they should be renamed prior to install. Reverting back to the 'production' DLL's just requires renaming the DLL files. I move between the DLL's all the time, and I have never had to run regsvr32, so I would say it is not necessary.

The production DLL schedule is currently in definition. We will update the forum when we get some concrete dates.

Thanks, ~Miguel

Miguel,

Thanks.

For other TI Community members I just want to say that I noticed that when I updated the DLLs and went to load my code, CCE Pro (I'm using Ver. 3.1, Build: 3.2.3.6.4 ) gave a message that the JTAG firmware needed to be updated, which, of course, I allowed. I have noticed that when I used older or newer DLLs (different builds or versions of CCE Pro), I usually get this message. I was told that the DLLs and the firmware work together and if the existing firmware is not correct for the DLL, it will automatically ask to reload the firmware.

Ed

Priya said:

Boyd,

To add to Brandon's note, the errata  is still under investigation and hence not published. We understand this makes the debugging experience very difficult. If you have multiple interrupts in the system it may help to disable a few while still keeping the relevant ones. However this may not work for all cases. I will update the forum if there is any additional information.

Regards,

Priya

Priya,

That was 5 months ago. Are we getting anywhere closer?

When I compared slaz054 and slaz057, they both have 21 bugs listed. Three old bugs (EEM12, PORT15 & TB15) are removed and three new bug (JTAG20, RTC4 & UCS6) are added. What does that mean?

Furthermore, Is rev A going to have those undocumented  bugs under investigation too?

Regards,

OCY

see answer from miguel:
http://e2e.ti.com/forums/p/5776/42006.aspx#42006

New DLL fix it.

regards,
Gregor