TIDA-010042: The MPPT_LOOP does not start every time

Adrien Boissy

Part Number: TIDA-010042

Tool/software:

Hi,

I purchased the TIDA-010042 MPPT PCB and used the design files from the official reference design on TI.com. I received the board and verified that the converter works by manually coding specific PWM values — everything functioned as expected. I then flashed the available firmware version V2.0, which appears to be the only and latest version.

I tested the board in two different setups:

Using a homemade PV emulator – a programmable DC power supply running an algorithm to emulate a PV panel with an open-circuit voltage of 35V and short-circuit current of 3.5A. I used an electronic load (E-load) in constant voltage (CV) mode at 22V to simulate the battery. The board was connected to my computer via LaunchPad for debugging.
- Before starting, the firmware showed the system was in Wait_state, as expected (attempting MPPT every 4 seconds, but remaining in wait state due to no current flow).
- I powered the E-load first, then the PV emulator. However, no current flowed. There is two "mode that take place every 5s, the first one in which the Output current is equal to 0A and voltage is around 20V (!=the CV voltage). And the other one during which hear a buzzing sound around 30 Hz (maybe the vibration of a component), the outpout voltage drops to 0V and a very small current is drawn (0.1A).
- Using an oscilloscope, I observed the second state : output voltage is 0V most of the time, but at a frequency of 30 Hz, (which matches the buzzing sound) it tries to convert the power during 1ms (PWM is active and output voltage rise) then returns to zero. It looked like the system was trying to start but failing. I added two photos of the osciloscope (the second one is zoomed compared to the first one)
Using a real PV panel – I replaced the emulator with an actual solar panel and kept the E-load in CV mode at 23V.
- Sometimes, MPPT starts correctly, and the system reaches the MPP.
- However, some other time or if I disconnected and reconnected the panel (even after resetting the software), the system would often remain stuck in Wait_state. I had to connect/disconnect the E-load multiple times to get MPPT to start again. If it didn’t work, I would again hear the buzzing sound, and the same behavior as with the PV emulator case. ( cf the pictures of the osciloscope)

After reading the TI forums, I saw a recommendation to connect a power supply with a diode in parallel with the E-load to better simulate a battery.

Why is this necessary?
Can you confirm that both the PSU + diode and the E-load should be connected in parallel to the “Battery +” and “Battery –” terminals?

I tried this configuration, it didn't work at all, the issue persisted — still no current draw and the same buzzing.

Do you have any idea what might be causing this behavior? Is there a condition that must be met on the battery side for the MPPT loop to start properly?

Thanks in advance for your help!

Best regards,
Adrien

4 months ago

0 Bowen Ling 4 months ago

TI__Intellectual 1430 points

Hi Adrien,

Thanks for testing the firmware.

It might be the reason of #define MIN_OUTPUT_CURRENT (10) //80mA

This is the threshold of output current, if the output current is detected less than 80mA, then the system will go into wait mode to reduce switching losses. As a first step, you can try to reduce the MIN_OUTPUT_CURRENT to make it easier to start.

For paralleling a diode connected with the PSU, i am not sure of this, could you share the e2e link?

Best Regards,

Bowen

0 Adrien Boissy 4 months ago in reply to Bowen Ling

Prodigy 20 points

Hi Bowen,

Thank you very much for your answer,

For paralleling a diode connected with the PSU I found it there : (+) TIDA-010042: Charging with Electronics load - Simulation, hardware & system design tools forum - Simulation, hardware & system design tools - TI E2E support forums

Maybe this is not relevant with the latest version of the code, do you think I should do it to simulate the battery ?

Concerning my issue, I finally don't think the Wait_state and MIN_OUTPUT_CURRENT are to blame, indeed, even when the Wait_state=0 (during 200ms) the PWM keep getting enabled and disabled (as you can see in the osciloscope pictures taken when Wait_state=0)

I looked into what may do that and I found out that in

ADC12_1_INST_IRQHandler() :

There is the test:

if(output_current > Output_current_prot) //25A, 124.12bits/A

{

PWM_FORCE_LOW();

So in case of overcurrent, this test disable the PWM signal, then it waits for 32ms (1000 interrupts requests that happen every 32us) before enabling it again. This is exactly what I saw in the pictures of the osciloscope : PWM is enabled, then after 1ms it get disabled for 30ms then enabled again.

So I will try with other values, because it seems that the output_current overpass the limit, which is strange. Indeed, I apply at the input a Solar panel that provides OCV=35V and SCC=1A, the output is an E-load in CV mode at 22V, so I don't know how the output current could be higher than 25A. Overshoot ? An issue with the Hardware ? A problem with the E_load

Also do you have an insight on why the code compares Output_current with the protection instead of Output_current_average ?

Can I get rid of this protection for testing purpose ?

Thank you for your time and your answers,

Best Regards,

Adrien

0 Bowen Ling 4 months ago in reply to Adrien Boissy

TI__Intellectual 1430 points

Hi Adrien,

When i test with E-load, i just use CV mode, did not parallel another PSU.

The Solar panel should not output such high current, can you get the inductor current signal on oscilloscope? This will help on identify if this is a problem of over-current, which now seems to be the top suspect.

I use Output_current instead of Output_current_average is because i want to protect the FET faster, if using the average value, the delay will be too long.

I suggest you first see the real current signal, if the current is not really high, which means the current stress on FET is not dangerous. Then you can try with get rid of this code to exclude if this this mis-trigger in SW.

Thanks,

Bowen

0 Adrien Boissy 4 months ago in reply to Bowen Ling

Prodigy 20 points

Hi Bowen,

Thanks again for your response.

I wanted to measure the current output from the MPPT, but I don’t have access to a current probe. I was considering using a shunt resistor, but I haven’t completed the calibration yet. Do you have any recommendations for accurately measuring the output current without a current probe? Also, how would you suggest measuring the inductor current in this setup?

I’ve performed further testing and noticed that when I connect a small PSU in parallel with the E-load, the overcurrent protection issue no longer occurs. Based on this, my current hypothesis is:

Without the PSU, the output voltage starts at 0V. When the MPPT loop initiates, the converter tries to ramp the output from 0V to 22V quickly, causing a large inrush current that trips the overcurrent protection.
With the PSU in parallel, the output voltage is already close to 22V when MPPT starts, so the converter only needs to supply a small incremental current, avoiding the protection trigger.

Do you think this explanation makes sense?

Howerver I had a new issue, which was that "Duty" would be stuck at its lower limit : (Duty=144, D=0.55) and because the outpout voltage is 22V it means that the input voltage should be 40V which is above the PV panel OCV, so no power could be drawn. I’m not sure why the duty cycle gets stuck there, even when the PV panel is connected and capable of supplying power. Do you have any idea what might cause this behavior?

As a temporary solution, I reduced the minimum duty cycle to Duty = 115 (D = 0.64), which corresponds to an input voltage of ~34.5V when Vbat = 22V — within the PV panel’s OCV range. With this adjustment, the system works correctly.

However, since this minimum duty value depends on the battery voltage, I’m considering dynamically adjusting the minimum duty cycle based on Vbat so that the input voltage stays below 35V.

Do you think this is a valid approach?
Where in the code would be the best place to implement such logic?
Would modifying the minimum duty cycle dynamically interfere with any other parts of the software, like MPPT behavior or protection features?

Thanks again for your time and support.

Best regards,

Adrien

0 Bowen Ling 4 months ago in reply to Adrien Boissy

TI__Intellectual 1430 points

Hi Adrien,

I am glad to hear the OCP is solved. I believe your theory makes sense, for measuring the current, i think it's better to have a current probe, with a high precision shunt (accurate value and low ESL), it's also possible.

I never tried to change the minimum duty cycle, but you can try this. You can implement this logic in duty cycle change ISR in believe. I have one question, if the duty is 0.55, the output is 22V, the input should be 40V, did you use multimeter test the input terminal's voltage to see if it really is 40V?

Thanks,

Bowen