MSPM0G3507: Sporadic missing events

We also tried to route the comparator to an GPIO and then used the event system:

Same issue here. 

There is some problem with the event system. 40 MHz ULPCLK should not be a problem?

We have tried to narrow down the phenomenon. The loss of the event occurs precisely when the two ADC modules start a new conversion. This is triggered asynchronously by another timer.

Does this help?

Hi, Dominik

1. DAC12's output is PA15, don't use this pin for other function.

2. Which ADC, Timer, PWM Timer COMP are you using in G3507's peripherals? (Such as ADC0, TimerA0)

3. Does this phenomenon happen during the stage of reading ADC result (if you do this in software) ?

Dominik Wuest said:

The loss of the event occurs precisely when the two ADC modules start a new conversion.

4. Timer trigger ADC start with event or software in Timer interrupt?

Dominik Wuest said:

This is triggered asynchronously by another timer.

Regards,

Helic

Hi Helic

1)

I do not use DAC12 output (PA15 is left open)

2)

I use both ADC in simultaneous sampling, triggered by a TIMER_SYS (TIMG0) event. Memory 1 need a valid trigger to step to next memory conversion register.

For the TIMER_SYS I use TIMG0:

For the TIMER_PWM I use TIMA0 with deadband insertion, fault handler. Trigger through COMP0 comparator.

COMP0 is configured as follows:

3) No, this problem also occurs when CPU is in Sleep0 and ADC conversion is triggered by the SYS_TIMER event, without any interrupt enabled in SYS_TIMER. I also tried to start conversion by software with a SYS_TIMER interrupt. Same problem.

4) I tried both. But the triggering is asynchronous to the PWM generation. I can try to synchronize that -> PWM_Timer triggers ADC.

What I also tried is to never go into a sleep mode: Wait in a while-loop with __NOP() until TIMER_SYS interrupt happens. This also had no effect to the problem.

For us, it looks like events are being lost for some reason. If we cannot find a solution, we can try to develop a demonstration project for the LP-MSPM0G3507.

Thanks for the support.

I synchronized ADC_StartConversion with the PWM Timer, so that it never happens in the same moment as the comparator triggers. Unfortunately still the same phenomenon. Could it be related to the access to the hardware registers? ADC12_getMemResult or updating the DAC12 or TIMx registers? These are accessed asynchronously.

We have just been able to prove that accessing hardware registers while an event is taking place causes the problem.

The following calls lead to the problem (may others too):

DL_TimerA_getRawInterruptStatus(TIMER_TIMEOUT_INST, DL_TIMER_INTERRUPT_ZERO_EVENT)
DL_TimerA_getRawInterruptStatus(TIMER_PWM_INST, DL_TIMER_INTERRUPT_FAULT_EVENT)

Can you comment on that?

Best regards

Dominik

Hi, Dominik

Thank you for the detailed test.

It will take some time to verify this issue.

Please feel free to post any updates, We will let you know if there is progress.

Currently, you can circumvent this issue by separating conflicting operations.

Regards,

Helic

5807.mapfiles.zip

Hi Helic

I think my problem is much more complicated.

If a single line of code is changed, the new software version may no longer work, even though this line has no influence during runtime. The problem is still the same: events to the timers are sporadically lost, which leads to incorrect PWM generation.

Attached are two map files. One leads to faulty behavior, the other does not. The difference between the files is a global variable, which is added and set during initialization. If two global variables are added and set, the software works again.

We have now tested this on two pieces of hardware. Both show exactly the same behavior.

Best regards

Dominik

Addition to the previous post. Also including __NOP() calls in the init routine contribute to the problem:

0 or 1 NOP: working
2 or 3 NOP: not working
4 or 5 NOP: working

For me it looks like it has something to do with the code alignment. nop_tests.zip

Hi Helic

An update from our side: It looks like, that the problem is related to the TIMG7 peripheral, which we use as blank source for COMP0. TIMG7 was triggered by the event system through TIMA0.

TIMG7 / CC1 did not work as blank source for COMP0 at all. Although this should work according to the data sheet.

DL_COMP_setBlankingSource(COMP0_INST, DL_COMP_BLANKING_SOURCE_4);

Since we removed TIMG7 and use TIMA0 / CC2 as blank source for COMP0 we are not able to reproduce the described problem from this thread.

The control of a flyback converter with a PWM frequency of over 100 kHz now works properly.

Hi, Dominik

I have done a quick test based on your description.

I didn't see any event loss for a long time.

May this code example will help you.

SporadicMissingEvents_G3507_nortos_ticlang.zip

Regards,

Helic

Thanks for your support. Since we have a working firmware and hardware this topic has no priority for us. Nevertheless, we will discuss internally whether we can try to create a test project with the seen problem that we can make available to you.

Hi, Dominik

Waiting for your response.

Regards,

Helic