I'm using MC9S12ZVML128. It has a GDU (Gate Driver Unit) which can control ADC1 conversion through the GDU DC link voltage which is monitored through ADC1 internal_3. I found it stops generating ADC1 completion interrupt (Vector base + 0x114, ADC1 conversion complete) when DC link voltage is over VHVHDHA or VHVHDLA depending on GHHDLVL bit setting of GDUCTR.
My questions are,
1. Is ADC1 completion interrupt controlled by DC link voltage through ADC1 hardware ONLY?
2. Can S12ZVM keep generating ADC1 completion interrupt when DC link voltage is over VHVHDHA or VHVHDLA?
Thanks,
Leon Sun
Hi Leon,
The ADC module does not care what input voltage it measures.
The HD voltage is divided by 5 (Table E-1, #29a) and measured as any other input signal.
At this high HD voltage level, you can't get a precise result though, because the input voltage is specified only up to 20V.
But the ADC interrupt will be triggered once the ADC is complete.
The issue must be elsewhere.
How do you trigger the ADC?
Do you use interrupts with higher priorities?
Regards,
Daniel
How do you trigger the ADC?
Answer: by Restart Mode with a fixed sample period.
Setting of ADC1CTL_0,
ADC_CFG = 3
STR_SEQA = 1
MOD_CFG = 0
Do you use interrupts with higher priorities?
Answer:
VHD Pin OverVoltage detected ISR (0x138) priority is 7.
ADC1 Error ISR (0x11C) priority is 5.
ADC 1 done ISR (0x114) priority is 4.
Hi Daniel,
Thank you very much for quick response. This code was implemented by someone several years ago. It starts to show issue when we change from HD high voltage monitor assert trip point high (VHVHDHA, Typ 28.3v) to HD high voltage monitor assert trip point low (VHVHDLA, Typ 21.0v). Inside our ADC1 completion interrupt service routine, we pet the watchdog. Because the trip point is reduced to 21.0v, somehow the ADC1 completion interrupt is no longer generated when DC link voltage reaches 21.0v which stops watchdog petting and triggers watchdog reset. I guess it's due to GDU DC link voltage monitor on ADC Channel Internal_3 (Table 1-11) stops ADC conversion somehow.
When voltage is over 20v, we don't care about the ADC result precision. We just want ADC1 completion interrupt is kept generated so the watchdog can still be petted inside the interrupt service routine.
I don’t quite understand the GDU phase multiplexer voltage (Internal_2) and GDU DC link voltage monitor (Internal_3) in Table 1-11. Should both GDU phase multiplexer voltage and GDU DC link voltage monitor be used? Not clear how they are used.
In section 18.4.9 GDU DC Link Voltage Monitor
It says the voltage on pin HD divide by 5 is routed to an ADC channel.
But in section 18.3.2.10 GDU Phase Mux Register (GDUPHMUX), VHD is divided by 12.
GDU Phase Mux Register (GDUPHMUX)
00 Pin HD selected , VHD / 12 connected to ADC channel
Kind regards,
Leon
Hello Leon,
Please try to use another input, like Internal_4 in place of Internal_3 and leave everything else as it was and test the high-voltage condition. Because I don't think the issue is caused by ADC sampling the Internal_3 input. I wonder if you can reproduce the issue that way.
Does the ADC get triggered to measure the channel? Because I understand that you use the EOL interrupt. Maybe the ADC can't get to the end of the list.
This is application-dependent, the VHD can be measured either directly (internal_3, divider 5) or via the Phase Mux (Internal_2, divider 12, if selected).
Regards,
Daniel
Hello Daniel,
One important thing I would like to fix is the watchdog reset issue when DC voltage is over 21v. With your input, I realized ADC1 completion interrupt stops running may be because a higher interrupt prevents its running since GDU Voltage Limit Detected interrupt has a higher priority then ADC1 completion interrupt. So, I added watchdog service in GDU Voltage Limit Detected interrupt service routine since watchdog service in ADC1 completion interrupt service routine can't run anymore. After adding this change, the reset issue is gone. I think the root cause is found. Please let me know if you have any comment on my analysis and solution.
Thanks,
Leon
Hello Leon,
Thanks for the update, I'm glad you found the root cause.
The analysis makes sense.
But I can't comment on the solution since this is really application-dependent.
BR, Daniel