[SOLVED] TLE9844-2QX: falling edge keeps erroneously being reported on MON5

Announcements

Webinar: Integrated solutions for smaller, simpler low-voltage motor control design.
Join the webinar to experience!

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User15529
Level 1
Level 1
I'm developing an application for a TLE9844-2QX microcontroller and I'm having an issue where triggering an edge on certain MONs (1, 2, 3) also causes a falling edge on MON5, which is used to trigger the deletion of data stored in EEPROM.

I've configured my high-voltage monitor inputs like this:

3263.attach

I've confirmed using an oscilloscope that no edge occurs on MON5 when I trigger MON1/2/3, and yet the interrupt for it triggers:

3264.attach

Has anyone encountered similar strange behaviour with the MON inputs for this board or a related one?
0 Likes
5 Replies
Lykaon
Employee
Employee
First like received
Hi,
in your example the MON5 has no selection for either "wake on rising edge" nor "wake on falling edge. One of those settings are required to enable the comparator of the monitor pin.
By the way, same setting is required for MON2.

Kind regards
User15529
Level 1
Level 1
I posted a pretty lengthy reply to this but it's not showing up. I'm not sure if there's some problem with these forums that caused it to get dropped, or whether I just need to wait for it to show up. I'll try again.

Edit: Oh I see, before the redirect fired this time I noticed it said it requires moderator approval before it appears.
0 Likes
User15529
Level 1
Level 1
Hello Lykaon,

Lykaon wrote:

in your example the MON5 has no selection for either "wake on rising edge" nor "wake on falling edge. One of those settings are required to enable the comparator of the monitor pin.


By this do you mean the MON_STS bit will be inaccurate unless I configure one of these "wake on" options? Because I noticed this and thought it was a bug, and I submitted it to Infineon support who appear to be treating it as a bug as well (Case:3781286).

Because I want to be able to read the status of these MONs but not use all of them as wake-up sources, I enable/disable them as wake-up sources within my application logic rather than through IFX Config Wizard:

3266.attach

In this code, I'm enabling/disabling wake-up for MONs 1 and 2.

I've also tried enabling MON 5 as a wake-up source (wake on rising edge) in IFX Config Wizard. I find that the interrupt is still erroneously triggering, although one difference I observe is that when the breakpoint I've set is hit, MON 5 will read as "low" if I don't configure it as a wake-up source and "high" if I do:

3267.attach3268.attach
0 Likes
User15529
Level 1
Level 1
Configuring MON5 as pull-down instead of pull-up seems to resolve the issue - an interrupt only triggers when I apply a signal to MON5 and not when I manipulate the other MONs.
0 Likes
Lykaon
Employee
Employee
First like received
Hi David,
the mon has a edge detection, so you have to select either MONxRISE or MONx_FALL[. In case you don't want to have the MON pin as wake-up source, just deactivate before entering the power saving mode.
For the case with the unintended status update on MON5, I would try to increase the filter time (just to exclude a cross-coupling effect on your board/setup) -> PMU_CNF_WAKE_FILTER

3270.attach