DRV8317: nSLEEP and AVDD LDO supply problem

Hi Jernej,

I'm thinking that it is possible that your 3.3V bus is under too much load and cannot provide the 3.3V that it should be able to. 

Is it possible for you to apply external power to the TMS320F2800137 and try this code again to test if this is the case?

Thank you,

Joseph

Hi,

I have already tried to externally supply the board in order to reflash the CPU and it worked, but I do not think it is the problem with 3.3V. I am running the board successfully with GPIO for nSLEEP configured as input. The board is running without external supply, motor is spinning (quite fast). The only problem I have is when configuring nSLEEP GPIO on CPU side as output, it drives the pin low for some reason, even if I set the pin as 1 and Open-Drain type. I see this with the oscilloscope on nSLEEP pin of DRV8317. LDO is then shutdown and the board looses 3.3V rail voltage. Regarding the 2.5V on nSLEEP, maybe my EMS put the wrong Zener diode, but 2.5V is enough.

Regards,

Jernej

Hi Jernej,

Interesting, thank you for the info. I am as familiar with the intricacies of the GPIO pins on this microcontroller, and am not sure of the differing capabilities of each GPIO pin. I'm wondering, have you tried different GPIO pins from the MCU to control nSLEEP? It should not matter but maybe see if that changes anything. 

It may be helpful to make a post on the TMS320F2800137 forum as well, as they would have more insight here than me. But to clarify, you set the GPIO29 pin to be an output, and it pulls the nsleep pin low for too long and the device sleeps? Then it goes high to 2.5V a little after?

This must mean you are using the Hardware version of the device right? Otherwise faults can be cleared using the CLR_FLT bit through SPI. Just double checking this.

Thank you,

Joseph

Hi,

Yes, I am using HW version of the device. After setting the GPIO as output, LDO shuts down and BOR resets the CPU. After reset, CPU is brought up again and the cycle repeats. I did not try to use different GPIO, becuase it is hardwired on my PCB which is really small (18by20mm). It is hard to get to other pins and almost all are already used. I am using 32 pin package.

Regards,

Jernej

Hi,

What happens if you put line of code that writes pin 29 high after setting it to output? In code snippet you sent it is reversed. Shouldn't the pin be driven high after the output direction is set? or does the order not matter?

GPIO_setDirectionMode(29, GPIO_DIR_MODE_OUT);

GPIO_writePin(29, 1);

Thank you,

Joseph

I was thinking the same and did all permutations. Nothing helped. When GPIO_setDirectionMode function is called, debugger dies. Interesting thing is that when I call GPIO_setPadConfig with OpenDrain setting before changing the direction mode, debugger dies in GPIO_setPadConfig function. I have reposted the message to TMS320F2800137 forum and will see.

Jernej

It must be something in GPIO logic inside the CPU. Maybe because the pin has 2.5V on it before changing direction.

Hi Jernej,

Interesting, thank you for the quick updates.

I would imagine the team responsible for TMS320F2800137 forum would know what the issue is.

I have encountered, although on a different MCU, GPIO pins not being "created equally". Meaning Although labeled GPIO there are different MUX settings that may affect how they operate. My knowledge is limited here though but I also suspect something like that is happening here.

Thank you,

Joseph

Thank you for helping me. Currently I do not need to reset fault conditions, because on the HW version of the device, this is done automatically for the most of faults. As I have said, the board it is running. I am having some issues with overcurrent tripping, when motor starts. According to oscillograms, the current is a liitle bit higher then expected and CMPSS are tripping the PWMs. I have disabled this also, because the builtin overcurrent protection is enough for me.