LP-MSPM0G3507: Unable to enter TIMH0_IRQHandler.

itself

Hi Shi,

Where do you enable the NVIC TimerH interrupt in your code?  Enabling only the Timer's interrupt is not enough.  You have to also enable this interrupt with the NVIC.

Example:     NVIC_EnableIRQ(TIMER_INST_INT_IRQN);

Thank you Dennis,

Now the interrupt is available! But here comes another problem.

I want to count the time value so I used DL_TimerH_getCaptureCompareValue().

But the value is wrong and it seems to be not controlled.

What factors do I need to pay attention to.

Thanks!

Hi Shi,

Since it appears you are already familiar with the SDK, have you by chance looked at the capture/compare example for the MSPM0G3507?

You will find it in: C:\ti\mspm0_sdk_1_00_00_04\examples\nortos\LP_MSPM0G3507\driverlib\timx_timer_mode_capture_edge_capture

Take a look at how it is implemented, then if you are still struggling, let me know.

Dear Dennis,

I am still struggling!!!

Can I use the C:\ti\mspm0_sdk_0_54_00_03_eng\examples\nortos\LP_MSPM0G3507\driverlib\timh_timer_mode_capture_edge_capture?

They should be same,right?

When I use the SDK, I found that if there's no signal, the capture interrupt can also be entered. It's wrong, right?

It seems that if I use "DL_TimrH_startCounter(TIMH0)". The timer will start and it cause the interrupt.

I just want to calculate the pulse width. Help! It cost me a lot of time and nothing has improved.

My English is poor. So if there's something you can not understand,just ask me.

Best Regards!

Hi Dennis,

Thank you for your help. I have tried the timx duty and period SDK and I replaced TIMG0 with TIMH0.

First I use CCS Theia 1.0.0 (which is for the new MSPM0 IDE) to debug.

And the result is: pwmPeriod = 0 and unable to monitor the "temp" variable.

Then I think maybe the  capture failed or watching variable failed.

So I decided to use CCStudio 12.1.0 to have another try. (I have previously encountered monitoring variable exceptions and resolved this issue by changing the optimization level. In addition the CCS Theia can't select the optimization level)

Here comes to the catastrophe!

The program was stuck in the following "while". Then I cut off the power.

It's not the problem. The problem is I can not connect to my board anymore！

Force reset is useless. BSL failed. Factory reset failed.......

I have already broken three boards....... (Although I am a fresh graduate, one month broke three boards was a great feat...ToT)

Now I have no launchpad anymore. But it doesn't mean I give up.

I will read the "MSPM0G_TRM_v0p6" 's TIMH. And if there's any process, I will let you know as soon as possible.

Best Regards!

Hi Shi,

By chance, do you put the CPU in sleep or stand-by mode?  If you did this, the next time the debugger tries to connect to the device, the MSP has already come out of reset and entered one of these two sleep modes before the debugger gains control.  This is well published bug in the version of silicon on the launchpads.

Since the factory reset fails, try the following:

Change the code that puts the MSP into sleep mode to use only the SLEEP mode.  Build you project, and start the debug or download process.  Hold down the BSL button (S1) and just before CCS starts to download the code, release the BSL button.  What this does is force the MSP into BSL mode which means your code is not yet running, and you have about 10 seconds  for the debugger to connect.  It may take you a couple of tries, but once it programs you are good.

Hi Dennis,

Thank you for your help!

The TI engineer in shanghai contacted me and told me that the first batch of MSPM0 has a bug.(It seems that some delay settings are particularly high, causing the chip to enter a low power consumption mode without being controlled.)The "_WFI" and "_WFE" may cause the problem.

My broken launchpads have been delivered to him. And he would sent his launchpad to me.

I will continue to learn about the capture interrupts.

Wait for my good news.

Hi Shi,

I see. Yes, the WFI (wait for interrupt) and WFE (wait for event) is the instruction to put the CPU in one of the 4 sleep modes.  If you don't specify which mode  the CPU will enter SLEEP0 mode and will work with the debugger no problem.  Using either the STOPx or STANDBYx modes are what cause this issue, but only a problem on the pre-release silicon that came populated on the launchpads.  The silicon version that was released last week has that bug fixed.

So out of curiosity, do you use an instruction like this one? DL_SYSCTL_setPowerPolicySTOP0();  If so, you run the risk of causing the same issue on new launchpad.  Please let me know.

Hi Dennis,

Sorry for my late response.

I havn't use the "DL_SYSCTL_setPowerPolicySTOP0();". If I met any problems , I will post them immediately.

Thank you for your support.